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 skills/christiangalsterer/documentation-plugin/tech-writernpx skills add christiangalsterer/documentation-plugin --skill tech-writergit clone --depth 1 https://github.com/christiangalsterer/documentation-pluginWhat 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.00114 | $0.01196 |
| Opus 5 | $0.00057 | $0.00598 |
| Sonnet 5 | $0.00023 | $0.00239 |
| Haiku 4.5 | $0.00011 | $0.00120 |
Grade A, and why
tech-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 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 — 127 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Tech Writer
Write technical documentation in a professional tone with a fixed document structure and Microsoft Writing Style Guide markdown conventions. Output is always a single markdown document.
Workflow
- Identify the audience and goal. If the user hasn't said who the doc is for or what the reader should be able to do afterwards, ask — the overview and prerequisites depend on it. Do not ask about anything else; use the defaults below.
- Gather the facts. Read the code, config, or notes the doc covers. Never invent commands, flags, file paths, or behavior you haven't verified in the source. Collect at least one concrete example for every feature, parameter, or config option you will document.
- Draft using the fixed structure below. Skip a section only when it is genuinely empty (e.g. no prerequisites) — never invent content to fill one. Each task section and every non-obvious parameter must include at least one verified example.
- Apply the conventions. Read
references/markdown-conventions.mdbefore writing and again as a checklist after drafting. It defines headings, lists, code blocks, links, tables, and tone rules. - Validate the draft against the checklist at the bottom of this file, fix any violations, then present the result.
Fixed document structure
Every document follows this order:
# <Title: concise, sentence case, states the task or topic>
<Overview: 1–3 short paragraphs. What is this, who is it for, what will
the reader achieve. No heading — this text directly follows the title.>
## Prerequisites
<Bullet list of required tools, access, knowledge, or prior steps. Omit
the whole section if nothing is required.>
## <Task sections — one H2 per major step or topic>
<Numbered steps for procedures; prose for concepts. Each step: one action,
imperative mood, starts with a verb.>
1. First action.
1. Second action. (Use `1.` for every item — let the renderer number them.)
### <Optional H3 subsections within a task>
## Troubleshooting
<Problem → cause → solution, one H3 per issue or a table. Omit if nothing
is known to go wrong.>
## Next steps
<Bullet list of links to related docs or follow-up tasks.>
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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 · 127 lines · 114 tokens per session scan A 29e5c3b81c28
tech-writer is a skill published in the GitHub repository christiangalsterer/documentation-plugin (1 stars, last pushed 7d ago), licensed MIT. It adds 114 tokens to every session and 1,196 once invoked, about $0.0006 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 skills, from other repositories
wp-ux-design
WordPress UX and design enforcement — Core Web Vitals, mobile-first layout, typography, color systems, navigation, page builder patterns, image optimization, form UX, loading and error states, admin UX, and performance checklists with concrete CSS/HTML/PHP examples.
wp-php-architecture
WordPress PHP architecture patterns — repository, service layer, DDD, SOLID, plugin/theme structure, CPT design, and anti-patterns. The definitive reference for professional WordPress PHP development.
qector-core
Core domain knowledge and verified facts for the QECTOR quantum error correction platform (plugin v1.0.6, decoder wheel 1.0.0). Covers the app-free library MCP server (8 stable tools), the opt-in research server (29 provisional tools including the evidence layer), the privileged admin server (3 tools), 11 slash…
qector-math-foundations
The strict mathematical ground rules for every QECTOR claim. Encodes the F2 notation, the 16 correctness theorems, the Wilson 95% score interval for LER, the required-artifact- metadata contract, safe-wording rules, and the published limitations that must travel with every claim (reference manual v1.0.0, DOI…
qector-batch-decoding
Batch, streaming, and GPU-accelerated decoding paths for QECTOR. Covers the manual 13 CUDA / OpenCL bit-identity contract, the per-thread scratch sizing formula (manual 13.4), the warm-up / dispatch / hot-path pattern, the worker-thread determinism guarantee (manual 26.3), and the cold-path / hot-path reporting rule.…
qector-bp-osd
Belief propagation with ordered-statistics post-processing (BP-OSD) for QECTOR. Covers the box-plus kernel phi(x) = -ln(tanh(x/2)), the log-domain sum-product / min-sum / relay schedules, the OSD-0 / OSD-W solve (Theorem 11), the ambiguity-cluster partition (Theorem 12), and the worked examples from the v1.0.0…