Getting it into your agent
This one installs as part of its plugin. Adding the marketplace and installing the plugin brings it with everything else the plugin ships.
/plugin marketplace add HAX-Studio/mnemonica/plugin install mnemonicaWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/hax-studio/mnemonica/brief-light)<a href="https://agentmods.dev/skills/hax-studio/mnemonica/brief-light"><img src="https://agentmods.dev/badge/skills/hax-studio/mnemonica/brief-light/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/hax-studio/mnemonica/brief-light"><img src="https://agentmods.dev/badge/skills/hax-studio/mnemonica/brief-light.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00069 | $0.00749 |
| Opus 5 | $0.00034 | $0.00375 |
| Sonnet 5 | $0.00014 | $0.00150 |
| Haiku 4.5 | $0.00007 | $0.00075 |
Grade A, and why
brief-light scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 9d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 58 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Mnemonica: brief-light
Give a real, substantive orientation to a project — not two sentences, but not the full depth
of brief-full either — by reading the CLAUDE.md index plus a bounded slice of each module
file, so the cost stays predictable regardless of how large any individual module has grown.
This skill never writes anything.
If the user's invocation includes extra wording (for example, "focus the brief on the
payments system"), treat it as narrowing which modules to cover — it cannot turn this into an
unbounded read of every module file in full; that is what brief-full is for.
Step 1: Check whether Mnemonica is installed
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; note which ones,
but continue — a brief can still be useful with partial coverage.
Step 2: Read the module index and README
Read the module index from .claude/CLAUDE.md. Read README.md at the project root if it
exists, for the project's own framing of what it is (name, purpose, how it runs) — this skill
only reads README.md, never writes it, same as every other Mnemonica skill.
Step 3: Read a bounded slice of each module
For each module file that exists on disk, read roughly its first 40 lines (or its first
major heading section, whichever is shorter) — not the whole file. This is what keeps
brief-light light: cost stays roughly constant per module regardless of how long any one
of them has grown. Do not read further just because a file looks interesting; that tradeoff
is what brief-full exists for.
Step 4: Check freshness
Check whether <project-root> is inside a git working tree.
- No git: if
knowledge/.mnemonica-state.jsonexists, read itslast_run_utcfor 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, docs may not reflect recent work" — say that plainly rather than guessing. On success, readCOMMITS_BEHINDand mention it if it is more than a handful of commits.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 9d ago First seen · 58 lines · 69 tokens per session scan A cbbe8d0773a6
brief-light is a skill published in the GitHub repository HAX-Studio/mnemonica (3 stars, last pushed 1mo ago), licensed MIT. It adds 69 tokens to every session and 749 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
create-request
Create, update, or scan per-task request tickets for progress tracking. These are date-prefixed non-lifecycle docs under requests/, NOT feature-level requirements (use /req-analyze for those). Use when: tracking task progress, updating completion status, scanning incomplete requests, checking request status dashboard.…
recap-doc
Post-development recap document generator. Use when: AI/Codex has implemented a feature and the user needs a guided walkthrough of what changed and why, with blind-spot detection and anticipated questions. Not for: Q&A follow-up (use /recap-ask), technical share-out for teammates (use /tech-brief), or generic code…
runbook
Generate and update feature release runbooks from existing docs and codebase. Use when: creating operational runbook, release handbook, deployment checklist, pre-release preparation. Not for: incident response (v2), code review (use codex-code-review), architecture design (use architecture).
jira
Jira integration — view issues, generate branches, create tickets, transition status. Use when: user mentions Jira ticket key (XX-123), says /jira, wants to create branch from ticket, create a new ticket, or update Jira status. Not for: GitHub issues (use issue-analyze).
repo-intake
Project initialization inventory (one-time). Use when: first onboarding a project, rebuilding cache after structural changes. Not for: day-to-day development (read cache directly), finding specific files (use code-explore). Output: project map with entrypoints + test map + next steps.
request-tracking
Request tracking knowledge base. Use when: querying request status, managing document references, tracking progress. Not for: creating requests (use create-request), tech specs (use tech-spec). Output: status report + progress tracking.