---

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.