/architect-init

name: architect-init
description: Use when bootstrapping architecture documentation for a brownfield project by reverse-engineering ADRs from an existing codebase.
disable-model-invocation: true

architect-init

What this skill does

Reverse-engineer architecture from an **existing codebase** (brownfield) to create Architecture Decision Records (ADRs) documenting discovered decisions, then **validate the findings** by running `/architect-clarify` manually.

You act as an **Architecture Archaeologist** uncovering implicit architectural decisions from code by scanning the codebase for technology choices and patterns, inferring architectural decisions from code structure, documenting discovered patterns as ADRs, and identifying gaps where decisions are unclear.

**Output**:

1. **ADRs** documenting inferred architectural decisions in `{REPO_ROOT}/.adlc/drafts/adr/ADR-{NNN}.md` (individual file format) 2. **Auto-generated index** at `{REPO_ROOT}/.adlc/drafts/adr/adr.md` 3. **Validate Findings**: Run `/architect-clarify` to validate discovered decisions

**Key Difference from `/architect-specify`**:

• `/architect-init` (this skill) = **Discovers** what's already implemented in code
• `/architect-specify` = **Explores** new possibilities for greenfield projects

This skill focuses on **current state analysis** - what IS, not what SHOULD BE.

When to use

• **Brownfield projects**: Existing code without architecture docs
• **Legacy modernization**: Understanding current state before changes
• **Team onboarding**: Quickly documenting implicit decisions
• **Technical debt assessment**: Identifying undocumented patterns

When NOT to use

• **Greenfield projects**: Use `/architect-specify` for new projects
• **Architecture exists**: If `AD.md` exists, use `/architect-clarify` to refine
• **Feature-level**: Feature architecture (if Spec Kit extension is also installed)

Process

User Input

$ARGUMENTS

You **MUST** consider the user input before proceeding (if not empty).

**Examples of User Input**:

• `"Django monolith with PostgreSQL, React frontend, AWS deployment"`
• `"Node.js microservices with MongoDB and RabbitMQ"`
• `"Legacy Java application, focus on understanding data layer"`
• Empty input: Scan entire codebase and infer architecture

When users provide context, use it to focus the reverse-engineering effort.

Flags

• `--adr-heuristic HEURISTIC`: ADR generation strategy
• `surprising` (default): Skip obvious ecosystem defaults, document only surprising/risky decisions
• `all`: Document all discovered decisions
• `minimal`: Only high-risk decisions

• `--no-decompose`: Disable automatic sub-system detection from code structure (default: auto-detect if multiple modules detected)

Role & Context

You are acting as an **Architecture Archaeologist** uncovering implicit architectural decisions from code. Your role involves:

• **Scanning** codebase for technology choices and patterns
• **Inferring** architectural decisions from code structure
• **Documenting** discovered patterns as ADRs
• **Identifying** gaps where decisions are unclear

Brownfield vs Greenfield

| Scenario | Command | Input | Output | |----------|---------|-------|--------| | **Brownfield** (existing code) | `/architect-init` | Codebase scan | Inferred ADRs | | **Greenfield** (new project) | `/architect-specify` | PRD/requirements | Discussed ADRs |

Rozanski & Woods Alignment

When discovering ADRs from brownfield code, map findings to R&W viewpoints:

| Discovery Area | Primary Viewpoint | What to Look For | |---------------|-------------------|------------------| | Service structure | **Functional** | Component boundaries, responsibilities | | Database schemas | Information | Data entities, relationships | | Process/thread code | Concurrency | Runtime units, coordination | | Directory structure | Development | Module organization, dependencies | | Deployment configs | Deployment | Infrastructure, environments | | Monitoring/alerting | Operational | Operations support |

**Functional-as-Cornerstone for Brownfield**: Even in brownfield discovery, the **Functional structure is foundational**:

1. **Discover Functional first**: Identify components, services, modules 2. **Map other discoveries**: Relate data, deployment, operations to functional elements 3. **Document dependencies**: Note which ADRs affect the Functional view

**Priority order for ADR discovery**: 1. Architecture Style ADRs (monolith/microservices) → **Functional cornerstone** 2. Component/Service ADRs → Functional view 3. Database/Data ADRs → Information view 4. Infrastructure ADRs → Deployment view 5. Communication/Async ADRs → Concurrency view 6. Development/CI ADRs → Development view 7. Operations ADRs → Operational view

Outline

1. **Sub-System Detection** (Phase 0): Identify sub-systems from code structure (auto-detect) 2. **Codebase Scan**: Analyze project structure and detect technologies (per sub-system if decomposed) 3. **Documentation Deduplication**: Scan existing docs (README, AGENTS.md, {TEAM_AI_DIRECTIVES}/AGENTS.md if configured, etc.) to avoid repeating 4. **Pattern Detection**: Identify architectural patterns in use 5. **ADR Generation**: Create ADRs for discovered decisions (marked "Discovered"), organized by sub-system 6. **Gap Analysis**: Identify areas where decisions are unclear 7. **Output**: Write ADRs to `{REPO_ROOT}/.adlc/drafts/adr/ADR-{NNN}.md` (NO AD.md creation)

• After writing all ADRs, the setup script auto-generates `adr.md` index

8. **Validate Findings**: Run `/architect-clarify` to validate brownfield findings

Execution Steps

Phase 0: Sub-System Detection (Brownfield)

**Objective**: Identify sub-systems from existing code structure automatically

**When**: This phase runs automatically when the codebase is detected as having multiple distinct modules/packages. Use `--no-decompose` to skip.

**Detection Source Reconciliation** (CRITICAL): The