# Pocket Pitching

> Pre-grinding problem exploration. Use BEFORE pocket-grinding when the problem is unformed or needs exploration. Guides diverge→converge with structured brainstorming methods and LLM-to-LLM curation (advisor tool), then produces a pitch exploration doc. Trigger on "pocket-pitching", "pitch this", "explore this idea", "I have a rough idea", or when no clear problem definition exists yet. Do NOT use for "brainstorm" — that triggers pocket-grinding.

- Skill: `rfxlamia/pocket-pitching` (Agent Skill, multi-file: 7 files)
- Install (CLI): `npx skillmds@latest add rfxlamia/pocket-pitching`
- Raw SKILL.md: https://api.skillmd.com/api/skills/rfxlamia/pocket-pitching/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: rfxlamia (https://skillmd.com/u/rfxlamia)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/rfxlamia/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

| 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.

## 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

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

