| name | feature-passes |
| description | Use when starting any substantial feature — the before/during/after development lifecycle: interview rounds, parallel blind-spot/references/reality-probe passes, a knowns matrix folded into the plan, an implementation-notes log during the build, and a compounding step after (explainer, quiz, memory/skill extraction). Triggers — "feature passes", "run the pre-build passes", "blind spot pass", "knowns matrix", "interview me about this feature", "compound the learnings". |
feature-passes
The before/during/after lifecycle for any substantial feature. The failure modes it exists to kill: a plan built on the author's assumptions instead of the user's decisions; design questions answered by opinion when production data could answer them by measurement; deviations during the build that silently overwrite locked decisions; and a session's hard-won learnings evaporating because nobody wrote them down as skills/memory. Every pass below is cheap relative to rebuilding a feature the user didn't ask for.
BEFORE — all of this happens in plan mode, before ExitPlanMode
1. Interview the user
2-3 AskUserQuestion rounds, 3-4 questions each. Options carry previews for anything visual (a mock row, a sample sentence, a naming candidate) — never ask the user to imagine what an option looks like.
Each round narrows:
- Round 1 — shape. What is a row/unit? Who is it for? Where does it surface?
- Round 2 — mechanics. Scope boundaries, flows, sequencing, what's explicitly out.
- Round 3 — edges. Day-one experience (empty states, first-run), naming, deadline/demo coupling.
Lock every answer into a decisions table in the plan (decision | chosen option | round). These are LOCKED — later passes may challenge them, but only explicitly (see step 3), never by silent drift.
2. Parallel passes — launch as agents in ONE message
Four independent agents, all launched in a single message so they run concurrently:
- (a) TECHNICAL blind-spot — an adversarial reviewer attacks the draft plan against the actual code. Every finding needs file:line evidence and a concrete amendment to the plan text. "This might be a problem" without a location is not a finding.
- (b) PRODUCT blind-spot — attacks the plan's emotional register, audience fit, the demo moment (what's the 10-second wow?), delivery surface, gating/timeline coupling, and success signals (how will we know it landed?).
- (c) REFERENCES — web research resolving the design unknowns from provider docs, plus a competitor scan: what is table stakes (users will assume it) vs open ground (differentiation).
- (d) REALITY PROBE — measure the actual deployed/production data the design assumes. Read-only only: API GETs, log queries — CloudWatch Logs Insights works as a database when the DB is walled off (see probe-before-wire's "Logs as the read-only database"). The probe converts "will this be a firehose or a dead feed?" class questions from opinion to measurement — rows/day, churn rate, field shapes, real cardinalities.
3. Fold results into plan v2 with a KNOWNS MATRIX
The plan gains a ## Knowns matrix section:
| Quadrant | Contents |
|---|
| Known-knowns | Verified facts, each with its evidence (a probe result, a file:line, a doc URL) |
| Known-unknowns | Tracked open questions, each with a resolution path + an owner |
| Unknown-knowns | Things the docs/repo already knew that the draft plan ignored — the blind-spot passes' harvest |
| Unknown-unknowns | Mitigations, since you can't list them: converge-iterate the plan, the impl-notes log, a live shakedown, a post-ship signal review |
Flag explicitly any amendment that modifies a decision the user locked in the interview — never silently override. Present the conflict ("pass (a) found evidence against locked decision D3") and let the user re-decide.
4. Only then ExitPlanMode
CRITICAL: build workflows launched while plan mode is active return read-only specs, not code — subagents inherit plan mode. ExitPlanMode first; if a build run already went out under plan mode, launch a FRESH run (never resume — the cached results are the read-only ones).
DURING
- Implementation-notes log. Keep
docs/implementation-notes/<feature>.md (or compile it from the build agents' structured deviation reports): every deviation from the plan gets one line of why. Don't stop to re-plan unless a deviation invalidates a locked decision — then it goes back to the user, not to your judgment.
- Every build lane runs build → INDEPENDENT verify → fix loop. A separate agent re-runs the gate itself in its own checkout and adversarially audits the work. A builder's self-reported green never counts as verified. Max ~2 fix rounds, then escalate to the human — a lane that won't converge in 2 rounds has a spec problem, not an effort problem.
AFTER — the compounding step (this is not optional)
-
Pitch/explainer for stakeholders. What shipped vs what was asked, the judgment calls made along the way, and what the feature can/can't ever do and why (the architectural ceiling, stated plainly).
-
Quiz. 3-5 questions answerable only against the deployed thing — not the plan, not the code. Pass = the build matches the locked decisions. The quiz doubles as an onboarding/support FAQ seed.
-
COMPOUND. Sweep the session for:
- (a) caught-once traps → memory files
- (b) repeated procedures → new or extended skills
- (c) deterministic orchestration you hand-wrote → parameterized Workflow scripts
- (d) config/transport fixes → code (Makefile / CI)
Apply the primitive test to sort each item: judgment → prompt, transport → code. End the session by actually creating them, not just listing them — a bullet list of "learnings" that never becomes a file compounds nothing.
Relationship to other skills
- converge — the plan-v2 audit and the diff audits during the build both run through
/converge audit; "converge-iterate the plan" (audit → fold → re-audit until no critical/high) is an unknown-unknowns mitigation.
- probe-before-wire — the REALITY PROBE pass is its design-time projection: verify the data assumption against reality before the plan bakes it in.
- primitive-test — the sorting function for the COMPOUND step.
