/think -- Challenge the scope

Most features fail because the problem was wrong. /think finds the right problem before building.

Three modes

The diagnostic adapts to what you are building. The agent picks the mode based on your prompt, or you can force one.

  • Founder -- You have an idea but no clear product shape. The diagnostic challenges assumptions about users, market, and differentiation.
  • Startup -- You have a product and need to decide what to build next. The diagnostic focuses on user pain, retention signals, and the narrowest wedge that moves a metric.
  • Builder -- You have a ticket or feature spec. The diagnostic checks whether the spec solves the actual problem, whether the scope is right, and what could go wrong.

How the agent picks

If your prompt mentions users, market, or competition, it selects Founder. If it mentions metrics, retention, or growth, it selects Startup. Everything else defaults to Builder. You can override with --mode founder or set it in .nanostack/config.json.

Six diagnostic questions per mode

Each mode asks six questions. They are not generic brainstorming prompts. They are designed to find the failure mode specific to that stage.

Founder questions

  • Who has this problem right now, and how do they solve it today?
  • What is the single strongest reason someone would switch to your solution?
  • What is the smallest version that tests your core assumption?
  • What would make you abandon this idea?
  • Who are the first ten users and how do you reach them?
  • What is the one metric that tells you this is working?

Startup questions

  • Which user segment retains best, and what do they do differently?
  • What is the number one reason users churn?
  • What is the cheapest experiment that could double the target metric?
  • What are you building that nobody asked for?
  • What existing feature is underused and why?
  • If you could only ship one thing this week, what moves the needle?

Builder questions

  • What problem does this solve, stated in one sentence?
  • What happens if you do nothing?
  • Who is the user and what is their current workflow?
  • What is the narrowest scope that delivers the value?
  • What could go wrong at runtime?
  • How do you know it worked?

The Think Summary

After the diagnostic, the agent writes .nanostack/think.json with five fields:

{
  "value_proposition": "One sentence. What this does for the user.",
  "scope_mode": "founder | startup | builder",
  "target_user": "Specific person or role, not 'developers'.",
  "narrowest_wedge": "The smallest version that still delivers value.",
  "key_risk": "The single biggest reason this could fail."
}

The /nano phase reads this file. If narrowest_wedge differs from your original prompt, the plan will be scoped to the wedge, not the original idea.

Real example

Prompt: "Add a notification system with email, push, and in-app support."

After the Builder diagnostic, /think identified that the actual problem was users missing important state changes. The narrowest wedge: a red dot on the nav icon that clears when clicked. No email. No push. No preferences UI.

The full notification system was 3-4 weeks of work. The red dot shipped in one sprint and solved the core problem. The rest went to the backlog with evidence for why it matters later.

When to skip

Skip /think when:

  • The task is mechanical (rename a variable, update a dependency, fix a typo).
  • You already have a validated spec from user research.
  • The scope is under 30 minutes of work.

Run /nano directly. It will note that think.json is missing but proceed without it.

Previous← How it worksNext/nano →