--- name: intent-harden description: Stress-test and tighten an intent contract before planning. Composes /grill-me + /linear-independence and adds three more phases (Visualize / Stress-test / Realign). Use right after a contract is ratified and before spawning a planner — especially for T3 work or any task where the contract was drafted in one pass and not yet stress-tested. Triggers on "harden the contract", "before we plan, let's stress-test this", or invoke directly with /intent-harden [target]. user_invocable: true --- The default failure mode of contract drafting is **invisible scope** — decisions the planner has to invent because nobody surfaced them, and additions that creep in because nobody compared the build to the original ask. This skill is the explicit expansion-then-contraction cycle that catches both. Run when a contract has been ratified (or is in late-stage drafting) and the user is about to commit it to a planner. Especially valuable when the user might otherwise rubber-stamp the contract under cognitive load. ## The five phases — run in order ### Phase 1 — EXPAND *(invoke /grill-me)* Drive the design tree. Surface every decision the planner would otherwise have to invent silently. Cover at minimum: - Privacy / enumeration / oracle attacks - Idempotency, dedup windows, rate limits - Validation strictness (server vs client, soft vs hard) - Failure modes (what happens if external service X is down) - Error UX (what does the user see; what does staff see) - Observability (audit trail, logging, dashboards) - Auth posture (how do we know it's the right person) For each branch, propose a recommended answer. The user steers; you do not interrogate without recommendations. ### Phase 2 — COMPRESS *(invoke /linear-independence)* Collapse the grill output into the smallest set of truly independent decisions — typically 3-5. Anything that can be answered from the codebase, from existing conventions, or from a sensible default, you commit to deciding yourself. Do NOT ask the user about column names, file paths, or default tradeoffs that have an obvious answer. Surface the compressed set with: **decision · tradeoff · cost of each option · your recommendation**. Use AskUserQuestion to bundle them when there are 2-4 questions. ### Phase 3 — VISUALIZE NEVER skip. Reading a contract is abstract; seeing the artifact is concrete. Produce three things: 1. **ASCII mockups** of every user-facing surface (forms, pages, emails, badges, dashboards). Even rough box-drawings beat prose. 2. **File tree** of what gets created and what gets mutated, grouped by frontend / backend / config / tests. 3. **Data flow diagram** for the critical path (one-page ASCII flowchart, with branches and side effects called out). The user must see the build before they consent to it. Misplacements (wrong subdomain, wrong audience, wrong surface) usually only surface when they SEE the picture — not when they read the spec. ### Phase 4 — STRESS-TEST Probe the upstream and downstream boundaries. For each major component, ask: - **What's already built?** Grep + read the codebase. The most expensive scope creep is rebuilding something that already exists. - **What's the action surface?** (UI button / Stripe Dashboard / cron / webhook / manual script) — sometimes the action lives outside our system entirely. - **Where's the source of truth?** (DB column / external API / external dashboard) — we don't need to track state our system isn't authoritative for. - **What fails silently if absent?** Identify the consequences of NOT building each piece. Sometimes the answer is "nothing user-visible" — cut it. - **What's the downstream side-effect on success?** (other webhooks fire / other systems get notified / state propagates) — confirm we don't double-handle. Cut dead-weight that already-wired systems handle. The "Stripe webhook already does X" insight is the prototypical stress-test win. ### Phase 5 — REALIGN Re-read the source-of-intent — the original PDF, Loom transcript, decision doc, or client message that started this work. Audit every decision in the hardened scope against it. Classify each decision as one of: - **VERBATIM** — directly required by the source - **ADDITION** — not in the source; we're proposing to add it - **DEVIATION** — diverges from the source (different copy, different flow, different placement) Surface the additions and deviations. For each non-VERBATIM item, offer three paths: - **Path A — Ship as scoped, flag to client post-launch.** Cheap, gets us launched, client can veto post-fact. - **Path B — Pause and ask client first.** Slow but zero misalignment risk. - **Path C — Cut the addition, ship pure source intent.** Smallest, fastest, safest. Defer the addition to a follow-up task only if a real complaint emerges. **Default recommendation: Path C** unless the addition is load-bearing for the verbatim spec to function. This phase is where most scope creep dies. The addition you proposed in Phase 1 because it "felt useful" gets cut here because the client never asked for it. ## Output After all five phases, produce a **hardened brief** with three sections: 1. **Final DONE_WHEN** — single tight statement of the contracted outcome. 2. **Final in-scope and out-of-scope lists** — with cut-list explicitly named. The cuts are as important as the keeps; they prevent re-litigation downstream. 3. **Source-alignment audit** — three lines: `Verbatim: · Additions kept: · Deviations: `. Future you (or the planner subagent) can verify alignment in seconds. This brief replaces the raw contract as the input to the planner. The original contract on the ledger remains the durable record; the hardened brief is the planner's working copy. ## When NOT to run - T1 fixes (≤2 files, ≤50 LOC) — the brief IS the commit message. - T2 mini-loops with an obvious shape — the executor + reviewer subagents will catch design issues. - Tasks where the source-of-intent is already fully unambiguous AND the codebase implications are well-known. In those cases, just go. ## Style notes - Recommend an answer for every question. Never interrogate without offering a default. - Use AskUserQuestion to bundle the linearly-independent decisions — single message, parallel answers. - Use ASCII for mockups even when crude. The point is shared sight, not aesthetics. - Keep the user in the driver's seat — every phase ends with a yes/no/refine before moving forward. - The skill is a **discipline**, not a script. If the user pushes back at any phase, redirect; don't insist on completing the next phase.