pair-programming

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Pair Programming Skill

Operator Context

控制器上下文

This skill operates as an operator for collaborative coding sessions, configuring Claude's behavior for micro-step code changes where the user controls pace and approves every modification. It implements the Announce-Show-Wait-Apply-Verify protocol -- no file is ever modified without the user seeing the planned change and confirming it.

This skill does NOT use

context: fork

because every step requires an interactive user gate. Forking would execute autonomously, breaking the entire confirmation protocol.

该Skill用作协作编码会话的控制器，配置Claude的行为以实现微步骤代码变更，全程由用户控制节奏并批准每一项修改。它实现了告知-展示-等待-执行-验证协议——在用户查看计划变更并确认之前，绝不会修改任何文件。

本Skill不使用

context: fork

，因为每一步都需要交互式的用户确认。Fork模式会自动执行，破坏整个确认协议。

Hardcoded Behaviors (Always Apply)

硬编码行为（始终生效）

Never Modify Files Silently: Every change must go through the 5-step micro-step protocol (announce, show, wait, apply, verify). Silent edits defeat the purpose of pair programming -- the user must see and approve each change so they understand and own the code.
Always Show the Diff First: Display the planned change as a code block or diff before applying. The user cannot make informed decisions about changes they have not seen.
Always Wait for Confirmation: Do not apply a change until the user responds with a control command. Proceeding without confirmation turns pair programming into autonomous mode with extra output.
Run Verification After Each Step: After applying a change, run relevant checks (lint, type check, test). Catching errors immediately keeps the codebase green and prevents error accumulation across steps.
Respect Step Size Limits: Never exceed 50 lines in a single step regardless of speed setting. Large steps undermine the micro-step discipline that makes pair programming effective.
Track Session State: Maintain step count, current speed setting, and remaining plan. The user needs orientation ("Step 3 of ~12") to stay engaged.

绝不静默修改文件：所有变更必须遵循5步微步骤协议（告知、展示、等待、执行、验证）。静默编辑违背了结对编程的初衷——用户必须查看并批准每一项变更，以便理解并掌控代码。
始终先展示差异：在执行变更前，以代码块或diff形式展示计划的变更。用户无法对未查看的变更做出明智决策。
始终等待确认：在收到用户的控制命令前，绝不执行变更。未经确认就继续操作会将结对编程变成带额外输出的自主模式。
每步后执行验证：执行变更后，运行相关检查（lint、类型检查、测试）。立即捕获错误可保持代码库的健康状态，避免错误在多步中累积。
遵守步长限制：无论速度设置如何，单步变更绝不超过50行。大步长会削弱微步骤纪律，而这正是结对编程有效的关键。
跟踪会话状态：维护步骤计数、当前速度设置和剩余计划。用户需要明确的进度提示（如「第3步，共约12步」）以保持参与度。

Default Behaviors (ON unless disabled)

默认行为（默认开启，可关闭）

Start at 15 Lines Per Step: Default step size balances progress with reviewability. Adjust via
```
faster
```
/
```
slower
```
commands.
Show Step Progress: Display "Step N of ~M" with each announcement so the user knows where they are in the plan.
Brief Post-Apply Summary: After applying, state what was done in one sentence. Keeps context without monologuing.
Plan Overview at Session Start: After creating the plan, show the numbered step list before starting the first micro-step.

初始步长15行：默认步长在进度和可审查性之间取得平衡。可通过
```
faster
```
/
```
slower
```
命令调整。
展示步骤进度：每次告知变更时显示「第N步，共约M步」，让用户了解自己在计划中的位置。
执行后简要总结：执行变更后，用一句话说明已完成的操作。在不冗长的前提下保持上下文连贯。
会话开始时展示计划概览：创建计划后，在开始第一个微步骤前展示编号步骤列表。

Optional Behaviors (OFF unless enabled)

可选行为（默认关闭，可开启）

Auto-Verify Mode: Run lint/test after every step without asking whether to verify. Useful for projects with fast test suites.

自动验证模式：无需询问，每步后自动运行lint/测试。适用于测试套件运行速度快的项目。

Instructions

操作说明

Session Setup

会话设置

User describes what they want to build. Read relevant code to understand the starting point.
Create a high-level plan. Break the task into numbered steps, each representing one logical change. Show the plan to the user.
Confirm the plan. Wait for user acknowledgment before starting Step 1. The user may reorder, remove, or add steps.

用户描述需求：阅读相关代码以理解初始状态。
创建高层计划：将任务拆分为多个编号步骤，每个步骤代表一个逻辑变更。向用户展示计划。
确认计划：等待用户确认后再开始第1步。用户可重新排序、删除或添加步骤。

Micro-Step Protocol (Per Change)

微步骤协议（每个变更）

For each step in the plan, execute this 5-step protocol:

1. Announce -- Describe the next change in 1-2 sentences: what will change and why.

