next-idea

name	next-idea
description	Propose the single smartest, most radically innovative, accretive, useful, and compelling addition to the current project. Output uses BLUF + Pyramid Principle. Use when the user says "next idea", "what should I build next", "what's the best next move", "what would make this 10x better", or wants a single high-conviction recommendation grounded in the current state of the project.

Next Idea

Identify the single highest-leverage addition the project could make right now. Not a list, not a roadmap — one idea, fully argued.

The Question

What's the single smartest and most radically innovative and accretive and useful and compelling addition you could make to the project at this point?

Procedure

1. Ground yourself in the project. Before generating ideas, read enough of the repository to know what exists. At minimum: top-level README.md, the directory structure, any CLAUDE.md / design docs, and the most recent commits (git log --oneline -20). If a dashboard or project plan exists (e.g. docs/dashboard.md), read it. Skim, don't deep-dive — you need shape, not detail.
2. Generate a wide candidate set, silently. Brainstorm 8–15 candidate additions internally. Do NOT show this list to the user. Cover different axes: new capability, new UX, new integration, new abstraction, new audience, new business model, new defensive moat, removing something, inverting an assumption.
3. Score each candidate on four dimensions:
   • Smart: non-obvious, leverages something unique about this project's position.
   • Radically innovative: surprises a reader; not a "fast follow."
   • Accretive: compounds with what already exists rather than replacing it.
   • Useful & compelling: a real user (or self) would be visibly better off; the idea is easy to want.
4. Pick the single winner. If two are close, pick the one with the larger blast radius if it works.
5. Stress-test it. Spend a moment trying to kill the idea: what's the strongest objection, what would have to be true for it to fail, what's the cheapest experiment that would falsify it. Keep the answers — they go in the output.
6. Write the output in the exact format below.

Output Format

Follow BLUF + Pyramid Principle strictly. Hierarchical numbering on every header. No prose before §1. No preamble like "Here's my analysis." Start at ## 1. Objective.

## 1. Objective

One paragraph. What question we are answering, framed against the current state
of the project. Reference the project by name and what it currently is.

## 2. Recommendation

One sentence — the idea, named. Then 3–5 bullets capturing the essence: what it
is, who it's for, why now, what changes for the user, what the moat is.

## 3. Next Steps

Concrete, ordered. The smallest possible first move that would validate or
falsify the idea. Then the second move. Then the third. Stop at three.

## 4. Why This Idea Wins

### 4.1 Smart
Why it's non-obvious. What insight about the project or its users this rests on
that a casual observer would miss.

### 4.2 Radically Innovative
What it changes about the category, not just the product. What it makes
possible that wasn't possible before.

### 4.3 Accretive
How it compounds with existing surface area. Which existing components become
more valuable because of it. Why this is multiplicative, not additive.

### 4.4 Useful & Compelling
The concrete user (or self) moment that gets visibly better. Tell it as a
micro-scenario — "today X happens; after this, Y happens instead."

## 5. What I Rejected and Why

List 3–5 candidates that were strong contenders. One line each: idea — why it
lost (lower leverage, already partially shipped, off-mission, dependent on
something not yet true, etc.). This proves the recommendation is a choice, not
a default.

## 6. Strongest Objection

State the best argument against the idea. Then answer it honestly — either
refute it, or concede that the idea is conditional on assumption X being true
and name the cheapest way to test X.

## 7. Falsification Plan

The smallest, fastest experiment that would tell you this idea is wrong.
Include: what you'd build (or fake), who you'd show it to, what observable
outcome would kill it.

## Appendix

Any supporting detail that didn't fit above: links to relevant files in the
repo (with paths), data points, prior art. Optional — omit if empty.

Formatting Rules

• No header is unnumbered. Every ## and ### carries its position number. The reader must be able to write "see §4.3" and have it stay valid.
• Pyramid Principle: each section's header summarizes the section below it. Don't bury the lede.
• No hedging in §2. The recommendation is one idea, stated decisively. Caveats belong in §6, not §2.
• No fabrication. If you don't know enough about the project to justify a claim, say so in §6 as a conditional ("this assumes Y; verify before committing").
• Length discipline. §2 fits on one screen. §4 is the longest section. The whole document is readable in under five minutes.
• One idea only. If the user pushes back, generate a new single idea — never "options A or B."