Keel Dev — development conductor

User-invoked conductor, not an auto-firing router. You reach for it by name when you're doing dev work; it orchestrates the pipeline and pulls in the right specialist per phase. It carries zero context cost until invoked. It writes no product code itself — the phase skills do that.

Backbone = Pocock (mattpocock/skills). One default per job; a short list of opt-in power-tools. keel-v2 governs everything.

Deference — keel-v2 is the arbiter

Scan the eleven danger surfaces first, record the lane line (Rigor: FAST/HEAVY — …). keel-v2's /review tripwires, a11y, design conformance, and human gates outrank every phase and every power-tool. A power-tool's own ethos is subordinate to keel-v2.

Comprehension — graphify-first

To understand the code (how X works, what depends on Y, data flow, blast radius, architecture) query graphify (query/path/explain) instead of grep+read — it returns a targeted subgraph, not a dozen file reads. Grep only for an exact known string/symbol, a tiny throwaway scope with no graphify-out/ yet, or an area just edited (graph may be stale). Default graphify; grep is the deliberate exception. For facts outside the repo (a library's API, a vendor's docs) use Pocock research — primary sources, findings saved as Markdown in the repo. Topic/market research belongs to keel-research.

The pipeline (spine default · power-tools opt-in)

Spine skills load as mattpocock-skills:<name>. A bare name works unless Claude Code ships a built-in with the same name — then invoke the prefixed form, or the built-in runs instead. Today that is mattpocock-skills:code-review: the built-in /code-review hunts bugs in a diff but has no Standards/Spec axes. Phase 5 runs both: they check different things, and neither replaces the other.

Phase exits — advance only when the line is true

• Align: the problem, success metric and scope fit in a paragraph the human has confirmed.
• Map: every decision ticket is resolved or parked in Open decisions; nothing left blocks the build.
• Spec: the spec names every behaviour to build and every one deliberately left out; on HEAVY it carries §Architecture and §Threat model (conventions §4).
• Decompose: each ticket is a vertical slice with acceptance criteria and blocking edges; the frontier is non-empty.
• Build: the ticket's acceptance criteria pass under tests; the slice is ticked in 00-status.md.
• Review: both axes report no open findings above nit, and the built-in /code-review bug pass ran on the final diff with each finding fixed or explicitly waived by the human.
• Verify/QA: every acceptance criterion has pass/fail evidence (the keel-qa report; keel-verify output for non-UI).
• Ship: every Ship-checklist line has evidence; the human has approved; nothing deploys on an agent's say-so.

Stack specialists (opt-in · pinned · name them explicitly)

Install only in projects on that stack (./install.sh supabase-agent-skills; it is parked, so a lane install skips it). Don't rely on them auto-triggering: Supabase's own evals show its skill activates in roughly 60% of relevant tasks, so name it at the phases below.

They teach how to do it correctly; Keel's gates still decide whether it may touch live data. In particular, iterate with execute_sql/supabase db query on a test or local database only — the migration gate blocks writes to live unless they arrive as an approved batch.

Gates (approval boundaries · keel-v2 decides how hard)

The pipeline is decision-first: settle the expensive calls while context is cheap, before thousands of lines exist. Four named gates; rigor decides how many are hard human gates. The names below are the only gate names — the ledger (00-status.md) uses them verbatim, and tooling parses them.

