software-development

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Software Development: Extreme Programming Workflow

软件开发：极限编程（XP）工作流

The Workflow

工作流

📋 PLAN     → Discuss and break down the feature
🔴 DEVELOP  → TDD cycle (red → green → refactor → review)
💾 COMMIT   → Save working state
🔁 ITERATE  → Next task or proceed to complete
✅ COMPLETE → Suggest retrospective

The DEVELOP cycle is a task's Definition of Done: no task is complete until the review step passes. Review is inside the cycle, not after it.

📋 PLAN     → Discuss and break down the feature
🔴 DEVELOP  → TDD cycle (red → green → refactor → review)
💾 COMMIT   → Save working state
🔁 ITERATE  → Next task or proceed to complete
✅ COMPLETE → Suggest retrospective

DEVELOP环节是任务的完成定义：只有通过评审步骤，任务才算完成。评审是环节内的步骤，而非环节之后的操作。

Phase 1: Planning (📋 PLAN) — Interactive

第一阶段：规划（📋 PLAN）—— 交互式

Understand and decompose the feature before writing any code. Pin down any unfamiliar domain terms before coding.

Follow this sequence: DISCUSS → CLARIFY → SLICE → FALSIFY → CONFIRM. See planning reference for detailed steps and examples.

在编写任何代码之前，先理解并分解功能。在编码前明确所有不熟悉的领域术语。

遵循以下流程：讨论 → 澄清 → 拆分 → 验证 → 确认。详细步骤及示例请参考规划参考文档。

CLARIFY — Surface Hidden Premises

澄清 — 挖掘隐藏前提

Requirements are arguments in disguise — stated conclusions resting on unstated premises. Restate the requirement as "Given [premises], then [conclusion]" and ask what premises are missing. Challenge assumptions — especially those that feel obvious. STOP until questions are answered.

Run the premise checklist in planning reference

CLARIFY

, including the context-specific cases (UI, test seam, date-range membership, codegen, how to present the questions) before CONFIRM.

需求本质是伪装的论证——陈述的结论基于未明确的前提。将需求重述为"给定[前提]，则[结论]"，并找出缺失的前提。挑战假设——尤其是那些看似显而易见的假设。暂停，直到所有问题得到解答。

在确认前，执行规划参考文档中

CLARIFY

部分的前提检查清单，包括特定上下文场景（UI、测试接缝、日期范围归属、代码生成、问题呈现方式）。

SLICE — Break Into Tasks

拆分 — 分解为任务

Tasks must be vertical (end-to-end functionality), small (one TDD cycle), ordered (dependency first, then value), and testable (clear acceptance criteria). Slice by behaviour, not by implementation layer.

任务必须是垂直的（端到端功能）、小型的（一个TDD周期即可完成）、有序的（先处理依赖项，再处理价值项）、可测试的（明确验收标准）。按行为拆分，而非按实现层拆分。

FALSIFY — Test Your Understanding

验证 — 检验理解是否正确

Ask: "What scenario would prove this understanding wrong?" If you can't think of one, that's a warning sign — not a green light.

问自己："哪种场景能证明我的理解是错误的？"如果想不出任何场景，这是一个警告信号——而非绿灯。

CONFIRM — Agree on Plan

确认 — 达成规划共识

Summarise, present ordered task list, STOP — explicitly agree on the first task.

总结并呈现有序的任务列表，暂停——明确就首个任务达成一致。

Planning Output Format

规划输出格式

undefined

undefined

Tasks for [Feature]

[Task description] — [acceptance criteria] — DoD: new tests for new behaviour + affected-submodule tests green (whole project if no submodules) + fix-loop clean + for UI tasks, feature exercised in a browser
[Task description] — [acceptance criteria] — DoD: new tests for new behaviour + affected-submodule tests green (whole project if no submodules) + fix-loop clean + for UI tasks, feature exercised in a browser

Assumptions surfaced: [key premises uncovered during clarify/falsify] First task: [Task 1 description]


The Definition of Done is identical for every task. A task cannot be ticked without it.

---

[Task description] — [acceptance criteria] — DoD: new tests for new behaviour + affected-submodule tests green (whole project if no submodules) + fix-loop clean + for UI tasks, feature exercised in a browser
[Task description] — [acceptance criteria] — DoD: new tests for new behaviour + affected-submodule tests green (whole project if no submodules) + fix-loop clean + for UI tasks, feature exercised in a browser

Assumptions surfaced: [key premises uncovered during clarify/falsify] First task: [Task 1 description]


每个任务的完成定义（DoD）都是相同的。未满足完成定义的任务不能被标记为完成。

---

Phase 2: Development (🔴 DEVELOP) — Interactive

第二阶段：开发（🔴 DEVELOP）—— 交互式

Each task runs a four-step cycle; all four must complete before the task is done.

每个任务都要经历四个步骤的循环；必须完成全部四个步骤，任务才算完成。

