chuck

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Chuck: Clarify and Implement

Chuck：澄清与实施

Lightweight collaborative skill for tasks that may benefit from brief clarification before implementation. No plan file — chuck dispatches immediately when the task is clear; when clarification is needed, it asks a few questions, proposes an approach, gets approval, and dispatches an implementer.

<HARD-GATE> Do NOT start implementing until you have: 1. Asked your clarifying questions (or determined none are needed) 2. If clarification was needed: proposed an approach and received user approval to proceed </HARD-GATE>

适用于实施前可能需要简短澄清的任务的轻量化协作Skill。无需计划文件——当任务明确时，Chuck会立即分派执行者；当需要澄清时，它会提出几个问题，给出实施方案，获得批准后再分派执行者。

<HARD-GATE> 在满足以下条件前，请勿开始实施： 1. 已提出澄清问题（或确定无需澄清） 2. 若需要澄清：已提出实施方案并获得用户批准 </HARD-GATE>

When to Use

使用场景

Use chuck when:

The task is clear or needs brief clarification, but not a full plan
You could implement it in one focused session
It touches a handful of files with a clear scope

Use nash + stoudemire instead when:

The task has multiple independent components
Architectural decisions have meaningful trade-offs
You'd need more than 3 questions to understand the requirements

在以下情况使用Chuck：

任务明确或仅需简短澄清，无需完整计划
可在一个专注的工作时段内完成实施
涉及少量文件，范围清晰

在以下情况改用nash + stoudemire：

任务包含多个独立组件
架构决策存在重大权衡
需要超过3个问题才能理解需求

Checklist

检查清单

Create a TodoWrite task for each item and complete them in order:

Quick context check — glance at relevant files/structure
Clarify — ask 1-3 questions (only if genuinely unclear)
Propose approach — present one recommendation and get approval (only after clarification)
Dispatch implementer — fresh subagent with full task context
Handle result — report back to user

为每个事项创建TodoWrite任务，并按顺序完成：

快速上下文检查 —— 浏览相关文件/结构
澄清 —— 提出1-3个问题（仅当确实存在疑问时）
提出方案 —— 给出一项建议并获得批准（仅在澄清后进行）
分派执行者 —— 携带完整任务上下文的全新subagent
处理结果 —— 向用户反馈

Process Flow

流程示意图

dot

digraph chuck {
    "Quick context check" [shape=box];
    "Clarification needed?" [shape=diamond];
    "Clarify (1-3 questions)" [shape=box];
    "Propose approach" [shape=box];
    "User approves?" [shape=diamond];
    "Dispatch implementer subagent" [shape=box];
    "Handle result" [shape=box];
    "Report to user" [shape=doublecircle];

    "Quick context check" -> "Clarification needed?";
    "Clarification needed?" -> "Dispatch implementer subagent" [label="no"];
    "Clarification needed?" -> "Clarify (1-3 questions)" [label="yes"];
    "Clarify (1-3 questions)" -> "Propose approach";
    "Propose approach" -> "User approves?";
    "User approves?" -> "Propose approach" [label="no, revise"];
    "User approves?" -> "Dispatch implementer subagent" [label="yes"];
    "Dispatch implementer subagent" -> "Handle result";
    "Handle result" -> "Report to user";
}

dot

digraph chuck {
    "Quick context check" [shape=box];
    "Clarification needed?" [shape=diamond];
    "Clarify (1-3 questions)" [shape=box];
    "Propose approach" [shape=box];
    "User approves?" [shape=diamond];
    "Dispatch implementer subagent" [shape=box];
    "Handle result" [shape=box];
    "Report to user" [shape=doublecircle];

    "Quick context check" -> "Clarification needed?";
    "Clarification needed?" -> "Dispatch implementer subagent" [label="no"];
    "Clarification needed?" -> "Clarify (1-3 questions)" [label="yes"];
    "Clarify (1-3 questions)" -> "Propose approach";
    "Propose approach" -> "User approves?";
    "User approves?" -> "Propose approach" [label="no, revise"];
    "User approves?" -> "Dispatch implementer subagent" [label="yes"];
    "Dispatch implementer subagent" -> "Handle result";
    "Handle result" -> "Report to user";
}

The Process

流程说明

Phase 1: Quick Context Check

第一阶段：快速上下文检查

Before asking questions, glance at the relevant parts of the codebase:

What files/modules are involved?
What patterns does the existing code use?
Is there anything that would change your approach?

