pitch

What this skill does

Asks 6 questions: one at a time, with multiple-choice anchors drawn from the project context, and then writes a pitch.md. That file is the input for your next planning step (a domain/spec review, a PRD, or a companion skill like grill-with-docs if you use one).

Why not jump straight to planning? A planning/spec step can only challenge something once there's something to challenge. Without a pitch, the first half of the session goes to figuring out what should even be built. The pitch separates "what do we want" from "does it fit our domain model".

Flow

Step 1: Load context

Before the first question:

• Read CONTEXT.md in the current project (or CONTEXT-MAP.md if present): it supplies the actors for Q2 and the out-of-scope suggestions for Q5.
• Read docs/adr/ if present: it supplies no-go candidates for Q6.
• If no project context is detectable: use the defaults (see references/defaults.md).

Step 2: Ask the 6 questions

Always: one question per message. Name a recommendation. Confirm before moving on.

Q1: The problem

"What's the concrete problem? Describe a situation, not a feature."

• No multiple choice: free text.
• If the answer is too abstract ("users are confused"): dig in with "Show me a concrete situation: who's doing what, and what goes wrong?"

Q2: Audience

"Who is this for, who hits this problem?"

• Generate MC options from the actors in CONTEXT.md.
• If no CONTEXT.md: End user / Admin / Internal team / Multiple.
• Always: "+ Other (free text)" as the last option.

Q3: Rough solution

"What's your rough idea for the solution? 2–3 sentences, no wireframe."

• No MC: free text, with a starter: "Imagine you're explaining it to someone at a whiteboard in 30 seconds."
• If the answer is too precise (user stories, DB schema): stop and say "That's already PRD-level: save it for the planning step. Rougher, please."

Q4: Scope of the first version

"How built-out should the first version be?"

• MC:
  • MVP: fastest version that solves the problem, technical debt knowingly accepted
  • Polished: production-ready, all edge cases
  • Undecided: not settled yet

Q5: Out of scope

"What's explicitly NOT part of this: things that might seem adjacent but aren't coming yet?"

• MC suggestions from CONTEXT.md: things marked there as "out of scope" or "phase X".
• Always include a free-text option.
• Recommendation: "I'd suggest [X from CONTEXT.md] as out of scope, because the phase plan puts it in phase Y."

Q6: No-goes

"What's an absolute no-go, something that must under no circumstances be part of this solution?"

• MC candidates from ADRs (rejected alternatives) + known constraints.
• If no ADRs: compliance notes (GDPR, etc.), hard technical limits.
• Always include a free-text option.
• May be left empty, then drop the section from pitch.md.

Step 3: Write pitch.md

Right after Q6: no further questions.

Location: docs/pitches/pitch-YYYY-MM-DD-<slug>.md in the project root. If docs/pitches/ doesn't exist: create it lazily. If no project root is detectable: the current directory.

Slug = 3–4 words from the problem, kebab-case.

Format: see references/pitch-template.md

Step 4: Handoff

After writing:

pitch.md is at docs/pitches/pitch-YYYY-MM-DD-<slug>.md.

Next step: hand it to your planning/spec step (a domain review, a PRD, or the
grill-with-docs skill if you use one), point it at that file.

Edge cases

User runs /pitch with text: e.g. /pitch I want SMS reminders for bookings → Take that text as pre-context for Q1, but still ask Q1 and confirm.

User already has a pitch.md: ask whether to update it or start a new version.

No CONTEXT.md present: use defaults for Q2 + Q5 (see references/defaults.md). Note in the output: "No CONTEXT.md found: actors and out-of-scope suggestions are defaults."

User skips a question: ask once more. If still no input: leave the section empty and mark it in pitch.md as _Not answered: resolve during planning_.