Skip to main content

​
Understanding Clarifying Questions

​
What they are

After you submit an idea, the IdeaProcessor returns 3–5 clarifying questions. They are generated from your idea to fill gaps in:
  • Target users
  • Feature scope
  • Priorities
  • Platform
  • Constraints
Your answers are the main input for the IntentAnalyzer, which produces the refined requirements used for the rest of the workflow.

​
Why 3–5 questions

  • Enough to lock scope and priorities
  • Does not overload the idea stage
  • Detail belongs in Intent, not Idea

​
Typical themes

ThemeWhat the AI is probingExample questions
Target audienceWho will use it; size, context“Who is your target audience?” “What is the typical team or user size?”
Core vs optional featuresMust-have vs nice-to-have“What are the must-have features for v1?” “What can wait for a later version?”
Platform preferenceWeb, mobile, or both“Web first, mobile first, or both?” “Any preference for Android vs iOS?”
Scale and contextUsage, data, environment“How many users or items do you expect?” “Any compliance or data requirements?”
Technical preferencesStack, integrations, constraints“Any preferred tech stack or existing systems to integrate with?”

​
Order and how answers are used

  • Questions are in a fixed order
  • Provide one answer per question, in the same order
  • Intent API sends answers as an array
The IntentAnalyzer combines your idea and answers to produce:
  • title — Project title
  • description — Detailed description
  • features — Feature list (prioritized from your answers)
  • target_audience — Who it’s for
  • technical_requirements — Tech, integration, or compliance needs
Missing or vague answers lead to generic or incomplete requirements.
Answer every question.

​
How to Answer Effectively

​
Answer every question

The workflow requires an answer for each question. Skipping or leaving one blank forces the AI to guess and usually weakens the refined requirements.

​
Be specific

  • Do: “Remote teams of 5–20; team leads and members. Need to work across time zones.”
  • Avoid: “Teams.”
  • Do: “Must-have: assignees, due dates, list view. Nice-to-have: Kanban, labels, recurring tasks.”
  • Avoid: “All the normal todo stuff.”

​
Separate must-have vs nice-to-have

Clearly split:
  • Must-have for v1 — Needed for a usable first version
  • Nice-to-have — Can come later
This drives platform choice, execution scope, and the PRD.

​
State platform preference if you have one

Examples:
  • “Web first; mobile later.”
  • “iOS only for now.”
  • “Web application; no native mobile.”
If unsure:
  • “No strong preference”
  • “Recommend based on the product”

​
One response per question

  • One input maps to one question
  • A response can be 2–4 sentences if needed
  • Do not merge answers for different questions

​
Avoid one-word or placeholder answers

  • Avoid: “Yes.” / “No.” / “Maybe.” / “Same as above.”
  • Prefer: A sentence or two that becomes a concrete requirement

​
Be consistent with your idea

Answers should refine the idea, not contradict it.

​
Providing Detailed Requirements

​
What “detailed” means here

Concrete and complete enough for the IntentAnalyzer to set:
  • title
  • description
  • features
  • target_audience
  • technical_requirements

​
Where to add detail

  • Target audience — Size, role, environment
  • Features — What each must-have means in practice
  • Scale — Order-of-magnitude
  • Constraints — Compliance, integrations, offline needs

​
Where to stay brief

  • Platform — “Web first” or “No preference”
  • Tech stack — Only if required

​
How your answers flow into the blueprint

Refined requirements are used by:
  • PlatformSelector
  • X402 / Execution
  • Deliverables — PRD, PLAN, specs, prompts, infra
Better answers → better platform choice → stronger blueprint.

​
Examples

​
Example 1: Todo app for remote teams

Idea
A todo app for remote teams with assignees and due dates. Typical clarifying questions
  1. Who is your target audience?
  2. What are the must-have features for the first version, and what can wait?
  3. Web, mobile, or both? Any preference?
  4. How many users or tasks per workspace do you expect?
  5. Any integrations or technical constraints?
Good answers
  1. Remote teams of 5–20 people; leads and members; multiple time zones
  2. Must-have: assignees, due dates, list view, filters. Nice-to-have: Kanban, labels, recurring tasks
  3. Web application first; responsive web
  4. Hundreds of users; thousands of tasks per workspace
  5. No hard integrations; single-VPS; no compliance needs

​
Example 2: Solana wallet for beginners

Idea
A Solana wallet for beginners with simple send/receive and token list. Good answers
  1. First-time Solana users; beginners
  2. Must-have: send/receive SOL and SPL, balances, tx history
  3. Mobile first: iOS and Android
  4. Solana only; common SPL tokens
  5. Non-custodial; no KYC

​
Example 3: What to avoid

Weak answers
  • “Teams.”
  • “Everything.”
  • “No preference.”
  • “Lots.”
  • “Nope.”
Stronger version
  • Remote teams of 5–20
  • Must-have vs nice-to-have clearly split
  • Web app first
  • Hundreds of users
  • No integrations for v1