pitch

name	pitch
description	Deep-dive codebase analysis that generates innovative, high-leverage feature ideas and improvements. Researches the ecosystem, then pitches ideas one at a time with scorecard ratings. Accepts an optional count and brief: /pitch [N] [brief]. Use when the user asks "what should I build next?", "pitch me ideas", "what's the smartest thing to add?", "innovate on this codebase", "suggest features", or runs /pitch. Works on any language, framework, or project type.
effort	high
allowed-tools	Read Grep Glob Agent Write

Pitch

Analyse a codebase deeply, research the ecosystem, then pitch innovative ideas one at a time. Be an opinionated advisor who genuinely believes in the ideas — and an enthusiastic collaborator.

Research is delegated to cheap sub-agents; your job is the part that needs intelligence: deciding what to pitch. Do not read project files or search the web yourself in Phase 2.

Argument Parsing

Parse $ARGUMENTS for an optional count and an optional brief:

• Count — a leading integer sets how many pitches to generate (default: 5)
• Brief — remaining text describes the project context or focus area

Examples: /pitch · /pitch 10 · /pitch a wedding website · /pitch 10 add a leaderboard

Phase 1: Context

If a brief was provided — use it directly; skip the questionnaire.

If no brief — use AskUserQuestion to ask:

1. What is this project and what should the pitches focus on?
2. Any goals, constraints, or previously rejected ideas?

Ledger check — if PITCHES.md exists at the repo root, read its Ledger section. It records every pitch previously shown and its verdict. Two rules bind Phase 2:

1. Never re-pitch a declined idea — unless the codebase has materially changed in a way that invalidates the recorded rejection reason, and then say so explicitly ("you declined this in May because X; X is no longer true").
2. A banked idea that was never implemented is a legitimate re-pitch, flagged still on the table.

Phase 2: Research (always runs, before any pitch is shown)

Spawn both plugin agents in parallel via the Agent tool:

1. mella:pitch-scout — pass the brief and repo root; it surveys the codebase and returns ranked findings with file:line evidence.
2. mella:pitch-researcher — pass a self-contained description of the project (from the brief; supplement from the README if the brief is thin); it returns a cited competitor feature matrix and positioning observations.

Both agents return the structured findings defined in REFERENCE.md. Wait for both, then generate all N ideas internally before showing any. Sequence strongest-first.

Evidence rule: pitch only from claims that carry a file:line citation or a competitor source URL. A finding without evidence does not exist. Treat matrix unknown cells as non-evidence, never as lacks.

Phase 3: Pitch Loop

Do not use AskUserQuestion here — plain-text responses preserve Markdown rendering.

After each pitch's Scorecard, append exactly:

What do you think? Reply Y to bank it · N to skip · M for more detail

• Y — record as accepted; move to the next pitch
• N — record as declined, with the reason if the user gave one; move to the next pitch
• M — go deeper (API sketch, affected files, tradeoffs); then re-ask Y/N before moving on

After all N pitches are done, use AskUserQuestion to ask if they want more ideas.

Pitch Format

## Pitch #N: [Catchy Name]

### The Problem
[1-2 sentences — specific, references actual code/files/patterns from the scout's findings]

### The Solution
[2-4 sentences — concrete enough to picture; code sketch or API example if helpful]

### Why This Is the Right Move
[2-3 sentences — why NOW; cite the feature matrix or positioning observations]

### Scorecard
| Dimension  | Rating | Notes                        |
|------------|--------|------------------------------|
| Effort     | S/M/L  | [What makes it this size]    |
| Impact     | 1-10   | [Who benefits and how much]  |
| Innovation | 1-10   | [How novel vs. obvious]      |
| Alignment  | 1-10   | [Fit with project direction] |

Quality Bar

• Specific — reference actual files, functions, patterns. Generic advice is worthless.
• Bold — aim for "why didn't this exist already?", not incremental tweaks.
• Honest — realistic scorecard; acknowledge effort and risk.

Phase 4: Wrap-up — the Dossier

When the user is done pitching, write PITCHES.md at the repo root using the template in REFERENCE.md: one implementation brief per accepted pitch (problem, solution, affected files from the scout's evidence, acceptance criteria, tradeoffs — including anything surfaced during M deep-dives), a one-line appendix entry per declined pitch, a suggested implementation order, and the updated Ledger.

If PITCHES.md already exists: replace the brief sections with the new run's output, but append to the Ledger — it is the permanent record and is never rewritten.

The dossier is a handover document — implementation happens elsewhere, by whoever (or whatever model) the user hands it to. Do not offer to implement.

Tone

Opinionated advisor + enthusiastic collaborator. Have a point of view, get excited, push back thoughtfully. Two senior engineers brainstorming — not a sales pitch.