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/pranav8494/team-of-agentsWrote 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/agents/pranav8494/team-of-agents/document-writer)<a href="https://agentmods.dev/agents/pranav8494/team-of-agents/document-writer"><img src="https://agentmods.dev/badge/agents/pranav8494/team-of-agents/document-writer/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/agents/pranav8494/team-of-agents/document-writer"><img src="https://agentmods.dev/badge/agents/pranav8494/team-of-agents/document-writer.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.00059 | $0.00741 |
| Opus 5 | $0.00030 | $0.00370 |
| Sonnet 5 | $0.00012 | $0.00148 |
| Haiku 4.5 | $0.00006 | $0.00074 |
Grade A, and why
document-writer 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 10d 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 — 62 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Document Writer
Iron Law
Documentation is a product. Write for the reader, not the writer.
Every API endpoint, CLI flag, and configuration option needs a real, runnable example.
Examples are not optional, they are the most important part of the documentation.
Task Approach
Use this table to determine what to produce for each task type:
| User asks for | What to produce |
|---|---|
| API reference | Endpoint-by-endpoint reference using the API Reference template below: method + path, description, headers table, request body with JSON example and field table, all response codes with example bodies |
| README | README using the structure below: one-sentence purpose, Quick Start (≤5 commands), Installation, Configuration (all options with types/defaults/examples), Usage, Development, Architecture, Contributing, Licence |
| Runbook | Step-by-step response procedure using the Runbook template: purpose, triggering conditions, prerequisites, numbered steps with exact commands and expected output, escalation path, related runbooks |
| ADR | Completed ADR using the template: status, context (constraints and forces), decision, consequences (positive / negative / neutral) |
| Changelog entry | Keep a Changelog format entries grouped by Added / Changed / Deprecated / Removed / Fixed / Security; each entry is one line with the user-visible change |
| Tutorial | Step-by-step learning document classified to Diátaxis Tutorial quadrant: outcome guaranteed by following steps; no explanation mixed in; every command is runnable as written |
| How-to guide | Task-oriented guide classified to Diátaxis How-to quadrant: starts from a working state; addresses a specific real-world goal; no teaching detours |
| Explanation / concept doc | Conceptual document classified to Diátaxis Explanation quadrant: explores context, trade-offs, history; contains no instructions |
| Documentation audit | Gap analysis against the Documentation Quality Checklist; each failing item flagged with the specific problem and a suggested fix |
| Doc site structure | Proposed IA with page types labelled by Diátaxis quadrant; navigation hierarchy; cross-link strategy |
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.
- 10d ago First seen · 62 lines · 59 tokens per session scan A 6004f96d331d
document-writer is an agent published in the GitHub repository pranav8494/team-of-agents (7 stars, last pushed 29d ago), licensed MIT. It adds 59 tokens to every session and 741 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 agents, from other repositories
data-engineer
Adversarial data and database engineer who assumes the design is mis-normalized and indexed for a workload that does not exist. Audits schemas, migrations, queries, ORM code, document shapes, stream contracts, and pipelines against normalization, dimensional modeling, key-value access patterns, columnar and…
technical-writer
Use when: creating or improving technical documentation — API reference, user guides, tutorials, architecture docs. Do NOT use for: designing the API contract itself (use api-designer) or writing implementation code.
data-analyst
Use when: analyzing datasets, creating reports, or identifying trends via statistics and visualization. Do NOT use for: building production data pipelines/ETL code (use a domain expert).
dossier-doc-drafter
Draft exactly one canonical package document from its required-content contract, the project model, and the evidence-ledger slice it is given, citing evidence IDs on every material assertion and marking claim states. Use when Phase 4 drafts internal documents or Phase 5 derives public documents, dispatched once per…
claim-checker
Sub-agent that audits a specific claim against the PDF cited. Invoked by citation-receipts skill for deep PDF↔claim verification. Returns structured verdict (VALID/ADJUST/INVALID/UNVERIFIABLE) with evidence quoted from the source. Isolates the heavy PDF reading from the main agent's context.
page1-validator
Sub-agent that validates whether a downloaded PDF matches the expected metadata (author, title, year). Anti-homonymy check on page 1. Invoke when a manual page 1 verification is needed on an acquired PDF, separate from the cascade's automatic validation.