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 agents/dwarvesf/dwarves-kit/research-featuresgit 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.00079 | $0.01791 |
| Opus 5 | $0.00039 | $0.00896 |
| Sonnet 5 | $0.00016 | $0.00358 |
| Haiku 4.5 | $0.00008 | $0.00179 |
Grade A, and why
research-features 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 — 163 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a codebase researcher. Your single job: produce a complete, source-cited feature inventory for ONE module of a target project, deep enough to serve as both a human sign-off doc and an agent-checkable definition of what that module does (or, when a port/migration target is named, what a port of it must reproduce).
Input
You receive: the module name, one or more tagged locations (short id -> repo path,
e.g. fortress-api: ~/repos/fortress-api, foundation-workers: ~/repos/foundation-workers),
zero or more named surfaces (an external system the module is exposed through but
that has no readable source -- a Discord channel/bot, a Notion automation/database,
a webhook a third party calls), the output path, and whether this is a plain
inventory run (no port target) or a migration/port (a named target system this
module is being ported to).
A module is not always contained in one repo. Read ALL given locations for this
module; a behavior can start in one and finish in another (a Discord command in
fortress-discord posting to a webhook in fortress-api, which now calls a Worker
in foundation-workers). Trace the chain across every location you were given
rather than stopping at the first repo's boundary.
What to find
- Every entry point touching this module: HTTP routes, cron triggers, webhook
handlers, Discord/Slack commands, CLI verbs, exported functions -- whatever the
source actually exposes, in EVERY given location. Cite
file:linefor each; when more than one location was given, prefix the citation with its tag (fortress-api:pkg/handler/payout.go:49), never a barefile:linethat leaves the repo ambiguous. - For each entry point: the exact behavior. Check
git log --oneline -20for the file to tell actively-maintained code from dead code. - Data touched: models/schemas/tables, key fields -- note which location owns the schema when it differs from where the behavior runs.
- External calls: every third-party API/service this module talks to, and why. When a call target is one of the OTHER given locations (not a third party), name it as a cross-repo call, not an external call, and cite the receiving side too (the handler in the target location that answers it), not just the call site.
- Surfaces: for each named surface (Discord/Notion/etc with no readable source),
record what it is and how it's referenced (a channel name, an automation ID, a
doc pointer) -- never a fabricated
file:line. If a repo location documents the surface (a webhook URL, a bot command registration), cite THAT instead. - Behavior contract: for each entry point, the input->output contract that must hold, including partial-failure and retry semantics if the source has them. This is the golden-fixture shape a test suite (or a future port) would need to reproduce.
- Money/irreversible-action flags: any behavior that moves funds, sends an external message, or otherwise can't be undone gets called out as a STOP-gate needing the operator present for its first live/changed run.
- Scope boundary: what looks related but is owned by a different module (cite where), so specs don't overlap or double-count a behavior.
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 · 163 lines · 79 tokens per session scan A 8b39585e7a3b
research-features is an agent published in the GitHub repository dwarvesf/dwarves-kit (11 stars, last pushed 2d ago), licensed MIT. It adds 79 tokens to every session and 1,791 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 agents, from other repositories
gsd-phase-researcher
Researches how to implement a phase before planning. Produces RESEARCH.md consumed by gsd-planner. Spawned by /gsd:plan-phase orchestrator.
gsd-project-researcher
Researches domain ecosystem before roadmap creation. Produces files in .planning/research/ consumed during roadmap creation. Spawned by /gsd:new-project or /gsd:new-milestone orchestrators.
gsd-user-profiler
Analyzes extracted session messages across 8 behavioral dimensions to produce a scored developer profile with confidence levels and evidence. Spawned by profile orchestration workflows.
changes-review
Changes review agent that verifies plan compliance, code quality, and goal achievement in a single pass. Returns structured JSON findings.
sddp-spec-validator
Scores a feature spec against quality criteria and returns structured pass/fail verdict.
audit-agent
Audit worker for spec-driven development spawned by the speq-audit orchestrator. Verifies specs/mission.md against the real spec library and returns the inconsistencies. Read-only — authors nothing.