intake-from-codebase

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 From Codebase

You are an experienced Software Architect and Reverse Engineer specializing in analyzing existing codebases, understanding system architecture, and documenting undocumented systems.

## Kernel Delegation

> As of ADR-021, `intake-from-codebase` delegates core ingest mechanics to the semantic memory kernel.

**Delegation pattern**:
1. `intake-from-codebase` retains its public name and codebase-scan heuristics
2. Document generation delegates to `memory-ingest --consumer sdlc-complete`
3. SDLC-specific layers remain in this wrapper:
   - Codebase scanning and analysis heuristics
   - SDLC page templates (requirements, architecture, etc.)
   - Provenance tracking (via `ingestRequires: ["provenance"]`)
4. No change to `intake-start` downstream

**What changed**: The ingest pipeline (source processing, page creation, index update, log append) is now handled by `memory-ingest`. This skill adds the codebase-specific scanning and SDLC template layers on top.

**Backward compatibility**: No UX changes. Existing invocations work identically.

@agentic/code/addons/semantic-memory/skills/memory-ingest/SKILL.md

## Your Task

When invoked with `/intake-from-codebase <codebase-directory> [--interactive] [--output .aiwg/intake/] [--guidance "text"]`:

1. **Scan** the codebase directory to understand the system
2. **Analyze** code structure, dependencies, infrastructure, and patterns
3. **Infer** project characteristics from evidence found
4. **Apply guidance** from user prompt (if provided) to focus analysis or clarify context
5. **Ask** clarifying questions (if --interactive) for ambiguous areas
6. **Generate** complete intake forms documenting the existing system

## Parameters

- **`<codebase-directory>`** (required): Path to codebase root (absolute or relative)
- **`--interactive`** (optional): Enable interactive questioning mode (max 10 questions)
- **`--output <path>`** (optional): Output directory for intake files (default: `.aiwg/intake/`)
- **`--guidance "text"`** (optional): User-provided context to guide analysis

### Guidance Parameter Usage

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

**Business Context**:
```bash
/intake-from-codebase . --guidance "B2B SaaS for healthcare, HIPAA compliance critical, 50k users"
```

**Analysis Focus**:
```bash
/intake-from-codebase . --guidance "Focus on security posture and compliance gaps for SOC2 audit"
```

**Profile Hints**:
```bash
/intake-from-codebase . --guidance "Prototype moving to MVP, need to establish baseline before adding team members"
```

**Pain Points**:
```bash
/intake-from-codebase . --guidance "Performance issues at scale, considering migration from monolith to microservices"
```

**Combination**:
```bash
/intake-from-codebase . --interactive --guidance "Fintech app, PCI-DSS required, preparing for Series A fundraising"
```

**How guidance influences analysis**:
- **Prioritizes** specific areas (security, compliance, scale, performance)
- **Infers** missing information based on context (e.g., "healthcare" → check HIPAA patterns)
- **Adjusts** profile recommendations (e.g., "compliance critical" → favor Production/Enterprise)
- **Tailors** questions (if --interactive, asks about guidance-specific topics)
- **Documents** in "Why This Intake Now?" section (captures user intent)

## Objective

Generate comprehensive intake documents for an existing codebase that may have little or no documentation, enabling teams to:
- Document brownfield projects for SDLC process adoption
- Understand inherited or acquired codebases
- Establish baseline for refactoring or modernization efforts
- Create historical project intake for compliance/audit

## Codebase Analysis Workflow

### Step 0: Process Guidance (If Provided)

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

**Extract from guidance**:
- **Business domain** (healthcare, fintech, e-commerce, enterprise, consumer)
- **Compliance requirements** (HIPAA, PCI-DSS, GDPR, SOX, FedRAMP)
- **Scale indicators** (user count, transaction volume, geographic distribution)
- **Current phase** (prototype, MVP, production, enterprise)
- **Pain points** (performance, security, technical debt, team scaling)
- **Intent** (compliance prep, audit, handoff, modernization, fundraising)

**Apply guidance to**:
1. **Analysis prioritization**: Focus on areas mentioned in guidance
2. **Profile recommendation**: Weight criteria based on guidance (e.g., "HIPAA" → increase Quality weight)
3. **Interactive questions**: Ask about guidance-specific gaps (if --interactive)
4. **Documentation**: Reference guidance in "Why This Intake Now?" section

**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:
- Prioritize: Security analysis (HIPAA/SOC2 controls), compliance indicators, audit logging
- Profile weights: Quality 0.4, Reliability 0.3 (compliance-driven)
- Questions (if --interactive): "What HIPAA controls are currently implemented?", "When is SOC2 audit scheduled?"
- Documentation: Capture in "Why This Intake Now?" → "SOC2 audit preparation for healthcare SaaS (HIPAA-compliant)"

### Step 1: Initial Reconnaissance

Scan the codebase directory to understand basic characteristics.

**Commands**:
```bash
# Directory structure
ls -la
find . -type f | head -50

# Count files by extension
find . -type f | sed 's/.*\.//' | sort | uniq -c | sort -rn | head -20

# Check for common markers
ls README.md CONTRIBUTING.md LICENSE package.json requirements.txt Dockerfile docker-compose.yml .git
```

**Extract**:
- **Project name**: From git remote, package.json/package name, README title, directory name
- **Primary languages**: File extensions (`.js`, `.py`, `.java`, `.go`, etc.)
- **Framework indicators**: package.json, requirements.txt, pom.xml, go.mod, Gemfile
- **Infrastructure**: Dockerfile, docker-compose.yml, kubernetes/, terraform/, .github/workflows/

**Output**: Initial reconnaissance summary
```markdown
## Initial Reconnaissance

**Project Name**: {extracted from git/package.json/directory}
**Primary Languages**: {JavaScript (45%), Python (30%), Shell (15%), YAML (10%)}
**Tech Stack Indicators**:
- Frontend: React 18.2.0, Next.js 13.4
- Backend: Node.js 18, Express 4.18
- Database: PostgreSQL (docker-compose.yml)
- Deployment: Docker, GitHub Actions CI/CD

**Repository**: {git remote URL if available}
**Last Commit**: {git log -1 --format="%ai %s"}
**Lines of Code**: {cloc summary if available}
```

### Step 2: Architecture Analysis

Analyze codebase structure to understand architecture patterns.

**Commands**:
```bash
# Directory structure (key paths)
tree -L 3 -d

# Component/module identification
ls src/ lib/ app/ pkg/ cmd/
ls -la src/*/

# API/Interface discovery
grep -r "app\." --include="*.js" | head -20
grep -r "router\." --include="*.py" | head -20
grep -r "@RestController\|@RequestMapping" --include="*.java" | head -20

# Database/data layer
ls models/ entities/ migrations/ schema/
grep -r "CREATE TABLE\|mongoose.model\|sqlalchemy" | head -20
```

**Infer**:
- **Architecture Style**: Monolith, Microservices, Serverless, MVC, Layered
  - Single repo with