Fixflow

Overview

• 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.

Trigger Cues

• 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.

Workflow

1. Define Ready Criteria (DoR)

See shared delivery base:

references/delivery-base.md

2. Build Complete Plan Before Editing

See shared delivery base:

references/delivery-base.md

3. Add BDD/TDD Layer When Needed

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

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

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

references/bdd-guide.md

4. Execute Step by Step

See shared delivery base:

references/delivery-base.md

per_step

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

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

See shared delivery base:

references/delivery-base.md

6. Validate with Test Matrix (Verification Loop)

See shared delivery base:

references/delivery-base.md

7. Commit and Handoff

See shared delivery base:

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.