Idea-to-implementation pipeline. Interviews the user about their idea, researches libraries/APIs/patterns, designs architecture, generates a structured plan, then auto-transitions to /project-init (if new project) and /subagent-driven-development. Use when user says "I want to build", "let's build", "let's create", "I have an idea", "new project", "design this", "plan this out", "what if we built", or invokes /design. Do NOT trigger for bug fixes, quick tweaks, or questions about existing code.
Take a raw idea and produce a researched, architected, user-approved plan — then seamlessly transition into building it. This is the front door to the entire flintflow workflow.
NEVER write code during /design. This skill produces a plan, not an implementation.
Structured conversation to understand the idea before researching anything. Adapt questions based on answers — skip what's already clear, dig deeper on ambiguity. Don't dump all questions at once; conversational flow across 2-3 rounds.
When to stop interviewing: You have enough to research when you know the what, who, stack, and success criteria. Don't over-interview — move to research.
Full research using all available tools. PARALLEL DISPATCH IS MANDATORY. This phase is critical — never skip it, even for "simple" ideas.
Dispatch these as parallel Agent calls in a SINGLE message:
Agent 1 — Context7 Docs: Pull fresh documentation for every library, framework, and API mentioned in the interview. Even ones you "know" — always pull current docs via Context7.
Version check (if building on existing code):
package.json, pyproject.toml, Cargo.toml, go.modAgent 2 — Web Search:
Agent 3 — Codebase Exploration (if building on existing code):
Wait for all three to return, then synthesize results before moving to Phase 3.
NotebookLM Deep Research (if complex domain): For unfamiliar domains, regulations, or complex integrations:
nlm research startCodex Second Opinion (if architecture is non-obvious):
Before moving to architecture, present findings to the user:
## Research Summary
### Libraries/Tools Evaluated
| Option | Pros | Cons | Docs Reviewed |
|--------|------|------|---------------|
| {lib} | ... | ... | Context7 ✓ |
### Existing Code to Reuse
- {file}: {pattern/utility} — reusable for {purpose}
### Key Findings
- {insight from research}
### Risks/Gotchas Discovered
- {pitfall to avoid}
Pause for user feedback. They may redirect the research or confirm the direction.
Present 1-2 architecture options. Not 5 — decision fatigue is real. Lead with the recommended approach.
## Recommended Architecture
### Overview
{One-paragraph summary of the approach}
### Stack
- Frontend: {choice + why}
- Backend: {choice + why}
- Database: {choice + why}
- Deployment: {choice + why}
### Data Flow
{How data moves through the system — brief description or simple diagram}
### Key Decisions
| Decision | Choice | Why | Alternatives Considered |
|----------|--------|-----|------------------------|
### File Structure
{Proposed directory layout}
If there's a meaningful alternative approach, present it briefly with tradeoffs. Let the user choose. Record decisions (these feed into PROJECT_STATE.md later).
Generate a structured task plan that /subagent-driven-development can consume
directly. This is the output of /design.
## Implementation Plan
### Tasks (ordered by dependency)
1. **{Task name}** — {description}
- Files: {files to create/modify}
- Dependencies: {what must exist first, or "none"}
- Touches DB: {yes/no}
- Verification: {how to prove this works}
2. **{Task name}** — {description}
- Files: ...
- Dependencies: Task 1
- Touches DB: ...
- Verification: ...
### Smoke Test Strategy
{What checks should smoke_test.sh include for this project}
### Verification Strategy
{What ground-truth values to add to VERIFICATION.md, if data-backed}
### Estimated Scope
{task count, rough complexity: small/medium/large}
Present the complete plan to the user for approval.
After user approves:
/project-init — pass along the design context (stack, DB,
external services, data sources) so project-init can scaffold accurate docs
without re-asking questions the user already answeredsmoke_test.sh from the plan's
smoke test strategy (if project-init didn't already create one)/subagent-driven-development with the generated plansmoke_test.sh doesn't exist, scaffold it from the plan/subagent-driven-development with the generated planNo manual copy-paste needed — the plan is already in the format SDD expects.