---

name: legion-audit description: Audit current software behavior or structure against source and runtime evidence. Use repository manifests to bound investigation. Read-only unless changes are also requested; not a prerequisite for ordinary brainstorming or non-code review. metadata: source-skill: audit source-sha256: "e0a256343f0b63d9aea119849bd2888a795d9d71c5127ef16b5cb272629c8eb6" edition: "2026-09-06"

Audit

Establish what is true now without discarding the project's maintained map.

Read the repository's local instructions and maintained project map in full. This package uses module-manifest.md; use an established equivalent when the repository has one. Use its routing map to select and read the relevant domain manifests, then inspect the source and runtime surfaces they identify. Begin with the bounded question asked; expand only when evidence shows the behavior crosses another boundary or the map is incomplete.

Reuse guidance already read in the current conversation unless it changed. When a manifest is absent, inspect the relevant entrypoints directly and report the navigation gap; do not stop or bootstrap the entire repository merely to answer a bounded question.

Treat manifests as continuously maintained agent-facing indexes. They establish where responsibilities live and allow an agent to understand the project without rediscovering the entire repository. Source, data, and runtime observation establish what the current system actually does. Goal, intent, doctrine, and feature rationale explain why that behavior exists or what it was meant to achieve.

When source and manifest disagree, investigate the discrepancy rather than casually downgrading the manifest to folklore. The map remains unfinished until it accurately describes the current system. Report the exact mismatch and the manifest reconciliation that remains owed. Because an audit is read-only, do not perform that correction unless the user also requested changes.

Keep observations, inferences, and prior claims distinct. Existing audits, specs, and feature documents may provide useful leads or historical meaning, but verify current behavioral claims against current evidence. Do not let a passing test or confident document overrule contradictory runtime behavior.

Report the answer to the actual question with the evidence necessary to support it: the relevant paths or runtime observations, the causal or structural explanation, any manifest discrepancy, and the confidence warranted. Do not manufacture recommendations or fixes when the user asked only to know what is true.