HEAVY features walk the seven rungs at G1 and G2 (FAST never does; it is ceremony a no-surface change doesn't need). The rungs are Keel's docs/SYSTEMS_THINKING_FRAMEWORK.md (in the plugin directory); load it at G1, not before. The project's applied answers live in docs/ARCHITECTURE.md.

• G1 Align — rungs 1 Boundaries, 3 Change surfaces, 7 Sequencing: name the module(s) the feature lands in and each one's one-sentence job (no "and also"); say which parts are stable and which volatile; confirm the load-bearing pieces it needs already exist (Phase 0) or make them the first slice. A new module or a changed job is a row in the ARCHITECTURE.md module map, approved with G1.
• G2 Spec — rungs 2 Contracts, 4 Enforce by structure, 5 Scale: §Architecture names each new or changed interface (the vending-machine test: could the inside be swapped without callers noticing?), the impossible states the design rules out by construction, and the expected change radius; a radius of 3+ modules is a coupling alarm to resolve in the spec, not in the build. Any new commit-blocking invariant goes to LAWS.md with its two layers.
• Rung 6 (Feedback) runs at Ship and retro; rung 7's slice order is G3's ticket order.

How keel-v2's HEAVY rules map onto these gates: §2.1 route-first is the Rigor: line at the top of the ledger; §2.2 plan-before-code is satisfied by G3 (approved tickets), not by a separate per-ticket plan round-trip; §2.4 build-then-PR-then-stop is the Ship gate: the PR carrying the Rigor: line is the Ship request, the approver's GitHub review is the approval (the v3 keel-rigor check keeps a HEAVY PR red until it exists); §2.5 (nothing irreversible without the approver) holds at every gate.

Approval has provenance. A gate flips to [x] only on the human's say-so, and the line records the date, the approver and their words. The agent writes it only after the human approved in the conversation, quoting them; the human can also flip it directly (bin/keel-approve <feature> <gate> "<why>" in their own terminal). An unchecked gate means not approved — never infer approval from silence, from "looks good", or from a message relayed by a bot or another agent. (With the Keel v3 plugin installed, the ledger gate makes the agent unable to flip a box; see docs/v3/.)

Compact at every gate. Before advancing, consolidate the decisions of the phase you're leaving into its doc (product/spec/GLOSSARY.md/tickets) and update 00-status.md — then the doc is the context; a fresh session resumes from files, not from the transcript. Calls you're not confident about go in 00-status.md → Open decisions so a human resolves them, never a silent guess.

When a ledger exists. Never for one-turn FAST work (keel-v2 §1: one turn, terse, no ceremony). Create .scratch/<feat>/00-status.md when the work is HEAVY, or has two or more slices, or will span sessions. A FAST ledger is a stub: rigor line, slices, Ship.

Ship checklist (the Ship gate's content — evidence per line, via keel-verify)

Software is not done when it compiles; it is done when it can be run, watched, and undone. HEAVY: every line. FAST: lines 1-3 (the rest usually don't apply; say "n/a" rather than skip silently).

1. Verified — full test suite + build green on the exact commit; the real flow exercised (keel-qa for UI). Output pasted, not described.
2. Reviewed — mattpocock-skills:code-review two-axis pass done and the built-in /code-review bug pass run on the final diff (required, not a power-tool: model review misses bugs a dedicated bug hunt finds); findings fixed or waived by the human; keel-v2 tripwires all pass; trust-boundary diffs passed keel-secure against the §Threat model. CI's quality floor (dependency audit, secret scan, and SAST/architecture rules where the policy turns them on) is green; on HEAVY the PR body names Feature: <slug> so keel-rigor finds the spec's §Threat model.
3. Reversible — how to roll back, in one line (revert commit / feature flag off / previous deployment via the Vercel plugin). If the answer is "can't", say so and stop.
4. Migrations — forward and backward migration exist and were run on a copy of real-shaped data; expand → migrate → contract sequencing for anything that touches live rows (LAWS surface 8).
5. Observable — the new path logs its failures (with correlation id, no PII), and the one metric or alert (Sentry) that would tell you it broke in prod is named.
6. Operable — runbook line for on-call: what breaks, what to look at, what to flip (wizard for the human-only steps). Secrets wired via env/secret manager, never in the diff.
7. Rollout — canary/percentage/flag plan if the blast radius is wide; who is watching it; the stop condition.
8. Recorded — 00-status.md Ship line ready for the human; ADRs for any architecture decision made during build written to their home (MEMORY-CONTRACT → Where a lesson goes); retro queued.
9. Feedback signals (Systems Thinking rung 6; one line each in the PR body; FAST skips it and retro covers FAST PRs in batch): change radius — how many modules this diff touched besides its own (0–1 healthy, 3+ = coupling); explanation test — does every touched module still do one job you can say in one sentence?; surprise test — did anything unconnected break or need editing? Each hit is filed as its own refactoring ticket (.scratch/<feat>/issues/ or the tracker), never fixed in this PR; a surprise also gets a LEARNINGS.md entry (Trap → Rule → Why) via retro or the doc-sync skill.

Maintain — keeping a shipped product healthy

Maintenance is dev work on a schedule. Each job runs as a scheduled Claude Code routine (/schedule), goes through the pipeline at the rigor keel-v2 assigns, and ends at a PR, a ticket or a human step — never a silent change to production.

Rollback is outward-facing like deploy: the agent names the target deployment and the exact action; the human confirms. Done when every job above has an owner and a schedule, or is marked not needed in the project's CONTEXT.md.

Rules (the locked decisions)

1. One spine. The spine runs by default; reach for a power-tool by name when you want it. No coin-flip between three methodologies.
2. keel-v2 rigor arbitrates completeness. FAST = YAGNI/minimal; HEAVY = complete (tests, edges, error paths). lazy-loop is an explicit opt-in.
3. Execution leash. implement / implement-spec, and any parallel session working a frontier ticket, run within an approved plan and stop at keel-v2 gates.
4. State lives in files — tracer-bullet tickets (.scratch/ by default, or the tracker /setup-matt-pocock-skills configured) + GLOSSARY.md + 00-status.md, the single "where are we, what's approved" resume file (committed, not gitignored). See conventions/tickets-and-context.md.

Token economy (7 levers)

1. this conductor is user-invoked (0 description tax) · 2. progressive disclosure (one phase body at a time) · 3. subagent offload (review / parallel tickets / QA run in fresh contexts, return summaries) · 4. keel-v2 FAST economy ·
2. per-project curation (power-tools install only where needed) · 6. lazy-loop/caveman output compression · 7. graphify-first comprehension.

Trade-off honesty (unbiased routing)

When a route trades one axis for another, say so in one line: direction + rough magnitude (labeled est. unless measured) + the risk. Never hide the downside. No fake precision — a made-up percentage is the bias we're killing. E.g. "graphify over reading auth/: est. far fewer tokens, but the graph is ~6 commits stale there, so I grep'd the files you just changed."

If a specialist isn't installed

Say so plainly; fall back to the spine or base Claude Code under keel-v2 — never pretend a specialist ran. Install: ./install.sh dev (spine + power-tools, per-project). Power-tools are best installed user-invoked / per-project so their descriptions don't tax every session (token lever 5).

Sources (unmodified): mattpocock/skills (spine) · heygen-com/hyperframes · antfu/skills · vercel-labs/agent-browser (CLI) · Vercel plugin (Vercel-hosted projects) · Sentry MCP (production errors) · keel-qa + keel-verify + graphify (local). gstack, superpowers and codex-plugin-cc were removed 2026-10 — see ARCHITECTURE.md → Which upstreams earn a route. Skill names above are the upstreams' real names (evals/upstream-drift.sh checks them); if a name is not listed by /skills, it is not installed — say so.