Step 1: The Idea Pack

What your agent does

Takes your raw idea — even if it's just a sentence — and structures it into a 10-section document that covers problem, solution, users, features, scope, risks, and open questions.

Why this matters

The Idea Pack forces clarity before any code exists. It's the difference between "build me a thing" and "here's exactly what we're building, for whom, and what's out of scope."

Every scope creep disaster starts with a vague idea. The Idea Pack kills vagueness.

What the output looks like

Your agent creates docs/idea/idea-pack.md with:

1. Problem Statement — What problem, who has it, how painful

2. Proposed Solution — One paragraph, plain language

3. Target Users — Specific roles and contexts

4. User Stories — 5-12 "As a [role], I want [action]" statements

5. Key Features — What v1 includes

6. Out of Scope — What v1 explicitly does NOT include

7. Success Metrics — How we know it worked

8. Technical Constraints — Platform, budget, integration requirements

9. Open Questions — Unresolved decisions

10. Risks — What could go wrong

Your role

Review and approve. Read through the Idea Pack and ask yourself:

• Does the problem statement match what I actually care about?

• Are the user stories concrete enough to build from?

• Is the "out of scope" list realistic? (If it's empty, that's a red flag.)

• Are there open questions that need answering before we proceed?

Tell your agent what to change. It'll iterate until you're happy.

Example

Here's what the User Stories section looked like when we built an uptime monitor:

> US-001: As a developer, I want to add a URL to monitor so that I know when it goes down.

> US-002: As a developer, I want to see a dashboard of all my monitors so that I can check status at a glance.

> US-003: As a developer, I want to configure how often each URL is pinged so that I can balance responsiveness and resource usage.

Simple, specific, buildable.

Next: From Idea Pack to full spec →