Pre-grinding problem exploration. Scans project context before making project-specific claims, picks 3-5 brainstorming methods based on problem type, runs them with independent advisor curation, investigates technical unknowns that could change the approach, then produces a pitch exploration doc with a problem statement and 2-3 approach directions.
Core principle: Diverge first, converge second. Never propose solutions until the problem is fully explored.
Start from the user's request. Use clear instructions, corrections, and approvals already given; do not ask the user to repeat them or select a numbered option. Ask only when an unanswered product decision or fact would materially change the exploration. Otherwise, inspect available context, proceed, and label any assumption that affects the result.
When to Use
Trigger when:
- Problem is vague, unformed, or needs exploration before spec-writing
- User says "pitch", "explore", "I have a rough idea", "help me think through this"
- Starting a new feature with no clear direction
Do NOT use:
- When problem is already clearly defined (use pocket-grinding)
- When a spec already exists (use pocket-grinding or pocket-planning)
- For "brainstorm" keyword — pocket-grinding owns that trigger
Boundary with pocket-grinding
| pocket-pitching | pocket-grinding |
|---|---|
| Explores the problem space | Specifies the solution |
| Produces: directions (sync vs async, new module vs extension) | Produces: concrete architecture + GWT scenarios |
| No GWT scenarios — just directional | Full BDD spec with acceptance criteria |
| 2-3 approach directions, no design | Design proposals with scenarios-validated tradeoffs |
When pitching output lands in docs/pocket/spec/, grinding reads it as INPUT context — not as a spec.
Operating Rules
- Use project evidence. Scan the project before making project-specific claims. If the user already gave the topic, begin exploring it; do not restart intake with a generic greeting.
- Confirm only new decisions. Restate the problem and continue when the summary preserves the user's meaning. Ask for confirmation only when your interpretation adds a consequential assumption or a product choice remains open. Treat the user's clear correction or approval as the answer.
- Get independent curation. After all method results are visible, call
advisor(). If it is unavailable or fails, use theadvisorsubagent fallback inreferences/advisor-brainstorm-protocol.md. Do not present your own synthesis as independent review. - Change approach when evidence stalls. For a technical unknown, try a distinct source or investigation mode when the first attempt does not answer it. A call count or retry limit is a cue to reassess, not a reason to stop. Record the evidence and carry any unresolved question into the brief and pocket-grinding.
- Honor an authorized handoff. If the user asks to continue to pocket-grinding, invoke it and pass the brief and open questions. If they have not chosen what to do next, present the choices once and wait.
Phase 0: Preflight
Goal: Understand project context before making project-specific claims.
Scan (read-only):
- Stack: detect from project root files (package.json, Cargo.toml, requirements.txt, go.mod, pom.xml)
- Architecture: scan top-level dirs (src/, lib/, app/, services/, packages/)
- Recent commits:
git log --oneline -10 - Existing pitch/spec docs: check
docs/pocket/spec/for recent work
Then respond to the request already in the conversation. Include a concise project summary when useful. Ask what the user wants to explore only if they have not already provided a topic.
Example when no topic has been provided:
Project: [name] · Stack: [detected stack] · [architecture pattern]
Recent: [3 most relevant recent commits]
What would you like to explore or pitch today?
Phase 1: Problem Intake
Goal: Establish a shared problem framing before diverging.
Process:
- Extract the problem, affected person or system, and why it matters from the user's request and available project context.
- Identify only missing facts that could change the framing or exploration direction. Ask a focused question for each consequential gap; usually one or two will be enough. Do not stop at an arbitrary question count if a material ambiguity remains.
- State the problem in one or two sentences. If it preserves the user's meaning, move to Phase 2. If it adds a consequential assumption, ask the user to correct or confirm that assumption before diverging.
If the problem is too broad to explore usefully, offer a small set of concrete angles and ask which one to pursue. Do not ask for confirmation of facts or choices the user has already made. Silence is not approval for a consequential choice the user has not made.
Phase 2: Diverge
Goal: Explore the problem from several useful angles, then have an independent advisor curate the results.
→ Read references/brainstorming-methods.csv to select methods
→ Load references/method-selection.md for selection criteria and default trio
2a — Method Selection
Read CSV. Select 3-5 methods based on problem type. Default trio: Question Storming + First Principles Thinking + Six Thinking Hats State selection rationale (1 line per method): "Chose [X] because [reason]..."
2b — Sequential Execution + Output
For each method, output results to conversation (visible text):
### [Method Name] — [category]
[4-6 insights or ideas generated by applying this method to the problem]
Output every selected method before calling advisor.
2c — Independent Advisor Curation
After outputting ALL method results, call advisor().
The advisor reads the full conversation including all method outputs.
Do NOT phrase this as "passing context" — advisor auto-reads conversation.
If the call is unavailable or fails, follow the independent advisor subagent
fallback in references/advisor-brainstorm-protocol.md. That protocol defines the
persona, context, and required response. If neither route can provide an independent
review, continue useful work that does not depend on curation, state what is missing,
and do not present a final synthesis or claim the pitch is complete.
Expected advisor return: key insights, patterns, connections, candidates to discard.
2d — Synthesis Presentation
Present to user:
## Brainstorm Synthesis — [N] methods explored
### Key Insights
- [3-5 insights from advisor curation]
### Patterns
- [pattern across methods]
### Ideas Worth Pursuing
- [shortlisted ideas]
### Discarded (why)
- [what got cut and why]
If a technical unknown could change the approach, investigate it in Phase 3 before converging. If the answer depends on information only the user can provide, ask for that information; otherwise use the available code or documentation sources. Carry unresolved questions forward with the evidence gathered.
Phase 3: Spike (When Needed)
Goal: Resolve a technical unknown that could change which approach is worth pursuing.
→ Load references/spike-protocol.md for trigger criteria and execution
Triggered when Phase 2 surfaces: "can X do Y?", "does Z already exist?", "what does library W support?"
Agent chooses the available mode based on the unknown:
- Code scan → architectural unknowns (what's in the codebase)
- Web search → library/API capability unknowns
- Both → when unknown spans external + internal
Investigate one unknown at a time and present the result before Phase 4. If a search does not answer it, use the next relevant source or mode in the spike protocol. At about five tool calls, reassess whether the current path is producing evidence and switch strategy if it is not. This is a strategy checkpoint, not a stop condition. If distinct approaches still leave the answer uncertain, state what you checked, what the evidence supports, and the exact open question; carry it into the pitch brief for pocket-grinding.
Phase 4: Converge
Goal: Synthesize diverge + spike results into a clear problem statement.
Output to user:
## Problem Synthesis
Problem: [1-2 sentences — clear, actionable]
Root tension: [the core tradeoff or challenge]
Key constraints: [from context scan + brainstorm + spike if ran]
Success looks like: [directional success signal — not GWT, just intent]
Adjust when the user adds nuance. If the user already supplied the framing, treat that instruction as acceptance; ask only about a consequential choice the user has not made.
Phase 5: Approach Directions
Goal: Propose 2-3 solution directions. Keep them at the direction level; leave detailed architecture and scenarios to pocket-grinding.
Directions at this level: sync vs async, new module vs extension, library vs custom, etc. Leave architecture and scenario validation to pocket-grinding.
Format:
## Approach Directions
Direction A: [name]
[1-2 sentences]
+ [main advantage]
− [main risk or tradeoff]
Direction B: [name]
[1-2 sentences]
+ [main advantage]
− [main risk or tradeoff]
Direction C: [name] (only if genuinely distinct from A and B)
[1-2 sentences]
+ [main advantage]
− [main risk or tradeoff]
Recommended: Direction [X] — [1-sentence reasoning based on constraints + insights]
Phase 6: Brief + Handoff
Goal: Write the pitch exploration doc and continue according to the user's stated intent.
→ Load references/brief-template.md for full document format
Save to:
docs/pocket/spec/YYYY-MM-DD-kebab-slug/pitch-exploration.md
If the user has not already said what to do next, present these choices in natural language:
Pitch doc written to: docs/pocket/spec/[path]
What would you like to do next?
1. Invoke pocket-grinding now (starts from this pitch)
2. Iterate on [specific phase] before proceeding
3. Save and stop here — I'll come back to this later
If the user asks to proceed to specification or otherwise clearly authorizes the
handoff, invoke pocket-grinding and pass the pitch doc path, problem statement,
recommended direction, and unresolved questions. If the user asks to revise, return
to the named phase and update the brief. If the user asks to stop, confirm the saved
path. Do not require the user to reply with an option number.
Reference Triggers
| Reference | When to Load |
|---|---|
references/brainstorming-methods.csv |
Phase 2a: read to select methods |
references/method-selection.md |
Phase 2a: selection criteria + default trio |
references/advisor-brainstorm-protocol.md |
Phase 2c: LLM-to-LLM curation mechanics |
references/spike-protocol.md |
Phase 3: trigger criteria + execution modes |
references/brief-template.md |
Phase 6: pitch doc format |