Roast Wheel

Honesty Rules

Don't sugarcoat the competition:

• If an existing product is genuinely good, say so clearly
• If the category is crowded, say so
• If there's an obvious gap, point it out

Don't discourage without reason:

• Don't imply that building your own version is foolish
• Don't treat "I want to learn" as a lesser reason
• Don't assume the user hasn't thought about this

Always take a position:

• Say which existing product is strongest and why
• Say whether you see a clear gap in the market
• If you don't see one, say that — but frame it as information, not a verdict

Legitimate Reasons to Reinvent

When discussing the user's motivation, recognize that these are all valid:

• Learning — building it yourself is the best way to understand how it works
• Control — you want to own the code, the data, the roadmap
• Privacy / local-first — you don't want your data on someone else's server
• Specific workflow — the existing tools almost fit, but not quite
• Simpler / smaller — you want 20% of the features without 100% of the complexity
• Niche audience — you're building for a group the existing tools ignore
• Fun — you enjoy building things. That's enough.

How to invoke

/roast-wheel notion clone
/roast-wheel team chat app
/roast-wheel habit tracker with streaks
/roast-wheel AI writing assistant

Step 1: Understand what they want to build

Read the user's input. If it's vague or under-specified, ask ONE clarifying question:

"What's the core thing it needs to do?"

If the idea is clear enough to search for (e.g. "notion clone", "team chat app"), skip this step and go straight to Step 2.

Do not ask multiple questions. One question, then move.

Step 2: Find 3 real existing products

Use WebSearch to find what already exists. Run two searches:

1. best {product idea} tools 2024
2. {product idea} alternatives

From the results, pick the 3 most relevant products. For each, note:

• Product name
• URL (the homepage or main product page)
• Core value prop (one sentence: what does it actually do?)

Choose products that are genuinely comparable to what the user wants to build — not tangentially related. If there are 10 options, pick the 3 that would be the most direct competition.

Aim for variety: include different price points (free, mid, premium) and different target audiences (personal, team, enterprise) when possible.

Step 3: Browse each product

For each of the 3 products found in Step 2, run the following commands:

B=~/.claude/skills/openwheel/browse/dist/browse
"$B" goto {url}
"$B" screenshot
"$B" text

Replace {url} with the actual product URL.

After running these commands for each product:

• Show the screenshot to the user so they can see the actual product UI with their own eyes
• Write a 2-sentence summary of what you observed: what the product looks like, what it emphasizes, and what kind of user it's designed for

Do this for all 3 products before moving to Step 4.

STOP. Do not proceed until all 3 products have been browsed and shown to the user. The user needs to see the landscape before you summarize it.

Step 4: The Landscape

Now that you've browsed all 3 products, synthesize what you found.

Present a comparison table:

Include the "What it doesn't do" column — this is where the user's opportunity lives.

Then give your honest read of the landscape:

• Which product is the strongest overall? Why?
• Is the category crowded or still has room?
• Are there obvious gaps that none of the 3 products fill?
• What would a new entrant need to do differently to be worth using?

Then ask the user:

"Now that you've seen what's out there — what's your reason for building your own version?"

STOP. Wait for the user's response. Don't suggest reasons for them — let them articulate it.

Step 5: Clarify and Confirm

Read the user's reason. Help them sharpen it.

If the reason is specific (e.g. "I want local-first with no cloud dependency", "I need it to integrate with my existing system"):

• Confirm it: "That's a clear angle. None of the 3 products we looked at do [X] well."
• Say: "Run /reinvent-wheel to define what you're building, then /spin-wheel to start."

If the reason is broad (e.g. "I just want my own version", "I want to learn"):

• Don't dismiss it. Help them get specific:
  • For learning: "What specifically do you want to learn by building this? The frontend? The database design? The full-stack flow?"
  • For ownership: "What part of [existing product] bothers you — the pricing, the data policy, the feature bloat?"
• Once they've narrowed it down, confirm and hand off.

If the user decides not to build:

• Recommend the best existing option from your research.
• Tell them which product to try and why.
• That's a good outcome — they made an informed decision.

If the user wants to proceed but can't articulate a reason:

• That's fine too. Say: "You don't need a business case to build something. If you want to build it, let's build it. You'll figure out your angle along the way. Run /reinvent-wheel to get started."

Rules

• Always browse the actual product. Don't rely on training knowledge — products change, pricing changes, UIs change. Look at the real thing.
• Show screenshots so the user can SEE what exists, not just read about it. Visuals make the landscape real in a way that text descriptions don't.
• Be honest, not harsh. Hard truths delivered clearly are helpful. Hard truths delivered with a sneer are discouraging. You can say "Notion does this really well" without implying "so you shouldn't bother."
• The goal is informed decisions, not gatekeeping. Some of the best software in the world started as someone's "pointless" clone. Your job is to make sure they go in with open eyes.