intake-start

What this skill does

<!-- 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 Start (SDLC)

## Purpose

**IMPORTANT**: This command is for teams who have **manually crafted their own intake documents** (project-intake.md, solution-profile.md, option-matrix.md) and want to validate them before starting the SDLC process.

**If you need to generate intake documents**, use one of these instead:
- `/intake-wizard "description"` - Generate intake from scratch with interactive guidance
- `/intake-from-codebase .` - Generate intake by analyzing existing codebase

**This command is NOT required** if you used `intake-wizard` or `intake-from-codebase` - those commands produce complete, validated intake forms ready for the next phase.

## Task

Given existing, manually-created Project Intake documents:

1. **Process guidance** from user prompt (if provided) to tailor analysis
2. **Validate** required fields and note gaps
3. **Generate** or update phase-plan-inception.md and risk-list.md
4. **Recommend** initial ADRs and agent assignments
5. **Hand off** to Executive Orchestrator to start Concept → Inception flow

## Parameters

- **`<path-to-intake-folder-or-form>`** (required): Path to intake directory (default: `.aiwg/intake/`)
- **`--guidance "text"`** (optional): User-provided context to guide inception planning

### Guidance Parameter Usage

The `--guidance` parameter accepts free-form text to help tailor the Inception phase planning. Use it for:

**Process Focus**:
```bash
/intake-start .aiwg/intake/ --guidance "Focus on security architecture first, compliance is critical path"
```

**Risk Priorities**:
```bash
/intake-start .aiwg/intake/ --guidance "Third-party API integration is biggest unknown, needs spike ASAP"
```

**Team Constraints**:
```bash
/intake-start .aiwg/intake/ --guidance "Team has limited DevOps experience, need extra support for infrastructure setup"
```

**Stakeholder Expectations**:
```bash
/intake-start .aiwg/intake/ --guidance "Executive demo required in 2 weeks, need working prototype for fundraising"
```

**Technical Unknowns**:
```bash
/intake-start .aiwg/intake/ --guidance "Performance at scale unproven, need load testing POC before committing to architecture"
```

**How guidance influences planning**:
- **Prioritizes** specific risks based on guidance (e.g., "API integration" → elevate integration risks)
- **Tailors** agent assignments (e.g., "limited DevOps" → assign DevOps Engineer + provide training resources)
- **Adjusts** phase plan (e.g., "demo in 2 weeks" → front-load UI prototype tasks)
- **Highlights** critical path items (e.g., "compliance critical" → security gates moved earlier)
- **Documents** in phase-plan-inception.md (captures strategic focus and constraints)
- **Recommends** spikes/POCs based on unknowns mentioned in guidance

## Inputs

- `project-intake.md` (filled) - Comprehensive system documentation with metadata, architecture, scale, security, team details
- `solution-profile.md` (filled) - Current profile characteristics, improvement roadmap, risk mitigation, key decisions
- `option-matrix.md` (filled) - 6-step framework application analysis with priorities and trade-offs

## Outputs

- `phase-plan-inception.md` - Tailored inception plan based on validated intake
- `risk-list.md` - Prioritized risks with mitigation strategies
- `agent-assignments.md` - Recommended agent assignments based on project characteristics

## Workflow

### Step 1: Read and Process Guidance

If `--guidance` parameter provided:
- Extract guidance text from user prompt
- Document guidance in notes for later use
- Use guidance to prioritize validation checks (e.g., "security critical" → focus security validation)

### Step 2: Locate and Read Intake Documents

**Default location**: `.aiwg/intake/` (or user-provided path)

**Required files**:
1. `project-intake.md`
2. `solution-profile.md`
3. `option-matrix.md`

**Error handling**:
- If path is a directory, look for files within it
- If path is a single file, read it and look for other files in same directory
- If files missing, report which ones and stop (cannot proceed without complete intake)

### Step 3: Validate Project Intake (Comprehensive)

**Critical sections to validate** (from new comprehensive template):

#### Metadata Validation
- [ ] Project name present
- [ ] Requestor/owner identified
- [ ] Date present
- [ ] Stakeholders listed (minimum: Engineering, Product)

#### System Overview Validation
- [ ] Purpose clearly stated (1-2 sentences minimum)
- [ ] Current Status specified (Planning/Development/Early Users/Production)
- [ ] Users defined (count, personas, or description)
- [ ] Tech Stack documented:
  - [ ] Languages specified
  - [ ] Frontend (if applicable)
  - [ ] Backend (if applicable)
  - [ ] Database specified
  - [ ] Deployment approach specified

#### Problem and Outcomes Validation
- [ ] Problem statement present (for existing systems) OR goal statement (for greenfield)
- [ ] Outcomes defined (success criteria, key results)

#### Current Scope and Features Validation
- [ ] Feature list present (minimum 1 feature for MVP+, 3+ for Production)
- [ ] Features categorized or prioritized

#### Architecture Validation
- [ ] Architectural style specified (monolith/microservices/serverless/etc.)
- [ ] Major components listed (minimum 2-3 for Production+)
- [ ] Data models documented (at least high-level entities)
- [ ] Integration points identified (external APIs, third-party services)

#### Scale and Performance Validation
- [ ] Expected user capacity documented (even if estimate)
- [ ] Active users estimate provided
- [ ] Performance characteristics specified (response times, throughput, etc.)

#### Security and Compliance Validation
- [ ] Security posture stated (Minimal/Baseline/Strong/Enterprise)
- [ ] Data classification documented (if handling user data)
- [ ] Security controls listed (authentication, authorization, etc.)
- [ ] Compliance requirements specified (if any: GDPR, HIPAA, SOC2, etc.)

#### Team and Operations Validation
- [ ] Team size documented (minimum: developer count)
- [ ] Current velocity/cadence noted (for existing teams)
- [ ] Process maturity described (trunk-based, PR workflow, CI/CD, etc.)
- [ ] Operational support plan outlined (on-call, monitoring, etc.)

#### Dependencies and Infrastructure Validation
- [ ] Third-party services listed (all critical external dependencies)
- [ ] Infrastructure details specified (cloud provider, regions, etc.)

#### Known Issues and Technical Debt Validation
- [ ] Known risks documented (even if "none identified yet")
- [ ] Technical debt acknowledged (if existing system)

#### Why This Intake Now? Validation
- [ ] Context provided (why starting SDLC process now)
- [ ] Goals clearly stated
- [ ] Triggers identified (timeline, funding, user need, etc.)

**Gap Handling**:
- For **critical gaps** (no purpose, no tech stack, no team size): **STOP** and request user fill gaps
- For **moderate gaps** (missing performance estimates, unclear compliance): **WARN** and note in phase plan
- For **minor gaps** (missing optional sections): **NOTE** in validation summary

### Step 4: Validate Solution Profile (Comprehensive)

**Critical sections to validate** (from new comprehensive template):

#### Profile Selection Validation
- [ ] Profile chosen (Prototype/MVP/Production/Enterprise)
- [ ] Selection rationale provided (explains why this profile fits)

#### Current State Characteristics Validation

**Security**:
- [ ]