mcpField
F
fixflow

fixflow

github.com/majiayu000Development28850 installsUpdated 1d ago
Repository

About fixflow

fixflow is a skill for coding agents handling end-to-end engineering work. It requires a complete plan, sequential implementation, ongoing validation, and an explicit commit policy, with BDD or TDD added when appropriate.

Key features

  1. 01Plan fully before editing
  2. 02Execute sequentially with ongoing checks
  3. 03Commit per step and record mappings
  4. 04Add BDD or TDD when needed
  5. 05Validate before handoff

Use cases

  1. 01Deliver engineering work from plan through implementation
  2. 02Commit each step after its checks pass
  3. 03Clarify ambiguous requirements with behavior scenarios
  4. 04Require test evidence before handoff

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/majiayu000/spellbook --skill fixflow

After installing, type/fixflowin Claude Code to confirm it loaded.

Bundled filesreferences/bdd-guide.mdreferences/delivery-base.md

Details

From the project README

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.

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.

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

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:

references/bdd-guide.md

4. Execute Step by Step

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

Comments

Markdown supported