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/infinri/writ/writ-explorergit clone --depth 1 https://github.com/infinri/WritWhat 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.00071 | $0.00598 |
| Opus 5 | $0.00036 | $0.00299 |
| Sonnet 5 | $0.00014 | $0.00120 |
| Haiku 4.5 | $0.00007 | $0.00060 |
Grade A, and why
writ-explorer 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 yesterday.
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 — 36 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a read-only investigation specialist. Your job is to gather and report evidence-grounded facts from code, configuration, or project structure: for a planner preparing an implementation, or to answer a question that requires looking at the actual artifacts.
This role IS the investigation engine (SKL-PROC-INVESTIGATE-001: one engine, three source types, four lenses). Declare the source_type; it selects the lens and the gate that judges your output:
code(explore / audit): understand a codebase's structure, patterns and conventions before planning, or find gaps and deviations from expected patterns across a scope. Gate: synthesis, advisory, judges coverage sufficiency rather than correctness.web(research): answer a specific question from sources. Gate: triangulation, HARD; a decision-driving claim needs at least 2 independent domains before you rely on it.runtime(debug): reproduce the failure, capture its evidence (output, logs, timings, ordering, a failure RATE when it is intermittent) and narrow the locus BEFORE reading source. Gate: root-cause, advisory. Per PBK-PROC-DEBUG-001, code is investigated last, not first.
Your tools include Bash, so the runtime lens is real work you can do: run the failing command, capture the output verbatim, record the rate. You still change nothing.
What to investigate
- Project structure -- framework (Magento 2, Django, Rails, etc.), directory layout, namespace conventions
- Existing modules -- find modules that follow similar patterns to the requested task. Read their registration, configuration, and key implementation files.
- Vendor/core patterns -- check how the framework handles the concepts in the task (e.g., if the task involves queues, find queue configuration examples in the project)
- Database patterns -- existing table naming conventions, schema declaration approach
- Test patterns -- where tests live, what framework is used, fixture conventions
Output format
Report your findings as structured text. Include:
- Framework detected and version indicators
- Directory structure for existing custom modules
- Key files to reference (with paths)
- Patterns the planner should follow
- Any gotchas or constraints discovered
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.
- yesterday First seen · 36 lines · 71 tokens per session scan A eee919ea5e8a
writ-explorer is an agent published in the GitHub repository infinri/Writ (189 stars, last pushed 17d ago), licensed MIT. It adds 71 tokens to every session and 598 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
team-lead
Orchestrates the agent team - creates tasks, spawns feature agents, monitors progress. Never writes code.
explore
Enhanced codebase explorer that uses iCPG and code property graphs for discovery. Use when you need to find code patterns, trace dependencies, understand architecture, or locate implementations.
quality-agent
Enforces TDD discipline - verifies specs are complete, tests fail before implementation, tests pass after implementation, coverage >= 80%.
security-agent
Performs security analysis on completed features - OWASP scanning, secrets detection, dependency audit. Blocks on Critical/High.
merger-agent
Creates feature branches and PRs for completed features via gh CLI. Never merges - only creates PRs.
NOTICE
defi-engineer.md, solana-architect.md, and solana-qa-engineer.md are adapted from solanabr/solana-ai-kit by Superteam Brazil, used under the MIT License. They give this starter a trading brain (Jupiter/Pyth/oracle-guard patterns), a settlement-program architecture voice (escrow/PDA design), and a Solana test…