Pocket Pitching

Pocket Pitching

Pre-grinding problem exploration. Scans project context silently, picks 3-5 brainstorming methods based on problem type, runs them with LLM-to-LLM advisor curation, optionally runs a technical spike, then produces a pitch exploration doc with problem statement and 2-3 approach directions.

Core principle: Diverge first, converge second. Never propose solutions until the problem is fully explored.

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

When pitching output lands in docs/pocket/spec/, grinding reads it as INPUT context — not as a spec.

Hard Gates

GATE 0: PREFLIGHT MUST COMPLETE BEFORE GREETING USER.
        Scan project + git log silently. No output until greeting.

GATE 1: NO DIVERGE without problem confirmation.
        Phase 1 ends with user explicitly confirming the problem statement.
        Silence or vague approval is not confirmation.

GATE 2: ADVISOR CALL MANDATORY in Phase 2.
        Output ALL method results to conversation FIRST, then call advisor().
        Do not skip. Do not call advisor before outputting results.

GATE 3: SPIKE MUST COMPLETE before Phase 4 if triggered.
        Technical unknowns block convergence.

GATE 4: USER MUST APPROVE BRIEF before pocket-grinding is invoked.
        Present all 3 handoff options. Do not auto-invoke.

Phase 0: Preflight

Goal: Understand project context silently before greeting the user.

Scan (silent — no output yet):

• 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 greet:

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 confirmed problem statement before diverging.

Process:

1. User describes the problem or idea
2. Ask max 2 clarifying questions if needed (WHAT + WHY — not both if one is clear)
3. Synthesize and confirm:

   Problem statement: [1-2 sentence synthesis]
   Is this accurate before we explore?
   

Rules:

• 2 questions maximum — this is pre-exploration, not deep spec questioning
• If problem is clearly stated, skip to confirmation
• If problem is too broad → "Which angle should we focus on this session: [A] or [B]?"

HARD GATE: User must explicitly confirm. Do not proceed on silence.

Phase 2: Diverge

Goal: Explore the problem broadly using selected methods, then curate with advisor.

→ 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]

Do this for ALL selected methods before calling advisor.

2c — Advisor Curation (MANDATORY)

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.

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]

Surface any technical unknowns → offer spike before converging.

Phase 3: Spike (Optional)

Goal: Resolve a specific technical unknown that blocks approach selection.

→ 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 decides mode:

• Code scan → architectural unknowns (what's in the codebase)
• Web search → library/API capability unknowns
• Both → when unknown spans external + internal

One unknown per spike. Do not expand scope. Present spike result before Phase 4.

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 if user adds nuance. Continue when user accepts synthesis.

Phase 5: Approach Directions

Goal: Propose 2-3 solution directions. NOT architecture, NOT scenarios — just directions.

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 pitch exploration doc, then ask user what to do next.

→ Load references/brief-template.md for full document format

Save to:

docs/pocket/spec/YYYY-MM-DD-kebab-slug/pitch-exploration.md

Handoff gate (all 3 options, explicit):

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 option 1: Invoke pocket-grinding skill, pass pitch doc path + problem statement + recommended direction as context. If option 2: Return to specified phase, revise, re-write brief, present gate again. If option 3: Confirm save path, close cleanly.

Reference Triggers