---
name: legion-bootstrap
description: Build the maintained module and domain map when repository documentation is explicitly requested or part of an agreed setup. Not an automatic detour whenever a bounded task finds a missing manifest.
metadata:
  source-skill: bootstrap
  source-sha256: "174af332c7c6a09a683188628b6f19f61230094799353e0e19bcc32afc2df117"
  edition: "2026-09-06"
---

# Bootstrap

Build a maintained map of the codebase so subsequent work can start from its responsibilities and relevant files rather than rediscovering the whole project.

## What to build

1. **`module-manifest.md`** — the concise index at the owning repository root. Contains:
   - A one-paragraph description of what this repo is and does
   - A `Task → Domain Routing` table: given a type of task (e.g., "UI changes", "API routes", "session management"), which domain manifest to read
   - Global rules and invariants that apply across the whole codebase
   - A list of domain manifests with one-line descriptions

2. **Domain manifests** — one per major area of the codebase. Live in `manifests/`. Each one contains:
   - What this domain covers
   - Key files and their roles (with paths)
   - Important data flows or call chains
   - Invariants that must not be violated
   - Current implementation status of notable features

## Process

- Cover the owned first-party system systematically, beginning with entrypoints and existing guidance. Exclude dependencies, caches, generated output, and vendored trees unless they own a relevant contract. Write the map progressively so understanding survives the investigation; do not try to hold a large codebase in one context.
- Identify domain boundaries by looking for cohesive clusters of files that serve a shared purpose. Don't force artificial splits — if routing and middleware are tightly coupled, they're one domain.
- For each domain, trace the important paths: how does data enter, how does it flow, where does it land?
- Look for invariants the hard way — read the code, find the patterns, note what would break if someone changed it without knowing.
- Use the repository's established format when present. Choose domain manifests only where they make navigation useful; a small repository may need one coherent module map. Do not import a neighboring project's architecture as a template.
- If the repo already has partial structure (some manifests exist), read them first and extend rather than replace.

## After building

- Verify the completed routing, file roles, flows, and invariants against the source before declaring the map current.
- Note any genuinely unclear areas explicitly rather than inventing certainty about code that could not be understood with confidence.
- Treat the new manifests as the canonical current agent-facing map from this point forward. Every later code change must reconcile them before completion; a stale manifest means an engineering operation was left unfinished.