fixflow

name	fixflow
description	Execute coding tasks with a strict delivery workflow: build a full plan, implement one step at a time, run tests continuously, and commit by default after each step (`per_step`). Support explicit commit policy overrides (`final_only`, `milestone`) and optional BDD (Given/When/Then) when users ask for behavior-driven delivery or requirements are unclear.

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.

When to Activate

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.

Red Flags

• Execution starts while requirements, non-goals, or compatibility policy are still ambiguous.
• Multiple feature steps are implemented before any mapped test command runs.
• Commit policy is implicit, changes mid-run, or ignores user override.

Checklist

• Pin the commit policy before editing.
• Map each feature step to at least one concrete validation command.
• Complete the current step, run its checks, and record status before starting the next step.

Routing Contract Integration

Use the canonical router in workflows/references/routing-contract.md.

Fixflow can start directly when either of these is true:

• upstream readiness resolved to execute_direct
• a planning workflow already emitted a handoff that preselects Fixflow for execution

Fixflow must not start execution when either of these is true:

• upstream readiness resolved to clarify_first
• upstream readiness resolved to plan_first and no execution handoff exists yet

When Fixflow receives a planning handoff, it must honor all required keys:

• mode
• artifacts
• runtime_pinning_snapshot
• verification_owner
• stop_conditions
• lane_map

If lane_map does not assign Fixflow-owned work clearly, stop and clarify before editing.

If Fixflow delegates any task to a child agent or parallel worker, it must use workflows/references/delegation-contract.md and keep a single integration owner for shared outputs.

Workflow

1. Define Ready Criteria (DoR)

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

2. Build Complete Plan Before Editing

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

3. Add BDD/TDD Layer When Needed

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

3.0 TDD Mode (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:

workflows/references/bdd-guide.md

4. Execute Step by Step

See shared delivery base: workflows/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.

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

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

6. Validate with Test Matrix (Verification Loop)

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

7. Commit and Handoff

See shared delivery base: workflows/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.

Red Flags

• Planning as a substitute for delivery - Fixflow is for executing when readiness is already resolved.
• Advancing with red checks - build or focused test failures must be fixed before the next step.
• Bundling unrelated dirty files - commits must include only the current step's owned files.
• Skipping commit policy - per_step is the default unless the user explicitly selects another policy.

Checklist

• Confirm routing readiness is execute_direct or a valid handoff selected Fixflow.
• Build a step plan with owned files, checks, and stop conditions.
• Run step-level verification before moving to the next step.
• Commit per step unless the user requested final_only or milestone.
• Report fresh validation evidence in the handoff.