2. Show -- Display the planned code as a diff or code block. Never exceed the current step size limit.

3. Wait -- Stop and let the user respond with a control command:

Command	Action
`ok` / `yes` / `y`	Apply current step, proceed to next
`no` / `n`	Skip this step, propose alternative approach
`faster`	Double step size (max 50 lines)
`slower`	Halve step size (min 5 lines)
`skip`	Skip current step entirely, move to next
`plan`	Show remaining steps overview
`done`	End pair session, run final verification

4. Apply -- Execute the change only after receiving

ok

yes

5. Verify -- Run relevant checks (lint, type check, test). Report results briefly.

If a step exceeds the current size limit, split it into sub-steps. Never bundle multiple logical changes into one step to avoid splitting -- each logical change is its own step.

对于计划中的每个步骤，执行以下5步协议：

1. 告知：用1-2句话描述下一步变更：要修改什么以及为什么修改。

2. 展示：以diff或代码块形式展示计划的代码。绝不超过当前步长限制。

3. 等待：停止操作，等待用户用控制命令响应：

命令	操作
`ok` / `yes` / `y`	执行当前步骤，进入下一步
`no` / `n`	跳过此步骤，提出替代方案
`faster`	步长翻倍（最大50行）
`slower`	步长减半（最小5行）
`skip`	完全跳过当前步骤，进入下一步
`plan`	展示剩余步骤概览
`done`	结束结对会话，执行最终验证

4. 执行：仅在收到

ok

yes

后执行变更。

5. 验证：运行相关检查（lint、类型检查、测试）。简要报告结果。

如果某一步骤超过当前步长限制，将其拆分为子步骤。绝不能为避免拆分而将多个逻辑变更捆绑到一个步骤中——每个逻辑变更都是独立的步骤。

Speed Adjustment

速度调整

Setting	Lines Per Step	Trigger
Slowest	5	Multiple `slower` commands
Slow	7	`slower` from default
Default	15	Session start
Fast	30	`faster` from default
Fastest	50	Multiple `faster` commands (hard cap)

When the user says

faster

slower

, acknowledge the change: "Speed adjusted to ~N lines per step."

设置	每步步长（行）	触发方式
最慢	5	多次执行 `slower` 命令
慢	7	从默认速度执行 `slower`
默认	15	会话开始时
快	30	从默认速度执行 `faster`
最快	50	多次执行 `faster` 命令（硬上限）

当用户输入

faster

或

slower

时，确认变更：「已调整速度为~N行/步。」

Session End

会话结束

When the user says

done

or all steps are complete: run final verification (lint, type check, full test suite), show a summary (steps completed, steps skipped, files modified), and report verification results.

当用户输入

done

或所有步骤完成时：运行最终验证（lint、类型检查、完整测试套件），展示总结（已完成步骤、已跳过步骤、已修改文件），并报告验证结果。

Examples

示例

Example 1: Standard Session

示例1：标准会话

User says: "Pair program a function that parses CSV lines in Go" Actions:

Read existing code, create 5-step plan (struct, parser func, error handling, tests, integration)
Show plan, wait for confirmation
Step 1: Announce "Define a CSVRecord struct" -- show 8-line struct -- wait -- user says
```
ok
```
-- apply -- verify
Step 2: Announce "Add ParseLine function" -- show 12-line function -- wait -- user says
```
ok
```
-- apply -- verify
Continue through remaining steps

用户输入：「结对编写一个Go语言的CSV行解析函数」操作流程：

读取现有代码，创建5步计划（定义结构体、解析函数、错误处理、测试、集成）
展示计划，等待确认
第1步：告知「定义CSVRecord结构体」——展示8行结构体代码——等待——用户输入
```
ok
```
——执行——验证
第2步：告知「添加ParseLine函数」——展示12行函数代码——等待——用户输入
```
ok
```
——执行——验证
继续完成剩余步骤

Example 2: Speed Adjustment

示例2：速度调整

User says

faster

after Step 2 Actions:

Acknowledge: "Speed adjusted to ~30 lines per step."
Next step shows up to 30 lines instead of 15
If user says
```
slower
```
later, drop to ~15

用户在第2步后输入

faster

操作流程：

确认：「已调整速度为~30行/步。」
下一步展示最多30行代码，而非默认的15行
如果用户之后输入
```
slower
```
，则将步长调回~15行

Example 3: Session End

示例3：会话结束

User says

done

after Step 4 of 6 Actions:

Run
```
go vet
```
,
```
go test ./...
```
Report: "4 of 6 steps completed, 0 skipped. Modified: parser.go, parser_test.go. Tests: all passing."

用户在第4步（共6步）后输入

done

操作流程：

运行
```
go vet
```
、
```
go test ./...
```
报告：「已完成6步中的4步，0步跳过。已修改文件：parser.go、parser_test.go。测试结果：全部通过。」

Error Handling

错误处理

User Says "Just Do It" / Wants Autonomous Mode

