Pocket pitching
A middleweight workflow for serious AI-coded features: less ceremony than BMAD, more accountability than Superpowers. Source : Trust Me Bro.
npx -y skills add rfxlamia/pocketto --skill pocket-pitchingAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
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.md
8.3 KB, as published. Nobody here has run it
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:
- User describes the problem or idea
- Ask max 2 clarifying questions if needed (WHAT + WHY — not both if one is clear)
- 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 |