Keep this fast — 30 seconds of exploration, not 5 minutes of archaeology.

在提问前，浏览代码库的相关部分：

涉及哪些文件/模块？
现有代码使用了哪些模式？
是否存在会改变实施方案的内容？

保持快速——仅需30秒探索，而非5分钟深入研究。

Phase 2: Clarify

第二阶段：澄清

Ask 1-3 questions to fill genuine gaps. Rules:

Prefer multiple-choice questions (easier for the user to answer quickly)
Only ask what you actually need to know to implement well
If everything is clear from context, skip this phase entirely and say so
Hard cap: 3 questions. If you need more, the task might be too big (see scope guard below)

提出1-3个问题以填补真实的信息空白。规则：

优先使用选择题（方便用户快速回答）
仅询问实施所需的必要信息
如果上下文已明确所有内容，直接跳过此阶段并告知用户
上限：3个问题。如果需要更多问题，任务可能超出范围（见下文范围管控）

Phase 3: Propose Approach

第三阶段：提出方案

Only do this phase when you asked clarifying questions.

Present one recommended approach in a few sentences:

What you'll build/change
Which files you'll touch
Any trade-offs or assumptions

Ask: "Does this look good?" Wait for approval before proceeding.

仅在提出澄清问题后执行此阶段。

用几句话呈现一项推荐方案：

要构建/修改的内容
会涉及的文件
任何权衡或假设

询问：“这个方案看起来可行吗？”等待用户批准后再继续。

Phase 4: Dispatch Implementer

第四阶段：分派执行者

Launch a fresh subagent with:

The synthesized task description (from the request and any clarification conversation)
Relevant context (file paths, patterns, dependencies)
The no-commit rule
Self-review instructions

Use the implementer prompt template below.

启动全新的subagent，附带：

合成的任务描述（来自用户请求及澄清对话）
相关上下文（文件路径、模式、依赖项）
禁止提交规则
自我审查说明

使用下方的执行者提示模板。

Phase 5: Handle Result

第五阶段：处理结果

Based on the implementer's status:

DONE → run
```
git diff --stat HEAD
```
, report summary to user
DONE_WITH_CONCERNS → review concerns; if they affect correctness, address them (re-dispatch or fix directly); if observational, note and report
NEEDS_CONTEXT → provide missing context from your clarification phase, re-dispatch
BLOCKED → escalate to user with what was attempted and what's blocking

根据执行者的状态：

DONE → 运行
```
git diff --stat HEAD
```
，向用户反馈摘要
DONE_WITH_CONCERNS → 审查问题；若问题影响正确性，解决问题（重新分派或直接修复）；若仅为观察性问题，记录并反馈
NEEDS_CONTEXT → 提供澄清阶段缺失的上下文，重新分派
BLOCKED → 向用户上报已尝试的操作及阻塞原因

Scope Guard

范围管控

If during clarification you realize the task:

Would touch 5+ files across multiple concerns
Requires multiple independent components
Needs architectural decisions with meaningful trade-offs

Flag it: "This seems like it might benefit from a full plan. Want me to switch to nash, or should I proceed with chuck?"

Let the user decide. Don't block.

如果在澄清过程中发现任务：

涉及5个以上跨多个关注点的文件
需要多个独立组件
需要存在重大权衡的架构决策

请告知用户：“这个任务似乎需要完整计划。需要切换为nash，还是继续使用Chuck？”

由用户决定，不要强制阻塞。

The No-Commit Rule

禁止提交规则

Chuck and its implementer subagent MUST NOT commit.

No
```
git commit
```
from the controller (you).
No
```
git commit
```
from the implementer subagent.
No
```
git add
```
followed by commit.
No amending existing commits.

The human reviews the full diff and commits when ready. If the implementer commits anyway, check

git log

to count the mistaken commits, then soft-reset to undo (

git reset --soft HEAD~N

) and note it in your report.

Chuck及其执行者subagent绝对禁止提交。

控制器（你）禁止执行
```
git commit
```
。
执行者subagent禁止执行
```
git commit
```
。
禁止执行
```
git add
```
后提交。
禁止修改现有提交。

由人工审查完整差异并在准备好后提交。如果执行者意外提交，检查

git log

统计错误提交的数量，然后执行软重置撤销（

git reset --soft HEAD~N

）并在报告中注明。

Implementer Prompt Template

