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/bahayonghang/my-ai-cli-toolkit/document-writernpx skills add bahayonghang/my-ai-cli-toolkit --skill document-writergit clone --depth 1 https://github.com/bahayonghang/my-ai-cli-toolkitWrote 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/skills/bahayonghang/my-ai-cli-toolkit/document-writer)<a href="https://agentmods.dev/skills/bahayonghang/my-ai-cli-toolkit/document-writer"><img src="https://agentmods.dev/badge/skills/bahayonghang/my-ai-cli-toolkit/document-writer.svg" alt="Measured on agentmods" 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 | $0.00075 | $0.01127 |
| Opus 5 | $0.00037 | $0.00563 |
| Sonnet 5 | $0.00015 | $0.00225 |
| Haiku 4.5 | $0.00007 | $0.00113 |
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 4d 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 — 102 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Write or update technical documentation for the target project at $ARGUMENTS.
Preconditions
Paths starting with
<skill-dir>are relative to this skill's base directory, announced when the skill loads. Substitute that literal path; it is not an environment variable.
- If
$ARGUMENTSis empty, report:Error: Please provide the target path and the documentation task (for example: './docs/api.md update the payment API docs' or './src/utils.ts add JSDoc for the public helpers'). - Read
<skill-dir>/references/WORKFLOW.md,<skill-dir>/references/DOCUMENT_TYPES.md, and<skill-dir>/references/VERIFICATION_CHECKLIST.mdbefore drafting. - If the request is in Chinese, the output file is Chinese, or the user wants polishing/rewrite into Chinese, also read
<skill-dir>/references/CHINESE_TECH_WRITING.md.
Execution Flow
1. Classify the task
Determine the closest document type before writing:
README.mdor overview docs- API reference or endpoint documentation
- Architecture or design explanation
- User guide, operator guide, troubleshooting, FAQ
CONTRIBUTING, maintenance, migration, or release notes- JSDoc, docstrings, or code comments
Infer the type from the requested file, target path, and user request. Ask only if multiple document types would lead to materially different outputs.
2. Gather evidence from the codebase
Use the actual project files as the source of truth:
- Read existing documentation first so you preserve project vocabulary and avoid duplicating stale mistakes.
- Inspect the directory structure, entrypoints, configs, public interfaces, examples, and tests.
- Trace important flows from input to output when documenting behavior, not just file names.
- For API or architecture docs, verify routes, config keys, environment variables, and defaults against code.
- For JSDoc or comments, read the concrete symbol implementation before writing anything.
3. Decide language, audience, and output location
- Match the language requested by the user or already used by the surrounding docs.
- If the task is a rewrite into Chinese, follow the Chinese writing reference instead of translating line by line.
- Prefer updating the explicitly requested file in place.
- If no exact file is given, use the conventional location:
- repository root for
README.md,CONTRIBUTING.md,MIGRATION.md docs/for user, API, or architecture docs- source file for JSDoc or code comments
- repository root for
- If location is still ambiguous after exploring the repo, ask one focused question.
What ships with it
5 files 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.
- 4d ago First seen · 102 lines · 75 tokens per session scan A 8fc59d526b17
document-writer is a skill published in the GitHub repository bahayonghang/my-ai-cli-toolkit (16 stars, last pushed 2d ago), licensed MIT. It adds 75 tokens to every session and 1,127 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 skills, from other repositories
documentation-writer
Write clear technical documentation including READMEs, API docs, architecture guides, and inline documentation. Use when creating or improving project documentation.
documentation-patterns
Technical documentation patterns for READMEs, ADRs, API docs (OpenAPI 3.1), changelogs, and writing style guides. Use when creating project documentation, writing architecture decisions, documenting APIs, or maintaining changelogs.
documentation-standards
Use when writing README files, API documentation, user guides, or technical documentation following industry standards from Google, Microsoft, and GitLab style guides.
documentation-and-adrs
Writes technical documentation and Architecture Decision Records. Use when creating READMEs, API docs, ADRs, or any documentation that needs to explain a system, a decision, or how to use something.
doc-generator
Auto-generate documentation from code: README files, JSDoc comments, API docs. Scans project structure, detects frameworks, and produces ready-to-use documentation.
documentation
Technical writing, API docs, and documentation best practices.