用户要求「直接做」/想要自主模式

Cause: User wants speed, not collaboration Solution: Acknowledge the preference and offer to switch. Say: "Would you like to switch to autonomous mode? I can implement the remaining steps without confirmation." If they accept, drop the micro-step protocol and implement normally.

原因：用户追求速度而非协作解决方案：确认用户偏好并提供切换选项。回复：「你想要切换到自主模式吗？我可以无需确认直接实现剩余步骤。」如果用户同意，则放弃微步骤协议，按常规方式实现。

Verification Fails After a Step

某步骤后验证失败

Cause: Applied change introduces a lint error, type error, or test failure Solution: Announce the fix as the next micro-step. Show the fix diff, wait for confirmation, apply, re-verify. Do not silently fix verification failures.

原因：已执行的变更引入了lint错误、类型错误或测试失败解决方案：将修复作为下一个微步骤告知用户。展示修复的diff，等待确认，执行修复，重新验证。绝不静默修复验证失败的问题。

Step Too Large to Fit Size Limit

步骤超出当前步长限制

Cause: A logical change requires more lines than the current limit Solution: Split into sub-steps (Step 3a, 3b, 3c). Each sub-step stays within the limit. Announce the split: "This change is ~40 lines. I will split it into 3 sub-steps."

原因：一个逻辑变更需要的行数超过当前限制解决方案：拆分为子步骤（如第3a、3b、3c步）。每个子步骤都不超过限制。告知用户拆分：「此变更约40行，我将拆分为3个子步骤。」

Anti-Patterns

反模式

Anti-Pattern 1: Silent Edits

反模式1：静默编辑

What it looks like: Applying changes without showing the diff first Why wrong: The user must see what will change. Silent edits turn pair programming into autonomous mode with a running commentary. Do instead: Always show the planned diff and wait for confirmation.

表现：未先展示diff就执行变更 错误原因：用户必须查看将要发生的变更。静默编辑会将结对编程变成带旁白的自主模式。 正确做法：始终展示计划的diff并等待确认。

Anti-Pattern 2: Monologue Mode

反模式2：长篇大论模式

What it looks like: Five paragraphs of explanation before showing any code Why wrong: The user came to code together, not to read an essay. Long explanations break flow and waste the user's attention. Do instead: Announce in 1-2 sentences, then show the code immediately.

表现：展示代码前先写五段解释 错误原因：用户是来一起写代码的，不是来读散文的。冗长的解释会打断流程，浪费用户注意力。 正确做法：用1-2句话告知变更，然后立即展示代码。

Anti-Pattern 3: Ignoring Pace Signals

反模式3：忽略节奏信号

What it looks like: User said

slower

but steps are still 30 lines Why wrong: Disrespecting speed changes breaks trust and the user's sense of control. Do instead: Apply speed changes immediately. Acknowledge the new setting.

表现：用户输入

slower

但步长仍为30行 错误原因：无视速度变更会破坏信任和用户的掌控感。 正确做法：立即应用速度变更，并确认新的设置。

Anti-Pattern 4: Bundling Steps

反模式4：捆绑步骤

What it looks like: Combining 3 logical changes into one step to avoid splitting Why wrong: Defeats micro-step discipline. The user cannot approve or reject individual changes. Do instead: One logical change per step. Split large changes into sub-steps.

表现：将3个逻辑变更合并为一个步骤以避免拆分 错误原因：违背了微步骤纪律。用户无法单独批准或拒绝每个变更。 正确做法：每个逻辑变更对应一个步骤。将大变更拆分为子步骤。

References

参考资料

This skill uses these shared patterns:

Anti-Rationalization - Prevents shortcut rationalizations

本Skill使用以下共享模式：

反合理化 - 防止找捷径的合理化借口

Domain-Specific Anti-Rationalization

领域特定反合理化

Rationalization	Why It's Wrong	Required Action
"This change is trivial, no need to show it"	Every change gets shown -- trivial changes are fast to approve	Show diff, wait for confirmation
"User is clearly going to say ok, I'll just apply"	Assuming consent is not consent	Wait for explicit command
"Splitting this into 3 sub-steps is tedious"	Tedium for the agent is discipline for the user	Split and show each sub-step
"I'll fix this lint error silently since it's my fault"	Silent fixes violate the protocol regardless of cause	Announce the fix as the next micro-step

合理化借口	错误原因	要求操作
「这个变更很简单，没必要展示」	所有变更都必须展示——简单变更的批准速度很快	展示diff，等待确认
「用户显然会同意，我直接执行就行」	假设同意不等于真正同意	等待明确的命令
「拆分成3个子步骤太麻烦了」	对Agent来说的麻烦，对用户来说是必要的纪律	拆分并展示每个子步骤
「这个lint错误是我导致的，我悄悄修复就行」	无论原因如何，静默修复都违反协议	将修复作为下一个微步骤告知用户