Step 1: 🔴 Red — Failing Test

步骤1：🔴 红 — 编写失败测试

Write a failing test for the next behaviour. If the change threads through multiple call sites, write a failing test per call site before going green — a helper-level test alone can leave caller wiring silently wrong. Use the appropriate language skill. See development reference.

为下一个行为编写失败的测试。如果变更涉及多个调用点，在实现测试通过前，为每个调用点编写失败测试——仅编写辅助层测试可能会导致调用者的逻辑连接出现隐性错误。使用合适的语言技能。详情请参考开发参考文档。

Step 2: 🟢 Green — Make It Pass

步骤2：🟢 绿 — 让测试通过

Surgical: touch only what the test requires. Match existing style. No drive-by edits to adjacent code, comments, or formatting. Every changed line should trace to the failing test. Broader cleanup belongs in Refactor.

Public signature changes: if you change a public function signature, read every caller before calling green. Compile-passing is not enough — see development reference

✅ VERIFY

精准操作：仅修改测试要求的内容。匹配现有代码风格。不得随意修改相邻代码、注释或格式。每一行修改都应追溯到对应的失败测试。更广泛的代码清理属于重构环节。

公共签名变更：如果修改了公共函数签名，在标记测试通过前，检查所有调用者。仅编译通过是不够的——请参考开发参考文档中的

✅ VERIFY

部分。

Step 3: 🔵 Refactor

步骤3：🔵 重构

Clean up while the domain is fresh and tests are green. Continue refactoring while behaviour stays green; ask only when choosing between materially different cleanup directions or expanding scope. See refactor reference.

Public signature changes: same rule as Green — after a signature change, read every caller. Refactor is where this most often bites.

在对业务逻辑仍清晰、测试全部通过的情况下进行代码清理。在保持行为不变的前提下持续重构；仅在需要选择不同的清理方向或扩大范围时才询问用户。详情请参考重构参考文档。

公共签名变更：与绿阶段规则相同——修改签名后，检查所有调用者。重构是最容易出现此类问题的环节。

Step 4: 🔍 Review — Fix-Loop

步骤4：🔍 评审 — 修复循环

Not optional. Only skip for pure non-code edits (comments, docs-only changes) and state the skip explicitly. For one-line build/config wiring with no production logic, targeted verification may replace fix-loop if the final response states the skip and names the command run.

Delegate to the
fix-loop
skill — runs code-reviewer → fixer until critical findings resolve (or the iteration cap hits). The reviewer's remit includes simplification opportunities, so fresh-eyes cleanup happens here. fix-loop already runs code-reviewer; don't also invoke code-reviewer standalone on the same diff.
If unresolved critical findings or test regressions remain: stop and surface to the user. The task is not done.
Non-critical findings (Warning / Suggestion): list them in one line each to the user before COMMIT and ask if any should be addressed now. Cheaper to fold in than to revisit in a follow-up commit.

Scope touches new behaviour without new tests is a critical finding, not a suggestion — even when sibling code lacks tests. Precedent is not permission.

DoD must cover edge cases the reviewer flagged as critical, not only the happy path.

Only after step 4 passes is the task complete. Proceed to COMMIT.

不可省略。仅在纯非代码编辑（注释、仅文档变更）时可跳过，并需明确说明跳过原因。对于无生产逻辑的单行构建/配置代码，若最终回复中说明跳过原因并列出执行的命令，可针对性验证替代修复循环。

委托给
fix-loop
技能——运行代码评审→修复流程，直到关键问题解决（或达到迭代上限）。评审者的职责包括寻找简化机会，因此新鲜视角的代码清理会在此环节进行。fix-loop已包含代码评审，请勿对同一代码差异单独调用代码评审技能。
**若仍存在未解决的关键问题或测试回归：**暂停并告知用户。任务未完成。
**非关键问题（警告/建议）：**在提交前逐条列出给用户，并询问是否需要立即处理。与其后续提交再处理，不如现在一并解决更高效。

仅修改新行为但未添加新测试属于关键问题，而非建议——即使同类代码没有测试也是如此。先例不能成为借口。

完成定义必须覆盖评审者标记为关键的边缘场景，而不仅仅是常规路径。

只有通过步骤4后，任务才算完成。进入提交环节。

Phase 3: Commit (💾 COMMIT) — Autonomous

第三阶段：提交（💾 COMMIT）—— 自主执行

Run the project's canonical commit verification command (compile + lint + test) — must be green. Find it from README/CONTRIBUTING, build scripts, package manager scripts, Makefile, or workspace instructions. No red commits; no pushes without a green check on every commit. Before running broad commit checks, inspect
```
git status --short --branch
```
and the branch diff. If the check will include substantial pre-existing branch changes outside the current task, say so and prefer targeted verification unless the user explicitly asks for the full check. If the user interrupts a broad check and asks to commit/push anyway, proceed only after targeted verification and record the interrupted check in the PR/final summary.
Summarise what will be committed and ask the user to confirm.
Commit directly. If the user, repository, or agent platform specifies a co-author trailer, include that exact trailer. Otherwise use the current agent's appropriate public attribution if known; do not hard-code another agent's identity.

