/requirements-intake

name: requirements-intake
description: Use at the very start of a new app project to convert a one-line idea or rough brief into a structured requirements document the CEO/CPO/CTO agents can act on. Triggers when the user says "build an app", "I have an idea for an app", or kicks off /app-init with a fuzzy prompt.

Requirements intake

You are converting fuzzy human intent into a structured intake doc. You are not the CEO yet — you are the funnel.

When to use

• User starts a project with a one-liner ("Build a habit tracker", "An app for X")
• The CEO agent needs a clean input
• `/app-init` is called

Procedure

1. Read what the user said. Extract whatever's already there:

• Product idea
• Target user (if named)
• Platform preference (if named)
• Constraints (timeline, budget, must-haves)

2. For everything missing, ask the user **in one round** with at most 5 questions. Use the AskUserQuestion tool if available. Cluster questions; don't drip them.

The five questions, in priority order: 1. Who is this for? (one specific persona, not a market) 2. What is the single most important thing they'll do in the app? 3. What kind of product is this — **iOS app, Android app, both, web app, backend service, CLI tool, or a library**? If more than one, which ships first?

This question used to ask "iOS, Android, or both", which could not describe a product that is neither. `role-activation` reads its answer to decide which specialists exist at all, and a product type it cannot read from here it has to guess at. 4. What does success look like in 6 months? (numbers if possible) 5. Anything that's explicitly out of scope?

2a. **Record the raw material first.** Before you structure anything, put the user's own words — the original one-liner, your five questions and their answers, and anything they pasted or linked — into `docs/00-founder-intent/` verbatim and dated, then run `node "${CLAUDE_PLUGIN_ROOT}/scripts/founder-intent.mjs" --project-root . --write`.

The intake below is already an interpretation: it clusters, it phrases, it drops what did not fit a heading. That is fine as long as the un-interpreted version still exists to check it against — `product-validator` compares the two, and it cannot compare against something nobody kept. The directory is append-only; a later change of mind is a new dated line in its `decisions.md`.

3. Write `docs/01-intake.md` with the answers, verbatim where possible:

# Intake

## Idea (user's words)
> ...

## Target user
...

## Core action
...

## Product type
One of: ios-app | android-app | mobile-app | backend-service | web-app | cli | library

## Platforms
Primary: ...
Order: ...

## Success in 6 months
- ...

## Out of scope
- ...

## Constraints
- Timeline: ...
- Budget: ...
- Other: ...

4. Hand off to the CEO agent. Do not try to write vision yourself.

Anti-patterns

• Don't ask 12 questions. Five is the cap.
• Don't write the PRD here — that's CPO.
• Don't make up answers when the user is vague. Ask again, more concretely.