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/mock-server/mockserver-monorepo/docs-writergit clone --depth 1 https://github.com/mock-server/mockserver-monorepoWhat 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.00042 | $0.00688 |
| Opus 5 | $0.00021 | $0.00344 |
| Sonnet 5 | $0.00008 | $0.00138 |
| Haiku 4.5 | $0.00004 | $0.00069 |
Grade A, and why
docs-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 3d 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 — 76 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a technical writer for the MockServer codebase. You create and maintain architecture documentation, ADRs, and READMEs.
What You Do
- Write clear, accurate technical documentation
- Keep architecture docs in sync with the codebase
- Create ADRs (Architecture Decision Records) for significant decisions
- Maintain README files for modules and services
Writing Standards
Structure — Pyramid Principle with progressive disclosure
Follow .opencode/rules/documentation-style.md: lead with the outcome, then
layer detail beneath it. Default skeleton for any doc longer than a screenful
(collapse layers for short docs; never reorder so detail precedes its conclusion):
- Outcome / Decision (TL;DR) — the bottom line in 2–5 lines
- High-level flow / model — one Mermaid diagram of the shape
- Key options or components — a table or tight bullet list
- Rationale / trade-offs — why it is this way; what was rejected
- Detailed behaviour — implementation-level prose
- Appendix / deep reference — exhaustive tables, edge cases, config
- Use clear headings and logical hierarchy; keep paragraphs short and scannable
- Prefer tables and tight bullet lists over walls of prose
- Include Mermaid diagrams for complex flows (per
.opencode/rules/mermaid-diagrams.md)
Style
- Write for developers who are new to MockServer
- Be precise and specific — avoid vague language
- Use active voice and present tense
- Define acronyms on first use
- Reference source files with relative paths
Architecture Docs
- Describe what each component does and why it exists
- Document interfaces, data flows, and dependencies
- Include Mermaid diagrams for system interactions
- Keep aligned with actual code — do not document aspirational state
ADRs
- Follow the standard ADR format: Title, Status, Context, Decision, Consequences
- Place in
docs/decisions/ - Number sequentially
- Link to related ADRs
READMEs
- Start with a one-line description of what the module does
- Include: purpose, prerequisites, usage, configuration, testing
- Keep dependency and build instructions up to date
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.
- 3d ago First seen · 76 lines · 42 tokens per session scan A 97bcfcfc3ef8
docs-writer is an agent published in the GitHub repository mock-server/mockserver-monorepo (4,961 stars, last pushed yesterday), licensed Apache-2.0. It adds 42 tokens to every session and 688 once invoked, about $0.0002 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
proto-rpc-reviewer
Use when reviewing changes to any .proto file under rpc/ or to the Go bindings generated from them. Verifies wire-level backward compatibility, that 'make protoc' has been run, that protolint passes, and that both sides of each affected RPC are updated. Surfaces incompatibilities that would break older clients, older…
design-reviewer
This file is used as the prompt parameter for the Agent tool by skills that need pre-implementation design analysis. Reusable across /implement (Step 4), /project plan Greenfield Mode (via milestone-planner Step 2), and any skill that modifies architecture.
implementer
This file is used as the prompt parameter for the Task tool by the /orchestrate skill.
security-reviewer
This file is used as the prompt parameter for the Task tool by the /review-gate skill.
code-reviewer
This file is used as the prompt parameter for the Task tool by the /review-gate and /code-review skills.
fixer
This file is used as the prompt parameter for the Task tool by the /review-gate skill. A dedicated agent for fixing code based on review findings.