fixflow

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Fixflow

Overview

概述

Use this skill to deliver end-to-end engineering work in one run:

Plan fully.
Execute in strict sequence.
Validate continuously.
Use explicit commit policy (
```
per_step
```
default;
```
final_only
```
/
```
milestone
```
when requested).
Add BDD behavior specs when requested or when requirements are ambiguous.

使用该技能可一次性完成端到端的工程工作：

制定完整计划。
严格按顺序执行。
持续验证。
使用明确的提交策略（默认
```
per_step
```
；按需使用
```
final_only
```
/
```
milestone
```
）。
当用户要求或需求模糊时，添加BDD行为规范。

Trigger Cues

触发条件

Trigger this skill when the user asks for one or more of:

Full plan + sequential execution.
No backward compatibility.
Test everything before handoff.
Commit after completion or commit before each next step.
Behavior-driven delivery (BDD) or acceptance scenarios.

当用户提出以下一项或多项需求时，触发该技能：

完整计划+顺序执行。
无需向后兼容。
交付前完成所有测试。
完成后提交或每步执行前提交。
行为驱动交付（BDD）或验收场景。

Workflow

工作流

1. Define Ready Criteria (DoR)

1. 定义就绪标准（DoR）

See shared delivery base:
references/delivery-base.md

参考共享交付基础文档：
references/delivery-base.md

2. Build Complete Plan Before Editing

2. 编写代码前制定完整计划

See shared delivery base:
references/delivery-base.md

参考共享交付基础文档：
references/delivery-base.md

3. Add BDD/TDD Layer When Needed

3. 按需添加BDD/TDD层

Use BDD if user requests it, or if requirements are unclear.

若用户要求或需求不明确，使用BDD。

3.0 TDD Mode (RED -> GREEN -> IMPROVE)

3.0 TDD模式（RED -> GREEN -> IMPROVE）

When user requests TDD or test-driven delivery:

RED — Write a failing test first
- Extract testable behavior from requirements
- Write minimal test case asserting expected behavior
- Run test, confirm it fails (red)
- If test passes unexpectedly -> requirement already met or test is wrong
GREEN — Write minimal implementation
- Write just enough code to make the test pass
- No extra improvements, no "while I'm here" changes
- Run test, confirm it passes (green)
IMPROVE — Refactor under green tests
- Eliminate duplication, improve naming, simplify logic
- Run tests after each refactor to confirm no regression
- Refactoring must not change external behavior

Coverage target: 80% line coverage for new code, 100% for critical paths.

Trigger cues for TDD mode:

User says "TDD", "test-driven", "test first"
User says "write tests before code"
Requirements are well-defined with clear inputs/outputs

For BDD Lite, Scenario Quality Checklist, Scenario Outline, and Test Layer mapping, see the shared reference:

references/bdd-guide.md

当用户要求TDD或测试驱动交付时：

RED — 先编写一个失败的测试
- 从需求中提取可测试的行为
- 编写最小化测试用例，断言预期行为
- 运行测试，确认测试失败（红色状态）
- 若测试意外通过 -> 需求已满足或测试存在问题
GREEN — 编写最小化实现代码
- 仅编写足够让测试通过的代码
- 不做额外优化，不添加“顺带完成”的变更
- 运行测试，确认测试通过（绿色状态）
IMPROVE — 在测试通过的前提下重构代码
- 消除重复代码，优化命名，简化逻辑
- 每次重构后运行测试，确认无回归问题
- 重构不得改变外部行为

覆盖率目标：新代码行覆盖率达到80%，关键路径达到100%。

TDD模式触发条件：

用户提及"TDD"、"test-driven"、"test first"
用户要求"先写测试再写代码"
需求定义清晰，有明确的输入/输出

关于BDD简化模式、场景质量检查表、场景大纲及测试层映射，请参考共享文档：

references/bdd-guide.md

4. Execute Step by Step

4. 分步执行

See shared delivery base:
references/delivery-base.md

For

per_step

(default):

Stage only files for current step.
Run step-level checks.
Commit immediately after step checks pass.
Record step -> commit hash mapping.

参考共享交付基础文档：
references/delivery-base.md

对于默认的

per_step

模式：

仅暂存当前步骤的文件。
运行步骤级检查。
步骤检查通过后立即提交。
记录步骤与提交哈希的映射关系。

5. Apply No-Backward-Compatibility Mode (When Requested)

5. 启用无向后兼容模式（按需）

See shared delivery base:
references/delivery-base.md

参考共享交付基础文档：
references/delivery-base.md

6. Validate with Test Matrix (Verification Loop)

6. 用测试矩阵验证（验证循环）

See shared delivery base:
references/delivery-base.md

参考共享交付基础文档：
references/delivery-base.md

7. Commit and Handoff

7. 提交并交付

See shared delivery base:
references/delivery-base.md

参考共享交付基础文档：
references/delivery-base.md

Guardrails

约束规则

Do not stop at planning when implementation is expected.
Do not leave partially completed plan steps.
Do not defer required testing when it can be run now.
Do not default to
```
final_only
```
; use
```
per_step
```
unless user explicitly asks otherwise.
Do not move to the next plan step before committing when
```
commit_policy = per_step
```
.
Do not claim compatibility if user explicitly requested no compatibility work.
Do not include unrelated pre-existing dirty files in commits.
Do not hand off without concrete validation evidence.

若用户期望实现功能，不得仅停留在规划阶段。
不得留下未完成的计划步骤。
若当前可运行测试，不得推迟必要的测试环节。
默认使用
```
per_step
```
模式，除非用户明确要求，否则不使用
```
final_only
```
。
当
```
commit_policy = per_step
```
时，未提交前不得进入下一个计划步骤。
若用户明确要求不做兼容工作，不得声称具备兼容性。
提交时不得包含无关的已修改文件。
交付时必须提供具体的验证证据。