Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
git clone --depth 1 https://github.com/OPTIMETA/PAIDEIAWrote 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/commands/optimeta/paideia/hwmap)<a href="https://agentmods.dev/commands/optimeta/paideia/hwmap"><img src="https://agentmods.dev/badge/commands/optimeta/paideia/hwmap/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/commands/optimeta/paideia/hwmap"><img src="https://agentmods.dev/badge/commands/optimeta/paideia/hwmap.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.00026 | $0.00683 |
| Opus 5.5 | $0.00010 | $0.00273 |
| Sonnet 5.5 | $0.00005 | $0.00137 |
| Haiku 4.5 | $0.00003 | $0.00068 |
Grade A, and why
hwmap 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 1mo 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.
What it actually says
Output language
Read INTERFACE_LANG from .course-meta (default en). All user-facing prose must be in that language. Keep in English regardless: file paths, slash command names, pattern IDs (P1, P2…), tier markers (🔥🔥/🔥/🟡/⚪), and the literal section anchors downstream tools regex on.
Read course-index/coverage.md. If missing, tell the user to run /analyze first.
Query: $ARGUMENTS
Core premise. HW coverage is an exam-probability signal. Sections the professor drilled into HW are where the exam points live. "No HW coverage" is not a red flag — it's a low-risk zone the professor chose to omit.
Procedure:
If query is a § number or section name: Show which problems cover that section, and adjacent sections (§±1) for context. List the patterns involved. State the exam tier (🔥🔥 / 🔥 / 🟡 / ⚪) and the drill recommendation that follows.
If query is hot (or primary, exam, risk, blind for backwards compatibility):
Return 🔥🔥 Exam-primary and 🔥 Exam-likely sections, ranked by HW density (highest first). For each:
- List the HW problems that target it (these are your drill anchors)
- One-line drill recommendation:
- Many HW, pattern fluent →
/twin <hw-id>(build surface variance) - Many HW, strategy shaky →
/blind <hw-id>(strategy-check on the real HW) - User has solved HW but forgets the pattern →
/pattern <Pk>then/quiz §<n> 3
- Many HW, pattern fluent →
Do not recommend /derive here as a default — derivations are for reading gaps, not for drilling exam-likely zones. Use /derive only if the user explicitly asks for a clean reference.
If query is all or empty:
Render an exam-tier distribution table:
| Exam tier | Count | Sections |
|---|---|---|
| 🔥🔥 Exam-primary (3+ HW) | n | list |
| 🔥 Exam-likely (2 HW) | n | list |
| 🟡 Exam-possible (1 HW) | n | list |
| ⚪ Low-risk (no HW) | n | list |
Plus the "Recommended drill priority" section from coverage.md (ordered by HW density, not by absence).
Low-risk section handling. If the user insists on drilling a ⚪ section, warn once (in $INTERFACE_LANG): "Sections with no HW have low exam probability. If time is short, start from 🔥🔥." Then comply if they still want to.
Always close with (in $INTERFACE_LANG): "If you could pick just one 🔥🔥 item to drill right now, which one — and how many minutes do you have?"
Output goal: exam-point maximization. Steer time toward HW-dense zones.
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.
- 1mo ago First seen · 49 lines · 26 tokens per session scan A b693de5b02ee
hwmap is a command published in the GitHub repository OPTIMETA/PAIDEIA (91 stars, last pushed 3mo ago), licensed MIT. It adds 26 tokens to every session and 683 once invoked, about $0.0001 per session on Opus 5.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-30.
Other commands, from other repositories
design-tutorial
Interactive guided tour of Naksha — learn commands through real exercises, discover workflows, and get oriented in under 10 minutes.
naksha-help
Quick-reference for any Naksha command — browse by category or look up a specific command.
annex-a-deep-dive
Deep dive analysis of ISO 27001 Annex A control domains with implementation guidance.
code-explainer
Use when a designer needs to understand code that already works. What a file does, what a line means, which parts are safe to change. Plain language with Figma analogies, no developer jargon.
recap
Get a summary of everything you learned this session — concepts, quizzes, and progress.
review
Cold re-quiz on code that already shipped — your own session commits, not the change in front of you.