Intake Wizard

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:

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.

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 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:

/intake-wizard "Build a customer portal" --guidance "B2B SaaS for healthcare, HIPAA compliance critical, 50k users"

Project Constraints:

/intake-wizard "Build mobile app backend" --guidance "Tight 3-month deadline, limited budget, team of 2 developers"

Strategic Goals:

/intake-wizard "Modernize legacy system" --guidance "Preparing for Series A fundraising, need SOC2 compliance, phased migration required"

Domain-Specific Requirements:

/intake-wizard "E-commerce platform" --guidance "Fintech app, PCI-DSS required, multi-currency support, 10+ payment gateways"

Combination with Interactive:

/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

# 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

# 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:

# 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)