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.
npx agentmods add commands/dwarvesf/dwarves-kit/feature-mapgit clone --depth 1 https://github.com/dwarvesf/dwarves-kitWhat 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 | $0.00088 | $0.01982 |
| Opus 5 | $0.00044 | $0.00991 |
| Sonnet 5 | $0.00018 | $0.00396 |
| Haiku 4.5 | $0.00009 | $0.00198 |
Grade A, and why
feature-map 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 2d 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 — 148 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Formalizes a pattern already run by hand at least 4 times (dfoundation's
projects/cloudflare-migration/specs/{icy,invoice,leave,payout}.md, one shared
7-section template every time, plus ENDGAME-CHECKLIST.md as the rollup ledger).
Same dispatch idiom as /kit:spec's Step 2 research fan-out. Generic: point it at
ANY project. A named port/migration target is one use case, not a requirement.
Relationship to the audit-loop pattern
Step 6 (Refresh mode) below is an instance of docs/patterns/audit-loop.md:
| Slot | This instance |
|---|---|
| Item set | every module row in the checklist (Step 4's output), enumerated at Step 2 |
| Contract | the module's spec (docs/specs/<module>.md) still matches the live source across every given location |
| Evidence class | a fresh research-features re-read of the source, file:line cited, diffed against the existing spec |
| Apply mechanics | match = leave status untouched (OK); drift = NEEDS REVIEW on the checklist row (FIX proposed, never silent); the operator decides |
The FIRST run against a module isn't an audit (there's nothing to reconcile yet,
just a spec to construct) -- the audit-loop shape only applies from Step 6 onward.
Sibling instance: skills/topology-drift/SKILL.md (maintainer-only, audits THIS repo's
own command/agent/skill/hook registry against its path-index doc, not a target
project). Different item set and contract, same four-slot shape; an improvement to
one loop's evidence/apply mechanics is worth checking against the other.
Process
Step 1: Gather intent
If not already clear from the conversation, ask:
- Which project? A project can be ONE repo or SEVERAL -- list every repo/clone-read
location in scope, each with a short tag (
fortress-api: ~/repos/fortress-api,foundation-workers: ~/repos/foundation-workers). A single-repo project is just the N=1 case, nothing special to configure. - Any named surfaces with no readable source (a Discord server/channel, a Notion automation/database, a third-party webhook)? These get documented by reference (a doc, a URL, an automation ID), never a fabricated citation. Skip if none.
- Which modules/areas? (or: derive the module list from the given locations' routing/directory structure? A module may span more than one location, e.g. a Discord command in one repo triggering a handler in another -- see one module, multiple locations, not one module per repo.)
- Is there a named port/migration target (a system this is moving to), or is this a
plain inventory run (understand/document what the project does, no target)? This
decides whether
research-featureswrites a Parity contract (port) or a Behavior contract (inventory) -- seeagents/research-features.mdsection 5. - Output location for specs (default
docs/specs/) and for the top-level checklist (defaultdocs/CHECKLIST.md; a migration run may prefer a name likedocs/PORT-CHECKLIST.md, caller's call).
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.
- 2d ago First seen · 148 lines · 88 tokens per session scan A 03a42560ae4d
feature-map is a command published in the GitHub repository dwarvesf/dwarves-kit (11 stars, last pushed 2d ago), licensed MIT. It adds 88 tokens to every session and 1,982 once invoked, about $0.0004 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-30.
Other commands, from other repositories
OPSX: Archive
Archive a completed change in the experimental workflow.
OPSX: Explore
Enter explore mode - think through ideas, investigate problems, clarify requirements.
OPSX: Propose
Propose a new change - create it and generate all artifacts in one step.
OPSX: Sync
Sync delta specs from a change to main specs.
OPSX: Apply
Implement tasks from an OpenSpec change (Experimental).
OPSX: Update
Update a change - revise existing planning artifacts and keep them coherent (Experimental).