Back to Details

fixflow

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Fixflow

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:
  1. 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
  2. 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)
  3. 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或测试驱动交付时：
  1. RED — 先编写一个失败的测试
    • 从需求中提取可测试的行为
    • 编写最小化测试用例，断言预期行为
    • 运行测试，确认测试失败（红色状态）
    • 若测试意外通过 -> 需求已满足或测试存在问题
  2. GREEN — 编写最小化实现代码
    • 仅编写足够让测试通过的代码
    • 不做额外优化，不添加“顺带完成”的变更
    • 运行测试，确认测试通过（绿色状态）
  3. 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
    时，未提交前不得进入下一个计划步骤。
  • 若用户明确要求不做兼容工作，不得声称具备兼容性。
  • 提交时不得包含无关的已修改文件。
  • 交付时必须提供具体的验证证据。