context-loaderlisted

# Purpose Build a minimal, sufficient `CONTEXT_PACK` so downstream skills decide with real project knowledge—not guesses. # When to Use / When NOT to Use **Use when:** starting any non-trivial engineering task; user mentions “load context”, “what’s the architecture”, or engineering-os begins a path. **Do not use when:** user already provided a Complete CONTEXT_PACK; or the task is a pure wording edit with zero code impact. # Preconditions - A concrete task or question exists. - Repo (or relevant paths) are accessible. # Inputs / Outputs **Inputs:** task statement, optional hints (paths, ticket). **Outputs:** `CONTEXT_PACK` # Upstream / Downstream **Upstream:** engineering-os, model-router (optional). **Downstream:** nearly all skills; especially spec-validator, adr-enforcer, delivery-planner, feature-implementer, defect-analyst. # Core Principles 1. Sufficiency over completeness. 2. Authoritative sources beat stale docs when they conflict—and conflicts must be reported. 3. Token budget is a hard constraint. 4. Prefer ADRs, interfaces, and entrypoints over trivia. 5. Never invent missing context. 6. Stop early when Blocked/Incomplete for risky work. 7. Emit a portable artifact others can consume. # Process ## Lite vs full | Task risk | Mode | |-----------|------| | Typo, comment, tiny chore | lite: target files + nearest README only | | Feature / bug / review | full discovery | ## Full discovery 1. **Source priority** (load in order, stop when sufficient):