A disciplined, brownfield-first feature pipeline for Claude Code: recon → grill → design → plan → act → verify → review, orchestrated end-to-end by /krukit-flow with stage gates, lossless resume, a living project constitution, and a trace-driven self-improvement loop.
Status: early public release. Built and used daily by the author; rough edges expected — feedback is the point. See
ROADMAP.md.
---
config:
theme: base
themeVariables:
cScale0: "#2a78d6"
cScale1: "#008300"
cScale2: "#1baf7a"
cScale3: "#eda100"
radar:
curveOpacity: 0.12
graticuleColor: "#c3c2b7"
axisColor: "#898781"
---
radar-beta
title Framework profiles (1-10, higher is better)
axis sv["Self-verification"], zr["Zero rework"], lr["Lossless resume"], ho["Hands-off"], fp["First-pass"]
axis ad["Artifact durability"], vs["Versatility"], te["Token efficiency"], sl["Speed / low ceremony"], ee["Ease of entry"]
curve k["krukit-flow"]{9, 9, 9, 8, 8, 8, 6, 6, 5, 6}
curve p["pocock"]{3, 4, 2, 4, 5, 3, 8, 9, 9.5, 9}
curve s["superpowers"]{7, 7, 4, 6, 7, 4, 9, 7, 7, 8}
curve g["spec-kit"]{6, 8, 7, 7, 8, 10, 4, 4, 3, 5}
max 10
min 0
graticule polygon
Higher is better on every axis (scale 1-10, absolute). Scores are the author's calibrated judgment from daily use of all four frameworks — not telemetry (no framework publishes head-to-head numbers; telemetry is on the roadmap). "Speed" and "low ceremony" are merged because they correlated perfectly across all four tools; "lossless resume" measures whether an interrupted pipeline resumes without losing state (flow-state.md).
The contours have different shapes, not different sizes: krukit-flow and pocock are near-perfect opposites. Each framework optimizes for a different price of error. Krukit's bet: buy self-verification and zero-rework with ceremony, then use routing to avoid paying that ceremony on small tasks.
krukit-flow routes a task (trivial / direct / fix / full / external-spec), then runs the stage skills in order — enforcing each stage's gate, recording state in flow-state.md, and supporting resume and per-stage skips. The orchestrator and the recon stage are original; the connective tissue (constitution, reopen-rule, verbatim gate-evidence, trace-driven krukit-improve) is what differentiates it from a plain command chain.
The design was hardened against 12 pain points collected from the public GitHub issue trackers of six workflow tools (spec-kit, superpowers, OpenSpec, BMAD, Taskmaster, GSD) in June 2026 — e.g. the most-reacted pain in that collection (one-way pipeline with no sanctioned backward path) is addressed by the reopen rule.
- Model: the
fullroute needs a Sonnet-class or stronger model. Below that bar the router caps the route atfixin autonomous runs and warns in interactive ones — weaker models misroute and rubber-stamp verification in our bench traces. - Harness: a skills-capable Claude Code (or compatible) harness with arrow-key questions (
AskUserQuestion) for interactive gates. Headless runs use autonomous mode (see krukit-flow).
git clone https://github.com/Todmy/krukit-flow
cp -r krukit-flow/skills/* ~/.claude/skills/Restart Claude Code, then run /krukit-flow on any feature task. The router will size the pipeline to the task — small changes stay small.
| Skill | Role |
|---|---|
krukit-flow |
Stage 0 — orchestrator |
krukit-recon |
Stage 1 — map the existing code before design |
krukit-grill |
Stage 2 — interrogate the idea against recon + domain model |
krukit-design |
Stage 3 — design doc + constitution check |
krukit-plan |
Stage 4 — bite-sized TDD implementation plan |
krukit-act |
Stage 5 — implement task-by-task with TDD |
krukit-verify |
Stage 6 — evidence-based verification + reality-check |
krukit-review |
Stage 7 — fresh-eyes review + branch finish |
krukit-rules |
Companion — living project constitution |
krukit-improve |
Companion — trace-driven skill improvement |
krukit-discovery |
Companion — pre-flow problem-space interrogation |
A full run in one session grows its context monotonically — measured across 25 runs it reaches ~580K by stage 7, and every API call after that pays to re-read the whole transcript. Stage boundaries are lossless (each stage declares its inputs as file paths and creates flow-state.md when invoked standalone), so the run can be cut into three sessions with /clear between them:
| Session | Skill | Stages | ~calls | ~context growth |
|---|---|---|---|---|
| A | krukit-think |
recon → grill → design | 216 | +164K |
| B | krukit-build |
plan → act | 263 | +174K |
| C | krukit-ship |
verify → review | 207 | +152K |
Each skill ends by naming the next command, so the chain is krukit-think <slug> → /clear → krukit-build <slug> → /clear → krukit-ship <slug>.
The grouping is not arbitrary. grill → design must stay together — grill's only durable output is a prose summary in flow-state.md, so it is the single boundary that loses information across a reset. plan → act stay together because plan is the cheapest stage in the pipeline (37 calls) and a dedicated session for it costs more in prefix rebuild than it saves. Running krukit-flow end-to-end in one session remains fully supported and is the right choice for small features.
Krukit exists because of tools I used heavily and genuinely rate:
- Spec Kit (GitHub) — spec-driven development done properly: write the spec down first, treat it as the deliverable.
- superpowers by Jesse Vincent — a deep, composable library of engineering-discipline skills: brainstorming, TDD, systematic debugging, verification, code review.
- Matt Pocock's skills — sharp interrogation methodology (grill-with-docs) for pressure-testing a plan before you build it.
All three are excellent and worth your time. I ran real features through them, then went and read what people actually complain about in their issue trackers — and built around what those complaints point at: one orchestrator plus stage skills that each fit in a single read — no separate CLI, no template pack, no config surface — while keeping the discipline that makes those tools good.
Pains collected from the public issue trackers of six workflow tools (spec-kit, superpowers, OpenSpec, BMAD, Taskmaster, GSD), June 2026:
- One-way pipeline. Once you're implementing, there's no sanctioned way back when the work proves the design wrong. The most-reacted pain in that collection.
- No grounding in the existing code. Specs and clarifying questions get written without reading the repo, so brownfield assumptions slip straight through to implementation.
- Capped, code-blind clarification. A fixed question limit, and no look at the actual source behind the answers.
- No feedback loop. Artifacts freeze at planning time; what you learn while building never flows back into the design.
- Silent gate approvals. "Did the user actually approve this?" gets answered by the model, not the user.
Krukit's takes: a brownfield recon pass before any design, a reopen rule so verification can send you back with the design and plan updated, gate approvals that require a real quoted user reply, and routing that keeps small changes small instead of forcing full ceremony.
This is an early release and your experience report is the most valuable thing you can give it. Open an issue with:
- what broke or confused you,
- what felt heavier than it should,
- what you'd steal for your own workflow.
MIT © 2026 Dmytro Tolok