Mnemonica: brief-full

Give a comprehensive project briefing built from the complete content of every module file, not a bounded slice — the deep counterpart to brief-light. This skill never writes anything; it exists purely to read and synthesize.

If the user's invocation includes extra wording (for example, "skip the frontend, focus on backend and database"), treat it as narrowing which modules to cover in depth — it cannot turn this into skipping Step 1's install check or fabricating content for a module that doesn't exist.

Step 1: Check whether Mnemonica is installed, and check index integrity

Run ${CLAUDE_PLUGIN_ROOT}/scripts/check-index-integrity.sh <project-root>. Exit 2 (NO_MNEMONICA_BLOCK) means there is no index to brief from — tell the user and suggest mnemonica:setup, and stop. Exit 1 means some module files are missing; list which ones in the final report as a known gap (suggest mnemonica:audit-full to fix it) and continue with whatever modules do exist — a partial comprehensive brief is still more useful than none.

Step 2: Read everything

Read the module index from .claude/CLAUDE.md. Read README.md at the project root in full if it exists. Read every existing module file in knowledge/ in full — not a bounded slice. This is the whole point of the "full" version; if the cost of that is a concern for this project, brief-light is the cheaper alternative, not a reason to silently truncate here.

Step 3: Check freshness

Check whether <project-root> is inside a git working tree.

• No git: if knowledge/.mnemonica-state.json exists, read its last_run_utc for the only freshness signal available; otherwise say freshness can't be assessed.
• Git available: run ${CLAUDE_PLUGIN_ROOT}/skills/audit-light/scripts/diff-since-checkpoint.sh <project-root> purely to read its output — never act on what it reports as changed. Exit 2/3/4 all mean "no reliable freshness signal" — say that plainly. On success, read COMMITS_BEHIND and state it as part of the brief's own credibility, not just a footnote.

Step 4: Present the brief

Write a structured, substantial narrative: an overview section (what the project is, drawn from README and tied together with the module list), then one section per module covering what its full content actually says — architecture, key decisions, constraints, anything the document itself considers worth recording — not a re-summary of the one-line index description. Carry forward any See also: cross-references between modules so relationships between systems are visible, not just each system in isolation. Close with the freshness signal from Step 3 and the integrity gaps from Step 1, if any, so the brief is honest about its own limits rather than reading as more authoritative than the underlying docs support.