执行者提示模板

Use this when dispatching the implementer subagent:

```
Task tool (general-purpose):
  description: "Implement: [short task name]"
  prompt: |
    You are implementing a task that was clarified through conversation with the user.

    ## Task

    [Synthesized task description — what to build/change, acceptance criteria,
    files to touch. Write this fresh from the request and any clarification conversation.]

    ## Context

    [Relevant context: file paths, existing patterns, dependencies, anything
    the implementer needs to understand where this fits.]

    ## CRITICAL: Do Not Commit

    You MUST NOT run `git commit`, `git add` followed by commit, `git commit --amend`,
    or any other command that creates or mutates a commit. The human reviews and commits
    everything at the end.

    `git add` to stage files for `git diff --staged` is fine, but never follow it with
    a commit.

    ## Before You Begin

    If you have questions about the requirements, approach, or anything unclear — ask
    them now. It's always OK to pause and clarify.

    ## Your Job

    1. Implement exactly what was described
    2. Write tests if applicable
    3. Verify implementation works (run tests, check for errors)
    4. Do NOT commit — leave changes in the working tree
    5. Self-review (see below)
    6. Report back

    ## Self-Review

    Before reporting, check your work:

    **Completeness:** Did I implement everything described? Missing requirements?
    **Quality:** Clean, maintainable code? Clear names?
    **Discipline:** Only built what was requested? Followed existing patterns?
    **Testing:** Tests verify behavior (not mocks)? Comprehensive?
    **No-commit check:** `git log` shows no new commits from this session.

    Fix any issues found during self-review before reporting.

    ## Report Format

    - **Status:** DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT
    - What you implemented
    - Files changed (`git diff --stat HEAD`)
    - Test results (if applicable)
    - Self-review findings (if any)
    - Concerns or blockers (if any)
```

分派执行者subagent时使用以下模板：

```
Task tool (general-purpose):
  description: "Implement: [short task name]"
  prompt: |
    You are implementing a task that was clarified through conversation with the user.

    ## Task

    [Synthesized task description — what to build/change, acceptance criteria,
    files to touch. Write this fresh from the request and any clarification conversation.]

    ## Context

    [Relevant context: file paths, existing patterns, dependencies, anything
    the implementer needs to understand where this fits.]

    ## CRITICAL: Do Not Commit

    You MUST NOT run `git commit`, `git add` followed by commit, `git commit --amend`,
    or any other command that creates or mutates a commit. The human reviews and commits
    everything at the end.

    `git add` to stage files for `git diff --staged` is fine, but never follow it with
    a commit.

    ## Before You Begin

    If you have questions about the requirements, approach, or anything unclear — ask
    them now. It's always OK to pause and clarify.

    ## Your Job

    1. Implement exactly what was described
    2. Write tests if applicable
    3. Verify implementation works (run tests, check for errors)
    4. Do NOT commit — leave changes in the working tree
    5. Self-review (see below)
    6. Report back

    ## Self-Review

    Before reporting, check your work:

    **Completeness:** Did I implement everything described? Missing requirements?
    **Quality:** Clean, maintainable code? Clear names?
    **Discipline:** Only built what was requested? Followed existing patterns?
    **Testing:** Tests verify behavior (not mocks)? Comprehensive?
    **No-commit check:** `git log` shows no new commits from this session.

    Fix any issues found during self-review before reporting.

    ## Report Format

    - **Status:** DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT
    - What you implemented
    - Files changed (`git diff --stat HEAD`)
    - Test results (if applicable)
    - Self-review findings (if any)
    - Concerns or blockers (if any)
```

Key Principles

核心原则

Speed over ceremony — no plan file, no multi-reviewer pipeline
Just enough clarification — 1-3 questions max, skip clarification and approval if clear
One approach when needed — after clarification, propose your best recommendation, not a menu
Fresh subagent — isolate implementation context from clarification context
No commits — human owns the commit history
Soft scope guard — flag when something's too big, but don't block

速度优先，减少繁文缛节 —— 无需计划文件，无需多审核者流程
恰到好处的澄清 —— 最多1-3个问题，若任务明确则跳过澄清和批准步骤
必要时仅提供一种方案 —— 澄清后给出最佳推荐方案，而非多个选项
全新subagent —— 隔离实施上下文与澄清上下文
禁止提交 —— 人工掌控提交历史
柔性范围管控 —— 当任务过大时标记，但不强制阻塞