midas-harness: Skill for Claude Code

business-plan — Phase 3

Guard + state: <paths.engine>/templates/skill-state-ritual.md (+ AGENTS.md § Safety / Path resolution). Prompt tool: AskQuestion. On Claude Code, fall back to AskUserQuestion if AskQuestion is not wired. Precondition: market_research passed unless track: lite (then {product}/idea.md + optional {product}/market.md; write/update the thin stub). Hard human checkpoint on full track — no engineering until go/no-go sign-off. On lite, Idea+Plan already GO-assumes the stub. Optional: /midas-tribunal (pre-go/no-go) — high-leverage, never forced. Playbook: <paths.engine>/pipeline/3-business-case.md

Turn the validated opportunity into a decision. The orchestrator owns the go/no-go judgment and the gate; the builder drafts the document.

Does / Does not

When NOT

• track: lite: missing {product}/market.md is OK — do not send the user to /market-research. If invoked, write/update the thin stub from {product}/idea.md, then /midas-status (overlay → /plan-sprints). See <paths.engine>/pipeline/lite.md.
• Market research gate not passed / blockers remain (track: full) → /market-research or /contextualize.
• Human already signed no-go → stop; do not reopen without an explicit ask.
• User only wants a decision debate → optional /midas-tribunal (never required).

Steps

1. Value proposition — for the target segment from {product}/idea.md + {product}/market.md (omit market.md when track: lite and the file is missing).
2. MVP scope vs non-goals — the minimum surface that validates the core hypothesis, and an explicit list of what is out of scope for the MVP. (The Phase-8 audit checks the build against this scope; vague scope here weakens every later audit.)
3. Business / monetization model — even if v1 is free, state the intended model and what v1 must prove for it to work.
4. Measurable success metrics — each with a target, a measurement method, and a window. These become the acceptance signals the per-sprint audit (/close-sprint) and /midas-tribunal grade against, so make them concrete and queryable.
5. Cost/effort envelope — a rough build estimate (sprints, dependencies).
6. Validation status — desk vs field (do NOT hard-wall a resource-constrained founder). State both:
   • Desk validation (done in Phase 2): the demand signals + competitive landscape — the part the AI can prove. Carry over the demand verdict (strong/mixed/weak).
   • Field validation (strongest evidence — recommend, don't mandate): customer interviews, a real preorder / letter-of-intent, or a small paid-ad demand test. This is the only thing that proves these customers pay. If the founder can do it, strongly recommend it before building.
   • If field validation is not feasible now (e.g. solo / AI-only founder, no audience yet): you MAY still proceed — record an explicit assumption ("real-customer demand is unproven; field validation deferred") as a top risk, re-surfaced before launch/scale and in /midas-tribunal. Do NOT invent a hard "no product until you interview N people" gate that walls the founder. The go/no-go is the human's informed risk call, not a lock.
7. Go / no-go — render an explicit recommendation with rationale, then obtain human sign-off via AskQuestion. A valid verdict is GO with field validation deferred (assumption logged) when desk demand is at least mixed and the human accepts the unproven-demand risk. Record name + date under ## Human sign-off in {product}/business-plan.md. Do not invent a human_approved state key (not in the schema). Gate pass is the state record. On "no-go", stop and log why.
8. Write {product}/business-plan.md from <paths.engine>/templates/business-plan.md — keep those headings (## MVP scope, ## MVP non-goals (explicit exclusions), ## Success metrics, ## Revenue / cost model, ## Validation status, ## Go / no-go recommendation, ## Human sign-off). Update paths.state (gate verdict by the orchestrator).