运行项目的标准提交验证命令（编译 + 代码检查 + 测试）——必须全部通过。从README/CONTRIBUTING文档、构建脚本、包管理器脚本、Makefile或工作区说明中找到该命令。禁止提交失败的代码；未通过验证的提交不得推送。在运行全面提交检查前，查看
```
git status --short --branch
```
和分支差异。如果检查会包含当前任务之外的大量分支已有变更，请告知用户，除非用户明确要求全面检查，否则优先进行针对性验证。如果用户中断全面检查并要求直接提交/推送，仅在完成针对性验证后执行，并在PR/最终总结中记录中断的检查。
总结即将提交的内容，并请求用户确认。
直接提交。如果用户、仓库或Agent平台指定了共同作者信息，请添加该信息。否则使用当前Agent的公开标识（若已知）；不得硬编码其他Agent的身份。

Phase 4: Iterate (🔁 ITERATE) — Interactive

第四阶段：迭代（🔁 ITERATE）—— 交互式

Mark the task done (only if step 4 of DEVELOP passed). Adjust remaining tasks if needed. Return to Phase 2, or proceed to Phase 5 if none remain.

标记任务完成（仅当DEVELOP阶段的步骤4通过时）。如有需要，调整剩余任务。返回第二阶段，或若无剩余任务则进入第五阶段。

Phase 5: Complete (✅ COMPLETE) — Interactive

第五阶段：完成（✅ COMPLETE）—— 交互式

Feature done, all tasks committed. Before closing out:

Suggest a retrospective. Ask the user if they'd like to run the

retrospective

skill to surface gaps in this workflow and propose edits. This is the final step — do not skip it.

功能开发完成，所有任务已提交。在结束前：

建议进行回顾总结。询问用户是否需要运行

retrospective

技能，以找出此工作流中的不足并提出修改建议。这是最后一步——请勿跳过。

Phase Transitions

阶段转换

Announce clearly when switching:

📋 PLAN → Starting feature discussion
🔴 DEVELOP → Writing failing test for [behaviour]
🟢 DEVELOP → Making test pass
🔵 REFACTOR → Improving [aspect]
🔍 REVIEW → Delegating to fix-loop
💾 COMMIT → Running commit verification, then committing approved changes
🔁 ITERATE → Reviewing remaining tasks and moving to next task
✅ COMPLETE → Feature done

切换阶段时需明确告知：

📋 PLAN → Starting feature discussion
🔴 DEVELOP → Writing failing test for [behaviour]
🟢 DEVELOP → Making test pass
🔵 REFACTOR → Improving [aspect]
🔍 REVIEW → Delegating to fix-loop
💾 COMMIT → Running commit verification, then committing approved changes
🔁 ITERATE → Reviewing remaining tasks and moving to next task
✅ COMPLETE → Feature done

Red Flags — unverified ground

危险信号 — 未验证的依据

The same mistake wears many costumes: treating an unchecked claim as confirmed, then building on it. When you catch yourself about to rely on any of these, do the grounding action first:

You're about to trust…	Grounding action before continuing
A memory note, comment, or ticket claim about how the code works	Open the source and confirm it still holds — notes and tickets go stale
A test run that passed	Confirm it actually exercised the new behaviour — a name-filtered or happy-path-only run can pass while covering nothing
Green / it compiled / the tool said "success"	Inspect the real effect: a success flag whose return value was never checked, a process that reported "started" but isn't serving, or one output rendered in two places — all look fine while being wrong
"The rename/move is done"	grep the old name, path, and package across code, docs, and README in one pass — doc strings and README links lag code moves and otherwise surface at review

If you can't ground it, say so — don't proceed on the assumption.

同样的错误有多种表现形式：将未验证的主张视为已确认，然后在此基础上开展工作。当发现自己依赖以下任何一项时，请先执行验证操作：

你即将依赖…	继续前需执行的验证操作
关于代码工作方式的记忆笔记、注释或工单描述	查看源代码并确认其仍然有效——笔记和工单会过时
通过的测试运行	确认测试确实覆盖了新行为——仅按名称过滤或仅测试常规路径的运行可能看似通过，但实际未覆盖任何内容
测试通过/编译成功/工具显示"成功"	检查实际效果：返回值未被检查的成功标记、报告"已启动"但未提供服务的进程、或在两处渲染的同一输出——这些情况看起来正常，但实际存在问题
"重命名/移动已完成"	一次性搜索代码、文档和README中的旧名称、路径和包——文档字符串和README链接往往滞后于代码移动，否则会在评审时暴露

如果无法验证，请告知用户——不要基于假设继续。