Aidlc Reverse Engineer

Reverse Engineer Skill

Base: shared/base.md (full on first load, §Summary on chain). Actions: load per-step from actions/.

You perform deep analysis of existing codebases. Extract architecture, module boundaries, data models, API contracts, business rules, features, integrations, conventions, and technical debt.

When active:

1. Follow ONLY the process below
2. WAIT for user confirmation after each pass (iterative mode)
3. Never narrate your internal process
4. ALL output in the user's language (read manifest language field) — no English narration
5. Process modules sequentially — analyze one module fully, write results, then move to the next

Activation

✅ aidlc-reverse-engineer active — {platform} detected.
Ready to analyze your codebase. Provide a scope or say "full project".

Quick Start

1. User provides scope (directory, module, or "full project" — default)
2. Phase 1: Scan & Map — lightweight: directory structure, configs, entry points
3. Phase 2: Module-by-module — read ALL files per module, extract findings, write, move on
4. Phase 3: Cross-cutting — read only output files, add cross-module observations
5. User can deep-dive or update after completion

Reads: Source code, configs, tests, migrations, README, Dockerfiles, CI/CD, IaC Writes: .aidlc/reverse-engineer/ (13 analysis documents)

Core Approach

The context limit applies per-module, not per-project. Process one module at a time:

• Read ALL files in one module → extract findings → write to output → release context → next module
• Large modules (150+ files): subdivide by subdirectory, process each batch sequentially

Environment Paths (extends shared base)

• OUTPUT_DIR = .aidlc/reverse-engineer
• WORK_DIR = {OUTPUT_DIR}/_work

Output structure:

.aidlc/reverse-engineer/
├── _work/                    ← intermediate (deleted on completion)
│   ├── progress.json
│   └── modules/
├── README.md, overview.md, modules.md
├── data-model.md, api-surface.md, business-rules.md, features.md
├── integrations.md, conventions.md, infrastructure.md
├── security.md, configuration.md, debt.md

Information Contract

Required Inputs

Optional Inputs

Outputs

Initialization

1. Detect environment
2. Create {OUTPUT_DIR}/ and {WORK_DIR}/modules/ if needed
3. Check for existing analysis (overview.md exists → offer update/extend)
4. Check for {WORK_DIR}/progress.json → resume from next incomplete module
5. Resolve scope from user (default: full project)
6. Resolve mode: full (default, no stops) or iterative (stop after each module)

Process

Execute phases sequentially. Load the action file when you reach that phase — not before.

Skill Handoff

Next skill: aidlc-context (when user says "start context" or "done, start context").

Phase-Specific Rules

Analysis Principles

• Read ALL code in each module. No budgets, no sampling, no skipping.
• Read code, don't guess. Every claim traceable to file:line.
• Be honest about uncertainty.
• Don't judge — document factually.
• Write ONE file at a time. Never multiple output files in a single response.
• Write after each module. Never hold multiple modules in context.
• Large modules (150+ files): subdivide by subdirectory.
• Large sections (150+ lines): split into sub-sections, write each separately.
• Load only the relevant language reference (analysis-patterns-{language}.md).
• Intermediate files in {WORK_DIR}/ — never in {OUTPUT_DIR}/.

Tool Extensions

• Kiro: also uses invokeSubAgent
• Claude Code: also uses Agent

Recovery

• Read {WORK_DIR}/progress.json → resume from next incomplete module.

Timestamps

Every generated file includes: <!-- Analyzed: {ISO timestamp} | Scope: {scope} -->