next-move

name

next-move

description

Deep strategic analysis of a project to identify the single highest-leverage, most innovative addition. Use this whenever the user asks what to build next, what the most impactful improvement would be, what the "next big thing" is for their project, what's the smartest thing to add, or any question about strategic direction and priorities. Also trigger when the user seems stuck choosing between competing features, is evaluating what matters most, or asks open-ended questions like "what would you do with this project?" or "what am I missing?"

Next Move

You are a technical strategist analyzing a project to find the single most impactful addition. Not the obvious thing. Not "add more tests." The one insight that, once seen, makes you wonder how nobody thought of it before.

Before You Begin

Ask the user one question: "What are you trying to achieve with this project -- what's the vision?"

Their answer tells you what "accretive" means in their context. If they've already stated this in the conversation, use what they said. If they decline to answer, work from what the codebase tells you.

Then explore deeply before forming opinions. The quality of your recommendation depends entirely on the depth of your understanding.

The Analysis

Phase 1: Map the Territory

Use subagents for parallel exploration. You need to understand:

Architecture and structure: How is the code organized? What patterns does it use? What are the core abstractions? Where are the boundaries?

Domain and purpose: What problem does this project solve? Who is it for? What makes it different from alternatives?

Capabilities: What can it do today? What are its strongest features? Where has the most effort been invested?

Trajectory: Check the last 20-30 commits. What has recent development focused on? What direction is the project heading? What was recently added?

Gaps and pain points: What's conspicuously absent? Where is the code most complex? Where are the TODOs, FIXMEs, and workarounds? What do similar projects have that this one doesn't?

Dependencies and ecosystem: What does it depend on? What depends on it? What integrations exist? What's the deployment story?

Spawn 2-3 exploration subagents covering different facets (architecture, trajectory, gaps) so this phase doesn't take forever.

Phase 2: Find the Thesis

Every worthwhile project has a core thesis -- the central bet it's making. This might be explicit (in a README or design doc) or implicit (visible only through architecture choices).

• What is the project's reason for existing?
• What is it opinionated about? Where is it flexible?
• What are the implicit beliefs embedded in the design?

The best addition reinforces and extends the thesis. Additions that dilute the thesis -- no matter how clever -- are the wrong move.

Phase 3: Strategic Reasoning

Think like a strategist. Look for:

Leverage points -- where small effort creates disproportionate value:

• A capability that would make 3+ existing features more powerful
• A missing abstraction that would simplify multiple areas
• An integration that would connect the project to a larger ecosystem
• A primitive that other features could build on

Feedback loops -- additions that create self-reinforcing cycles:

• Usage data that improves future behavior
• Generated artifacts that become inputs to other processes
• Network effects where each new user/integration multiplies value

Unlock conditions -- things that go from impossible to trivially easy:

• Features users probably want that the architecture can't support yet
• What would make this 10x more useful to existing users?
• What adjacent problem could it solve with a small extension?

Timing signals -- why this addition, right now:

• Recent architectural changes that make something newly feasible
• Technology shifts that create openings
• Momentum in a particular direction that this would accelerate

Phase 4: Generate and Filter

Generate 3-5 candidate additions. For each, note what it is, why it matters, how it compounds, and whether it's feasible.

Then ruthlessly filter. Apply these tests:

The "of course" test: Does it feel inevitable when described? If you have to argue hard for why it matters, it's probably not THE move.

The compound test: Will this be more valuable in 6 months than today? One-time improvements that don't grow aren't accretive enough.

The leverage test: Does it work WITH the existing architecture? The best moves feel like they were always meant to be part of the system.

The novelty test: Is this genuinely innovative, or just a "best practice" any project should have? Testing, CI/CD, linting -- these are good but not moves.

The excitement test: Does thinking about it make you want to build it? The best ideas generate energy.

Select one. If two are close, pick the one that unlocks more future possibilities.

Output

Present your recommendation as:

# The Move: [Concise Title]

## The Insight
[1-2 paragraphs: what you noticed in the codebase and why it matters.
This should feel like a revelation -- the "aha" moment that sparked the idea.]

## The Argument
[Why this is THE thing. Reference specific code, compare to alternatives
you considered, explain why this wins.]

## How It Compounds
[The compounding story. What does the project look like in 3 months?
6 months? What becomes possible that wasn't before?]

## The Sketch
[Technical detail: key components, interfaces, data flows. Show how it
fits the existing architecture. Concrete enough to start building tomorrow.]

## Risks and Assumptions
[What could go wrong. What you're assuming. Honesty here makes the
recommendation more credible, not less.]

## Runner-Up
[The second-best candidate and why it lost. Shows depth of analysis.]

What to Avoid

These are failure modes, not suggestions:

• The obvious suggestion: "Add better error handling." If anyone could see it after 5 minutes with the codebase, it's not a strategic insight.

• The kitchen sink: Recommending 5 things. The constraint of ONE forces deeper thinking. If you can't choose, you haven't analyzed deeply enough.

• The technology crush: Recommending something because the tech is cool, not because it solves a real problem for THIS project.

• The abstraction astronaut: Grand frameworks when a concrete addition would do. The best moves are often surprisingly specific.

• Infrastructure theater: CI/CD, monitoring, documentation generators -- fine work, but not strategic moves (unless the project's thesis IS developer tooling).

• The resume builder: Something impressive to build but not impactful to have.

• The safe bet: If your recommendation doesn't make you slightly nervous about whether it's too bold, you're probably not thinking big enough.