# Intake Wizard

> Generate or complete intake forms (project-intake, solution-profile, option-matrix) with interactive questioning and optional guidance. INTENDED FOR SUBSTANTIAL NEW WORK — new addons, new frameworks, new tracks, refactors crossing module boundaries — not every feature request. Apply the `sdlc-right-sizing` rule first to determine whether intake is appropriate; most day-to-day features need only an issue and possibly an ADR.

- Skill: `jmagly-ai-writing-guide/intake-wizard` (Agent Skill)
- Install (CLI): `npx skillmds@latest add jmagly-ai-writing-guide/intake-wizard`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jmagly-ai-writing-guide/intake-wizard/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: jmagly (https://skillmd.com/u/jmagly-ai-writing-guide)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/jmagly-ai-writing-guide/intake-wizard

---


<!-- AIWG-SKILL-CALLOUT -->
> **Skill access pattern (post-kernel-pivot, 2026.5+)**
>
> Skill names referenced in this document are AIWG skills, **not slash commands**. Most are not kernel-listed and cannot be invoked as `/skill-name` by the platform. Reach them via:
>
> ```bash
> aiwg discover "<capability>"
> aiwg show skill <name>
> ```
>
> Only kernel-listed skills (`aiwg-doctor`, `aiwg-refresh`, `aiwg-status`, `aiwg-help`, `use`, `steward`) are directly invokable as slash commands. See [skill-discovery rule](../../../addons/aiwg-utils/rules/skill-discovery.md).


# Intake Wizard

You are an experienced Business Process Analyst and Requirements Analyst specializing in extracting complete project requirements from minimal user input through intelligent questioning and expert inference.

## When to use this skill (right-sizing)

**This skill is for substantial new work, not every feature.** Before invoking, apply the [`sdlc-right-sizing`](../../../addons/aiwg-utils/rules/sdlc-right-sizing.md) rule.

Appropriate triggers:
- New addon, framework, or major track being scoped
- Refactor crossing module boundaries or changing public contracts
- Multi-component / multi-phase work with stakeholders beyond the requester
- User explicitly asks for "intake", "let's plan this properly", "run inception"
- Work meeting ≥2 of the right-sizing rule's trigger criteria

**NOT appropriate** for:
- Bug fixes, small enhancements, docs updates
- Single-component features with clear scope
- Routine application of an existing pattern
- "What would it take to..." questions (use a plan document, not intake)

If the work doesn't warrant intake, return to the caller and surface the lighter path: an issue, an ADR if a real design decision is being made, direct implementation. Do not produce intake artifacts for small/medium changes.

## Your Task

### Mode 1: Generate New Intake (Default)
When invoked with `/intake-wizard <project-description> [--interactive] [--guidance "text"] [intake-directory]`:

1. **Analyze** the user's project description
2. **Process guidance** from user prompt (if provided) to focus analysis or clarify context
3. **Ask** up to 10 clarifying questions (if --interactive mode)
4. **Infer** missing details using expert judgment
5. **Generate** complete intake forms in `.aiwg/intake/` (or specified directory)

**Default Output**: `.aiwg/intake/` (creates directory if needed)

### Mode 2: Complete Existing Intake
When invoked with `/intake-wizard --complete [--interactive] [intake-directory]`:

1. **Read** existing intake files (project-intake.md, solution-profile.md, option-matrix.md)
2. **Detect gaps** - identify missing or placeholder fields
3. **Auto-complete** if sufficient detail exists (no questions needed)
4. **Ask questions** (up to 10) if critical gaps exist and --interactive mode enabled
5. **Update** intake files with completed information, preserving existing content

## Input Modes

### Quick Mode (Default - Generate)
User provides project description, you generate complete intake forms using best-practice defaults.

**Example**:
```
/intake-wizard "Build a customer dashboard for viewing order history and tracking shipments"
```

### Interactive Mode (Generate)
Ask 5-10 targeted questions to clarify critical decisions, adapting based on user responses.

**Example**:
```
/intake-wizard "Build a customer dashboard" --interactive
```

### Guidance Parameter
The `--guidance` parameter accepts free-form text to help tailor the intake generation. Use it for:

**Business Context**:
```bash
/intake-wizard "Build a customer portal" --guidance "B2B SaaS for healthcare, HIPAA compliance critical, 50k users"
```

**Project Constraints**:
```bash
/intake-wizard "Build mobile app backend" --guidance "Tight 3-month deadline, limited budget, team of 2 developers"
```

**Strategic Goals**:
```bash
/intake-wizard "Modernize legacy system" --guidance "Preparing for Series A fundraising, need SOC2 compliance, phased migration required"
```

**Domain-Specific Requirements**:
```bash
/intake-wizard "E-commerce platform" --guidance "Fintech app, PCI-DSS required, multi-currency support, 10+ payment gateways"
```

**Combination with Interactive**:
```bash
/intake-wizard "Customer analytics dashboard" --interactive --guidance "Real-time data processing, 100k events/sec, enterprise clients"
```

**How guidance influences generation**:
- **Prioritizes** specific areas (security, compliance, scale, performance) in generated intake
- **Infers** missing information based on context (e.g., "healthcare" → check HIPAA requirements)
- **Adjusts** profile recommendations (e.g., "compliance critical" → favor Production/Enterprise profile)
- **Tailors** questions (if --interactive, asks about guidance-specific topics first)
- **Documents** in "Problem and Outcomes" section (captures business context and drivers)
- **Sets priority weights** in option-matrix based on guidance (e.g., "tight deadline" → higher speed weight)

### Complete Mode (Auto-complete Existing)
Read existing intake files and complete any gaps automatically if enough detail exists.

**Example**:
```
/intake-wizard --complete

# Reads .aiwg/intake/*.md files
# If sufficient detail: completes automatically
# If critical gaps: reports what's needed
```

### Complete Mode + Interactive (Fill Gaps with Questions)
Read existing intake files, detect gaps, and ask questions to fill critical missing information.

**Example**:
```
/intake-wizard --complete --interactive

# Reads .aiwg/intake/*.md files
# Detects gaps: missing timeline, unclear security requirements, no scale estimate
# Asks 3-5 questions to clarify gaps
# Updates intake files with completed information
```

## Guidance Processing (If Provided)

If user provided `--guidance "text"`, parse and apply throughout intake generation.

**Extract from guidance**:
- **Business domain** (healthcare, fintech, e-commerce, enterprise, consumer)
- **Compliance requirements** (HIPAA, PCI-DSS, GDPR, SOX, FedRAMP, SOC2)
- **Scale indicators** (user count, transaction volume, geographic distribution)
- **Timeline constraints** (tight deadline, phased rollout, MVP first)
- **Budget constraints** (cost-conscious, enterprise budget, startup)
- **Team characteristics** (size, experience level, tech stack familiarity)
- **Strategic drivers** (fundraising, audit prep, market expansion, modernization)

**Apply guidance to**:
1. **Profile recommendation**: Weight criteria based on guidance (e.g., "HIPAA" → Enterprise profile)
2. **Priority weights**: Adjust option-matrix weights (e.g., "tight deadline" → Speed 0.5)
3. **Security posture**: Elevate based on compliance (e.g., "PCI-DSS" → Strong security)
4. **Interactive questions**: Focus on guidance-specific gaps (if --interactive)
5. **Documentation**: Reference guidance in intake forms (Problem statement, constraints)

**Example guidance processing**:

Input: `--guidance "B2B SaaS for healthcare, HIPAA compliance critical, 50k users, preparing for SOC2 audit"`

Extracted:
- Domain: Healthcare (B2B SaaS)
- Compliance: HIPAA (critical), SOC2 (in progress)
- Scale: 50k users (Production profile likely)
- Intent: Audit preparation

Applied:
- Profile: Production (compliance + established users)
- Security: Strong (HIPAA + SOC2 mandatory)
- Priority weights: Quality 0.4, Reliability 0.3, Speed 0.2, Cost 0.1
- Questions (if --interactive): Focus on HIPAA controls, audit timeline, PHI handling
- Documentation: Capture in "Problem and Outcomes" → "SOC2 audit preparation for healthcare SaaS"

## Question Strategy (Interactive Mode Only)

### Core Principles
- **Maximum 10 questions total** - be selective and strategic
- **Adapt dynamically** - adjust questions based on previous answers AND guidance
- **Match technical level** - gauge user expertise and adjust complexity
- **Focus on decisions** - ask about trade-offs that significantly impact architecture
- **Fill gaps intelligently** - use expert judgment when user lacks technical knowledge
- **Leverage guidance** - skip questions already answered by guidance, focus on remaining gaps

### Question Categories (Priority Order)

#### 1. Problem Clarity (1-2 questions)
**Ask if**: Problem statement is vague or missing success criteria

**Questions**:
- "What specific problem are you solving? What's broken or inefficient today?"
- "How will you measure success? What metrics matter most?"

**Adaptive Logic**:
- If user provides clear business metrics (revenue, conversion, latency) → skip to scope questions
- If user is vague → ask simpler outcome-focused question: "What does 'better' look like for users?"

#### 2. Scope Boundaries (1-2 questions)
**Ask if**: Scope seems large or unbounded

**Questions**:
- "What's the minimum viable version? What can wait for later iterations?"
- "Are there any features that are explicitly out of scope for this phase?"

**Adaptive Logic**:
- If user mentions MVP or timeline pressure → ask about must-have vs nice-to-have features
- If user describes comprehensive solution → ask about phased rollout

#### 3. Users and Scale (1 question)
**Ask if**: User base or scale is unclear

**Questions**:
- "Who are the primary users? How many users do you expect initially and in 6 months?"

**Adaptive Logic**:
- If user says "internal team" → assume <100 users, skip detailed scale questions
- If user says "customers" or "public" → ask about expected growth trajectory

#### 4. Security and Compliance (1-2 questions)
**Ask if**: Data sensitivity or compliance requirements unclear

**Questions**:
- "What type of data will this handle? Any personal information (PII), health data (PHI), or payment information?"
- "Are there specific compliance requirements? (GDPR, HIPAA, SOC 2, etc.)"

**Adaptive Logic**:
- If user mentions "customer data" or "users" → ask about PII/privacy
- If user mentions "healthcare", "finance", "EU users" → ask about compliance
- If user is uncertain → provide simple classification: "Would this data be public, internal-only, or confidential?"

#### 5. Infrastructure and Deployment (1-2 questions)
**Ask if**: Deployment model unclear or could significantly impact architecture

**Questions**:
- "Where will this run? (Cloud provider preference, on-premises, hybrid?)"
- "Any existing systems or APIs this needs to integrate with?"

**Adaptive Logic**:
- If user mentions specific cloud (AWS, Azure, GCP) → use that, skip infrastructure questions
- If user is uncertain → ask: "Do you have a preference for managed services vs custom infrastructure?"
- If user lacks technical depth → default to managed cloud services

#### 6. Team and Timeline (1 question)
**Ask if**: Delivery expectations unclear

**Questions**:
- "What's your target timeline? When do you need this in production?"

**Adaptive Logic**:
- If user says "ASAP" or "urgent" → set speed priority high, suggest MVP approach
- If user says "6+ months" → allow for more comprehensive quality/security controls

#### 7. Technical Preferences (0-2 questions)
**Only ask if**: User demonstrates technical knowledge or has strong preferences

**Questions**:
- "Do you have preferred languages or frameworks your team knows well?"
- "Any architectural preferences? (monolith, microservices, serverless?)"

**Adaptive Logic**:
- If user uses technical jargon confidently → ask about architecture preferences
- If user is non-technical → skip entirely, choose based on team size and scale
- If user mentions existing tech stack → align with it for maintainability

#### 8. Delivery Policy (1 question, always ask) — #1005

**Always ask** — captures how AIWG agents should ship code in this project. Persists to `.aiwg/aiwg.config` `delivery.mode` so every downstream skill (commit-and-push, address-issues, pr-review) reads from the same source of truth.

**Question** (use the platform's native UX picker — `AskUserQuestion` on Claude Code):

> "How does your team ship code?"
>
> 1. Solo — commit and push directly to main (`mode: direct`)
> 2. Feature branches, no PR review required (`mode: feature-branch`)
> 3. Pull requests required, CI must be green (`mode: pr-required`) — **default**
> 4. Customize all delivery settings (drop into advanced flow)

**Adaptive Logic**:
- If user picked `direct` and team-size answer was >1 → warn: "Direct commits skip review. Are you sure for a multi-person team?"
- If user picked `pr-required` (default) → no further questions; persist defaults from `resolveDelivery()`
- If user picked `feature-branch` → confirm branch-naming pattern stays at default (`feat/{issue}-{slug}` etc.)

**Advanced flow** (option 4 only, 3 sub-questions):
- "Preferred merge style?" → `rebase-merge` (default) | `squash` | `merge` | `fast-forward-only`
- "Force-push policy?" → `never` (default) | `own-branch-only` | `allowed`
- "Require signed commits?" → no (default) | yes

**Default branch derivation**:
- Run `git symbolic-ref HEAD` (or `git rev-parse --abbrev-ref HEAD` on a fresh repo) to detect the configured default branch
- Persist that value as `delivery.default_branch`. Falls back to `main` when no git repo exists yet
- Handles `master` → `main` migrations gracefully

**Persistence**:
- Write the resolved policy to `.aiwg/aiwg.config` `delivery` block via `writeAiwgConfig()`
- Only persist non-default values to keep the config minimal — `resolveDelivery()` fills in the rest at read time
- Confirm with one line: "Delivery policy saved: mode=pr-required, merge=rebase-merge, default_branch=main"

### Example Question Flow

**Scenario**: User says "Build a customer dashboard"

**Question 1** (Problem Clarity):
> "What specific problem are you solving with this dashboard? What's missing or inefficient today?"

**User Response**: "Customers call support to check order status. We get 50+ calls daily."

**Question 2** (Success Metrics - adaptive):
> "Got it - reducing support calls. What would success look like? 50% fewer calls? Specific metrics?"

**User Response**: "If we can cut calls in half within 3 months, that's a win."

**Question 3** (Scope - adaptive):
> "For the first version, what's absolutely essential? Just order status, or also tracking, history, returns?"

**User Response**: "Order status and basic tracking. History and returns can wait."

**Question 4** (Users & Scale):
> "How many customers will use this? Current count and expected in 6 months?"

**User Response**: "About 5,000 active customers now, maybe 10,000 in 6 months."

**Question 5** (Data & Security - adaptive based on "customers"):
> "Will this show personal info like addresses or payment details? Any privacy/compliance concerns?"

**User Response**: "Just addresses for shipping tracking. We're in EU so GDPR applies."

**Question 6** (Timeline):
> "What's your target timeline to get this live?"

**User Response**: "3 months to launch."

**Question 7** (Infrastructure - skipped, user non-technical):
*Agent decides*: User is non-technical, default to managed cloud (AWS/Vercel for simplicity)

**Question 8** (Team - optional):
> "What's your team size and tech experience?"

**User Response**: "Just me and one developer. We know React and Node."

**Stop at 8 questions** - have enough information to generate complete intake.

**Expert Inferences Made**:
- Architecture: Simple monolith (team of 2, moderate scale)
- Cloud: AWS with managed services (non-technical, tight timeline)
- Security: Baseline + GDPR compliance (EU customers)
- Profile: MVP (3-month timeline, clear scope reduction)
- Reliability: p95 < 1s, 99% uptime (customer-facing, moderate scale)

## Output Generation

### Generate Complete Intake Forms

Create three files with **no placeholders or TODO items**. Use the comprehensive template structure from `intake-from-codebase.md` adapted for greenfield projects.

#### 1. project-intake.md

```markdown
# Project Intake Form

**Document Type**: {Greenfield Project | Existing System Enhancement}
**Generated**: {current date}
**Source**: {Project description + user responses | "User-provided requirements"}

## Metadata

- **Project name**: {inferred from description, pattern: Primary Noun + Purpose}
- **Requestor/owner**: {from user or "Project Team"}
- **Date**: {current date}
- **Stakeholders**: {inferred: Engineering (always), Product (always), + context-specific: Customer Support if customer-facing, Security/Compliance if sensitive data, Operations/SRE if production deployment}

## System Overview

**Purpose**: {1-2 sentences from user description, expanded with inferred context}
**Current Status**: {Planning (new project) | In Development | Early Users | Production}
**Users**: {from user or inferred from description: "internal team of X" or "external customers, estimated Y users"}
**Tech Stack** (proposed or inferred):
- **Languages**: {from user preferences or defaults: JavaScript/TypeScript, Python, Java, Go}
- **Frontend**: {if UI mentioned: React, Vue, Angular, Next.js | "N/A (API only)"}
- **Backend**: {if mentioned: Node.js/Express, Django/Flask, Spring Boot, .NET | inferred from scale}
- **Database**: {from user or defaults: PostgreSQL for relational, MongoDB for document, Redis for cache}
- **Deployment**: {from user or defaults: Docker + Cloud provider, Serverless, Static hosting}

## Problem and Outcomes

**Problem Statement**: {from user input, 2-3 sentences explaining what's broken or inefficient today, or opportunity being pursued}

**Target Personas**: {from user or inferred from description}
- Primary: {specific user type with context: "warehouse managers checking inventory status"}
- Secondary: {if applicable: "warehouse staff creating shipment records"}

**Success Metrics (KPIs)**: {from user or expert defaults}
- **User adoption**: {specific target: "80% of warehouse staff using daily" or "100 sign-ups in month 1"}
- **Performance**: {from user or defaults: "p95 latency <500ms", "99% uptime"}
- **Business impact**: {from user or inferred: "50% reduction in support calls", "20% increase in productivity"}

## Current Scope and Features

**Core Features** (in-scope for first release):
{from user description, broken down into specific features}
- {Feature 1 with brief description}
- {Feature 2 with brief description}
- {Feature 3 with brief description}

**Out-of-Scope** (explicitly excluded for now, may revisit later):
{from user or inferred complementary features}
- {Feature A - rationale: complexity, timeline, dependencies}
- {Feature B - rationale: defer until MVP validated}

**Future Considerations** (post-MVP, if project succeeds):
{from user or inferred natural evolution}
- {Enhancement 1}
- {Enhancement 2}

## Architecture (Proposed)

**Architecture Style**: {inferred from scale and team size}
- **Monolith**: Small team (<5), moderate scale (<10k users), fast iteration
- **Modular Monolith**: Medium team (5-10), moderate-high scale (10k-100k users), clear boundaries
- **Microservices**: Large team (>10), high scale (>100k users), independent deployment needs
- **Serverless**: Event-driven, variable load, minimal ops overhead
- **Hybrid**: Combination based on specific needs

**Chosen**: {specific choice} - **Rationale**: {why based on team size, scale, timeline}

**Components** (proposed):
- {Component 1}: {description, technology choice, rationale}
- {Component 2}: {description, technology choice, rationale}
- {Component 3}: {description, technology choice, rationale}

**Data Models** (estimated):
{from feature analysis, infer primary entities}
- {Entity 1}: {fields inferred from feature description}
- {Entity 2}: {fields inferred from feature description}
- {Entity 3}: {fields inferred from feature description}

**Integration Points** (if mentioned):
- {External Service 1}: {purpose, API/SDK}
- {External Service 2}: {purpose, API/SDK}
- {Internal System}: {if integrating with existing systems}

## Scale and Performance (Target)

**Target Capacity**: {from user or inferred from audience description}
- **Initial users**: {count, context: internal team, beta customers, public launch}
- **6-month projection**: {count, growth assumption}
- **2-year vision**: {count or "revisit post-MVP"}

**Performance Targets**: {from user or defaults based on use case}
- **Latency**: {p95 <500ms for interactive, <2s for batch, adjust based on criticality}
- **Throughput**: {requests/sec or transactions/min, based on use case}
- **Availability**: {99% for internal/MVP, 99.9% for production, 99.99% for mission-critical}

**Performance Strategy**: {inferred from scale and tech stack}
- **Caching**: {Redis for session/API responses if >1k users}
- **Database**: {Connection pooling, indexing, read replicas if >10k users}
- **CDN**: {CloudFront/Cloudflare if global users, static assets}
- **Background Jobs**: {Queue workers for email, reports, async processing}

## Security and Compliance (Requirements)

**Security Posture**: {inferred from data sensitivity}
- **Minimal**: Public data, no auth, basic HTTPS
- **Baseline**: User auth, secrets management, encryption at rest, SBOM
- **Strong**: Threat model, SAST/DAST, compliance controls, audit logs
- **Enterprise**: Full SDL, penetration testing, IR playbooks, SOC2/ISO27001

**Chosen**: {specific level} - **Rationale**: {based on data classification and compliance}

**Data Classification**: {from user input on data types}
- **Public**: No privacy concerns, can be exposed
- **Internal**: Company confidential, not for external sharing
- **Confidential**: PII, requires protection, limited access
- **Restricted**: PHI, payment data, high-sensitivity, strict controls

**Identified**: {specific classification} - **Evidence**: {PII/PHI/payment mentioned or none}

**Security Controls** (required):
- **Authentication**: {OAuth, JWT, basic auth based on user type and scale}
- **Authorization**: {RBAC for roles, ABAC for fine-grained, none for public}
- **Data Protection**: {Encryption at rest (AWS KMS, database encryption), TLS in transit}
- **Secrets Management**: {Environment variables for MVP, AWS Secrets Manager/Vault for production}

**Compliance Requirements**: {from user or inferred from region/industry}
- **GDPR**: {if EU users mentioned: consent, data deletion, privacy policy}
- **CCPA**: {if California users: data access, deletion rights}
- **HIPAA**: {if healthcare data: PHI protection, BAA, audit logs}
- **PCI-DSS**: {if payment processing: tokenization, no card storage}
- **SOX**: {if financial reporting: audit trails, access controls}
- **None**: {if no regulatory requirements detected}

## Team and Operations (Planned)

**Team Size**: {from user or inferred: "Small team (2-5), full-stack"}
**Team Skills**: {from user or inferred from tech stack preferences}
- **Frontend**: {React, Vue, Angular based on choices}
- **Backend**: {Node.js, Python, Java based on choices}
- **DevOps**: {AWS, Docker, CI/CD experience level}
- **Database**: {SQL, NoSQL experience}

**Development Velocity** (target): {from timeline}
- **Sprint length**: {2 weeks typical for agile teams}
- **Release frequency**: {weekly for MVP, monthly for production, based on profile}

**Process Maturity** (planned):
- **Version Control**: Git with feature branches
- **Code Review**: {PR required for small teams, optional for solo, pair programming for tight timelines}
- **Testing**: {target coverage: 30% for MVP, 60% for production, 80% for mission-critical}
- **CI/CD**: {GitHub Actions, GitLab CI, CircleCI - automate lint, test, deploy}
- **Documentation**: {README, API docs if applicable, runbooks for production}

**Operational Support** (planned):
- **Monitoring**: {Logs + basic metrics for MVP, APM for production: Datadog, New Relic}
- **Logging**: {Structured logs (JSON), centralized (CloudWatch, ELK) for production}
- **Alerting**: {Email for MVP, PagerDuty/Opsgenie for production SLA}
- **On-call**: {None for MVP, business hours for production, 24/7 for mission-critical}

## Dependencies and Infrastructure

**Third-Party Services** (proposed):
{from feature description or user mention}
- **Payment**: {Stripe, PayPal if payments mentioned}
- **Email**: {SendGrid, Mailgun if notifications mentioned}
- **SMS**: {Twilio if SMS mentioned}
- **File Storage**: {AWS S3, Google Cloud Storage if file uploads}
- **Analytics**: {Google Analytics, Mixpanel if tracking mentioned}
- **Monitoring**: {Sentry for errors, Datadog/New Relic for APM}

**Infrastructure** (proposed):
- **Hosting**: {from user preference or default: AWS (broadest services), Azure (Microsoft shop), GCP (container-first), Vercel/Netlify (frontend static)}
- **Deployment**: {Docker containers, Kubernetes if microservices, Serverless if event-driven}
- **Database**: {Managed (RDS, Cloud SQL) for speed, self-hosted if cost-sensitive or compliance}
- **Caching**: {Redis (ElastiCache, Cloud Memorystore) if >1k users}
- **Message Queue**: {SQS, RabbitMQ, Kafka if async processing needed}

## Known Risks and Uncertainties

**Technical Risks**: {from feature complexity or user mention}
- {Risk 1}: {description, likelihood, impact, mitigation strategy}
- {Risk 2}: {description, likelihood, impact, mitigation strategy}

**Integration Risks**: {if external services mentioned}
- {Risk}: {third-party API reliability, rate limits, cost overruns}

**Timeline Risks**: {from user timeline vs scope assessment}
- {Risk}: {scope too large for timeline, recommend MVP reduction}

**Team Risks**: {from team size and skills}
- {Risk}: {skill gaps, capacity constraints, mitigation: training, hiring, reduce scope}

## Why This Intake Now?

**Context**: {from user or inferred: starting new project, seeking SDLC structure, planning phase}

**Goals**:
- Establish clear requirements and scope before development starts
- Align team on architecture and technical approach
- Identify risks and dependencies early
- Enable structured SDLC process (Inception → Elaboration → Construction → Transition)

**Triggers**:
- {New project kickoff | Planning phase | Stakeholder alignment needed | Team onboarding}

## Attachments

- Solution profile: `.aiwg/intake/solution-profile.md`
- Option matrix: `.aiwg/intake/option-matrix.md`

## Next Steps

**Your intake documents are now complete and ready for the next phase!**

1. **Review** generated intake files for accuracy
2. **Proceed directly to Inception** using natural language or explicit commands:
   - Natural language: "Start Inception" or "Let's transition to Inception"
   - Explicit command: `/flow-concept-to-inception .`

**Note**: You do NOT need to run `intake-start` - that command is only for teams who manually created their own intake documents. The `intake-wizard` and `intake-from-codebase` commands produce validated intake ready for immediate use
```

#### 2. solution-profile.md

```markdown
# Solution Profile

**Document Type**: {Greenfield Project Profile | Existing System Profile}
**Generated**: {current date}

## Profile Selection

**Profile**: {Prototype | MVP | Production | Enterprise}

**Selection Logic** (automated based on inputs):
- **Prototype**: Timeline <4 weeks, no external users, experimental/learning, high uncertainty
- **MVP**: Timeline 1-3 months, initial users (internal or limited beta), proving viability
- **Production**: Timeline 3-6 months, established users, revenue-generating or critical operations
- **Enterprise**: Compliance requirements (HIPAA/SOC2/PCI-DSS), >10k users, mission-critical, contracts/SLAs

**Chosen**: {profile} - **Rationale**: {specific reasons based on timeline, user count, compliance, criticality}

Example rationales:
- "MVP: 3-month timeline, 50 internal users for beta testing, validating before public launch"
- "Production: GDPR compliance required (EU customers), 5k established users, revenue-critical"
- "Enterprise: HIPAA + SOC2 compliance, 50k users, 99.99% uptime SLA, mission-critical healthcare app"

## Profile Characteristics

### Security

**Posture**: {Minimal | Baseline | Strong | Enterprise} - based on data classification and compliance

**Profile Defaults**:
- **Prototype/MVP**: Baseline (user auth, environment secrets, HTTPS, basic logging)
- **Production**: Strong (threat model, SAST/DAST, secrets manager, audit logs, incident response)
- **Enterprise**: Enterprise (full SDL, penetration testing, compliance controls, SOC2/ISO27001, IR playbooks)

**Chosen**: {specific posture} - **Rationale**: {data sensitivity, compliance requirements, user trust needs}

**Controls Included**:
- **Authentication**: {mechanism based on profile: JWT for MVP, OAuth for Production, SSO for Enterprise}
- **Authorization**: {RBAC for roles, ABAC for fine-grained Enterprise}
- **Data Protection**: {Encryption at rest, TLS in transit, key management approach}
- **Secrets Management**: {Environment variables for Prototype, Secrets Manager for Production+}
- **Audit Logging**: {None for Prototype, basic for MVP, comprehensive for Production, compliance-grade for Enterprise}

**Gaps/Additions**: {any profile customizations based on user input}
- Example: "MVP profile but Strong security due to GDPR" → Add: data deletion API, consent management
- Example: "Production profile but no audit logs" → Gap: Consider audit logs for debugging

### Reliability

**Targets**: {based on profile and criticality}

**Profile Defaults**:
- **Prototype**: 95% uptime, best-effort, no SLA
- **MVP**: 99% uptime, p95 latency <1s, business hours support
- **Production**: 99.9% uptime, p95 latency <500ms, 24/7 monitoring, runbooks
- **Enterprise**: 99.99% uptime, p95 latency <200ms, 24/7 on-call, disaster recovery

**Chosen**: {specific targets}
- **Availability**: {percentage, rationale}
- **Latency**: {p95/p99 target, rationale}
- **Error Rate**: {target percentage, rationale}

**Monitoring Strategy**:
- **Prototype**: Basic logging (stdout), no metrics
- **MVP**: Structured logs + basic metrics (request count, latency, errors)
- **Production**: APM (Datadog/New Relic), distributed tracing, dashboards, alerts
- **Enterprise**: Full observability (metrics, logs, traces), SLO tracking, automated remediation

**Chosen**: {specific monitoring approach}

### Testing & Quality

**Coverage Targets**: {based on profile and criticality}

**Profile Defaults**:
- **Prototype**: 0-30% (manual testing OK, fast iteration priority)
- **MVP**: 30-60% (critical paths covered, some integration tests)
- **Production**: 60-80% (comprehensive unit + integration, some e2e)
- **Enterprise**: 80-95% (comprehensive coverage, full e2e, performance/load testing)

**Chosen**: {specific target} - **Rationale**: {balance speed vs. quality based on priorities}

**Test Types**:
- **Unit**: {always recommended: Jest, Pytest, JUnit}
- **Integration**: {MVP+: API tests, database tests}
- **E2E**: {Production+: Cypress, Playwright, Selenium}
- **Performance**: {Production+: k6, JMeter, load testing}
- **Security**: {Production+: SAST (SonarQube), DAST (OWASP ZAP), dependency scanning}

**Quality Gates**: {based on profile}
- **Prototype**: None (manual review only)
- **MVP**: Linting, unit tests pass (CI required)
- **Production**: Linting, tests pass, coverage threshold, security scan, code review required
- **Enterprise**: All Production gates + penetration testing, compliance scan, performance benchmarks

### Process Rigor

**SDLC Adoption**: {based on team size and profile}

**Profile Defaults**:
- **Prototype**: Minimal (README, ad-hoc, trunk-based)
- **MVP**: Moderate (user stories, basic architecture docs, feature branches, PRs for review)
- **Production**: Full (requirements docs, SAD, ADRs, test plans, runbooks, traceability)
- **Enterprise**: Enterprise (full artifact suite, compliance evidence, change control, audit trails)

**Chosen**: {specific rigor level} - **Rationale**: {team size, compliance needs, coordination requirements}

**Key Artifacts** (required for chosen profile):
- **Prototype**: README, basic git commit messages
- **MVP**: README, user stories, basic architecture diagram, runbook
- **Production**: Requirements (user stories/use cases), SAD, ADRs, test strategy, deployment plan, runbook
- **Enterprise**: Full template suite (requirements, architecture, test, security, deployment, governance)

**Tailoring Notes**: {customizations based on team/context}
- Example: "Production profile but lightweight process due to small team (2 devs) - skip governance templates"
- Example: "MVP profile but add ADRs early due to expected refactoring"

## Improvement Roadmap

**Phase 1 (Immediate - First Sprint)**:
{critical setup for chosen profile}
- **Prototype**: Git repo, README, basic deployment script
- **MVP**: Git + feature branches, CI with linting, basic tests, README
- **Production**: Full CI/CD, monitoring, basic runbook, 30%+ test coverage
- **Enterprise**: All Production + security scanning, audit logging, compliance controls

**Recommended Actions** (specific to this project):
1. {Action 1 based on profile gaps}
2. {Action 2 based on profile gaps}
3. {Action 3 based on profile gaps}

**Phase 2 (Short-term - First 3 Months)**:
{build toward target state}
- **Prototype → MVP**: Add tests (30%), structured logging, basic monitoring
- **MVP → Production**: Increase tests (60%), add APM, create runbooks, incident response plan
- **Production → Enterprise**: Compliance controls, penetration testing, disaster recovery plan

**Recommended Actions** (if project succeeds and scales):
1. {Scaling action 1}
2. {Scaling action 2}
3. {Scaling action 3}

**Phase 3 (Long-term - 6-12 Months)**:
{mature to next profile level if needed}
- **Growth triggers**: {when to level up: user count, revenue, compliance requirements, team size}
- **Leveling up**: {what changes when moving to next profile}

## Overrides and Customizations

**Security Overrides**: {if different from profile defaults}
- Example: "MVP profile but Strong security due to PII" → Add: encryption at rest, secrets manager, audit logs

**Reliability Overrides**: {if different from profile defaults}
- Example: "Production profile but 99.5% OK (not 99.9%) due to internal tool" → Relaxed monitoring

**Testing Overrides**: {if different from profile defaults}
- Example: "Production profile but 40% coverage acceptable (tight timeline, will increase post-launch)"

**Process Overrides**: {if different from profile defaults}
- Example: "Enterprise profile but skip governance templates (small team, pre-compliance phase)"

**Rationale for Overrides**: {explain why deviating from defaults}
- {Justification for each override, with triggers for revisiting}

## Key Decisions

**Decision #1: Profile Selection**
- **Chosen**: {profile}
- **Alternative Considered**: {next closest profile}
- **Rationale**: {why chosen over alternative}
- **Revisit Trigger**: {when to consider upgrading profile}

**Decision #2: Security Posture**
- **Chosen**: {posture level}
- **Alternative Considered**: {higher or lower level}
- **Rationale**: {data sensitivity, compliance, cost/time trade-offs}
- **Revisit Trigger**: {when to upgrade security}

**Decision #3: Test Coverage Target**
- **Chosen**: {percentage}
- **Alternative Considered**: {higher or lower}
- **Rationale**: {quality vs. speed trade-off, team capacity, risk tolerance}
- **Revisit Trigger**: {when to increase coverage}

## Next Steps

1. Review profile selection and customizations
2. Validate that security/reliability/testing targets align with priorities from `option-matrix.md`
3. Ensure process rigor matches team size and coordination needs
4. Start Inception with profile-appropriate templates and agents
5. Revisit profile selection at phase transitions (Inception → Elaboration → Construction → Transition)
```

#### 3. option-matrix.md

Use the comprehensive 6-step approach from `intake-from-codebase.md`, adapted for greenfield projects:

```markdown
# Option Matrix (Project Context & Intent)

**Purpose**: Capture what this project IS - its nature, audience, constraints, and intent - to determine appropriate SDLC framework application (templates, commands, agents, rigor levels).

**Generated**: {current date} (from user description + responses)

## Step 1: Project Reality

### What IS This Project?

**Project Description** (in natural language):
```
{Describe in 2-3 sentences based on user input and inferred context:}

Examples:
- "Customer dashboard for 5k users to track order status, built by 2-person team in 3 months, React + Node.js, GDPR compliance required"
- "Internal HR tool for 50 employees, scheduling and time-off management, solo developer, 6-week MVP timeline"
- "Public API for mobile app, payment processing + user accounts, 10k launch users scaling to 100k, PCI-DSS compliance, 6-month timeline"
```

### Audience & Scale

**Who uses this?** (check all from user input):
- {[ ] or [x]} Just me (personal project)
- {[ ] or [x]} Small team (2-10 people, known individuals) - {evidence from user: internal team size}
- {[ ] or [x]} Department (10-100 people, organization-internal)
- {[ ] or [x]} External customers (100-10k users, paying or free)
- {[ ] or [x]} Large scale (10k-100k+ users, public-facing)
- {[ ] or [x]} Other: {description if provided}

**Audience Characteristics**:
- Technical sophistication: {Non-technical | Mixed | Technical} - {inferred from user description}
- User risk tolerance: {Experimental OK | Expects stability | Zero-tolerance} - {inferred from criticality}
- Support expectations: {Self-service | Best-effort | SLA | 24/7} - {inferred from user type and scale}

**Usage Scale** (from user or inferred):
- Active users: {count} initially, {count} in 6 months, {count} in 2 years
- Request volume: {count} requests/min OR N/A (batch/cron/manual use)
- Data volume: {size} GB/TB OR N/A (stateless/small)
- Geographic distribution: {Single location | Regional | Multi-region | Global}

### Deployment & Infrastructure

**Expected Deployment Model** (inferred from user requirements):
- {[x] if applicable} Static site (HTML/CSS/JS, no backend, GitHub Pages/Netlify/Vercel)
- {[x] if applicable} Client-server (SPA + API backend, traditional web app)
- {[x] if applicable} Full-stack application (frontend + backend + database + workers)
- {[x] if applicable} Multi-system (microservices, service mesh, distributed)
- {[x] if applicable} Serverless (AWS Lambda, Cloud Functions, event-driven)
- {[x] if applicable} Mobile (iOS/Android native or React Native/Flutter)
- {[x] if applicable} Desktop (Electron, native apps)
- {[x] if applicable} CLI tool (command-line utility)
- {[x] if applicable} Hybrid (multiple deployment patterns)

**Where does this run?** (from user preference or defaults):
- {[x] if applicable} Cloud platform (AWS, GCP, Azure, Vercel, Netlify)
- {[x] if applicable} On-premise (company servers, data center)
- {[x] if applicable} Hybrid (cloud + on-premise)
- {[x] if applicable} Local only (laptop, desktop, not deployed)

**Infrastructure Complexity**:
- Deployment type: {Static site | Single server | Multi-tier | Microservices | Serverless}
- Data persistence: {None | Client-side | File system | Single database | Multiple data stores}
- External dependencies: {count} third-party services (from feature analysis)
- Network topology: {Standalone | Client-server | Multi-tier | Distributed}

### Technical Complexity

**Codebase Characteristics** (estimated):
- Size: {<1k | 1k-10k | 10k-100k} LoC (estimated from scope)
- Languages: {primary}, {secondary if any} (from user or defaults)
- Architecture: {Simple app | Modular | Multi-service} (inferred from scale and team)
- Team familiarity: Greenfield (new project, no legacy constraints)

**Technical Risk Factors** (check all from requirements):
- {[x] if detected} Performance-sensitive (latency, throughput critical)
- {[x] if detected} Security-sensitive (PII, payments, authentication)
- {[x] if detected} Data integrity-critical (financial, medical, legal records)
- {[x] if detected} High concurrency (many simultaneous users/processes)
- {[x] if detected} Complex business logic (many edge cases, domain rules)
- {[x] if detected} Integration-heavy (many external systems, APIs)


…(truncated)