What is technical-documentation?

A set of rules for writing and reviewing technical documentation and instruction files in a software repository. It covers product docs, contributor guides, and files that tell coding agents how to work.

Use it to create or overhaul documentation, review doc changes, audit repository docs, and align contributor or agent instructions.

It helps keep documentation clear, usable, consistent with the codebase, and maintainable as the project changes.

technical-documentation — Skill by vincentkoc/dotskills

Install

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.

Any agent

npx skills add vincentkoc/dotskills --skill technical-documentation

Clone the repo

git clone --depth 1 https://github.com/vincentkoc/dotskills

Made for: Claude Code, Codex.

Or install technical-documentation, the plugin that ships this one along with the rest of its 1 skill, 9 agents.

Wrote 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.

README.md

[![agentmods](https://agentmods.dev/badge/skills/vincentkoc/dotskills/technical-documentation/github.svg)](https://agentmods.dev/skills/vincentkoc/dotskills/technical-documentation)

Your own site

<a href="https://agentmods.dev/skills/vincentkoc/dotskills/technical-documentation"><img src="https://agentmods.dev/badge/skills/vincentkoc/dotskills/technical-documentation/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.

Your own site · 80×15

<a href="https://agentmods.dev/skills/vincentkoc/dotskills/technical-documentation"><img src="https://agentmods.dev/badge/skills/vincentkoc/dotskills/technical-documentation.svg" alt="Reviewed on agentmods" width="80" height="20"></a>

Per session 58 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.

When invoked 2,085 The whole file, excluding the scripts and references it only reads on demand.

Security scan A 0 findings. A grade says what 26 rules found in the file — not that it is safe.

Origin 94% copy Near-identical to another mod in the catalogue.

Token cost

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.00058	$0.02085
Opus 5.5	$0.00023	$0.00834
Sonnet 5.5	$0.00012	$0.00417
Haiku 4.5	$0.00006	$0.00209

Measured 1mo ago against content hash aa303f550049, method: parsed. Prices are Anthropic first-party input rates as of 2026-10-07, from the pricing page.

Security

Grade A, and why

technical-documentation 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 1mo ago.

The scan reads SKILL.md. This mod also ships 1 executable file (scripts/ste-lint.py), listed below but not scanned — reading those needs a real analyzer, not pattern matching.

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.

Origin

This is a copy

94% identical to technical-documentation — 126 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.

skills/technical-documentation/SKILL.md · 122 lines

How it starts

The opening of the file, as written. The whole thing — 122 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Technical Documentation

Purpose

Produce, review, and audit technical documentation that is clear, unambiguous, and maintainable for both humans and agents. Covers product docs, contributor-governance files, and agent instruction files. Prose follows Simplified Technical English so a reader or an agent cannot misread it. Audits scale to trees with hundreds of pages through sharding, adversarial checks, and parallel remediation.

When to use

Creating or overhauling docs in an existing product/codebase (brownfield).
Building evergreen docs meant to stay accurate and reusable over time.
Reviewing doc diffs for structure, clarity, and operational correctness.
Running full-repo documentation audits across governance files and product docs surfaces (docs/, README*, .md/.mdx/.mdc, Fern/Sphinx/Mintlify/MkDocs sources).
Auditing a large or messy docs tree: hundreds of pages, pages over 20k characters, confusing navigation, many locales, poor reader experience.
Rewriting dense or ambiguous English into Simplified Technical English: procedures, reference pages, error messages, tool descriptions, AGENTS.md and CONTRIBUTING.md.
Updating or reviewing AGENTS.md and/or CONTRIBUTING.md to keep agent and contributor workflows aligned with current repo practices.
Designing governance documentation strategy for repos with alias instruction files (CLAUDE.md, AGENT.md, .cursorrules, .cursor/rules/*, .agent/, .agents/, .pi/).
Diagnosing agent-file drift where teams had to prompt iteratively to surface missing files, broken commands, or policy conflicts.

Evidence and artifacts

Keep routine scoped review and audit findings in chat or stdout. Do not create report files, ledgers, or shard directories by default.
Create durable evidence only for a requested deliverable or a concrete large-audit, resumption, or handoff requirement. State its consumer and purpose before writing files.
Reuse one task-owned location for required evidence. Preserve coverage, deduplication, journal, and recovery contracts when a large or resumable workflow needs them.
Report coverage and gaps whether findings stay inline or in files. Less persistence never means less investigation.

Read the full file on GitHub · 122 lines

Files

What ships with it

23 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.

Changes

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.

1mo ago Changed · +25 lines aa303f550049
1mo ago Changed · +21 lines · +37 tokens per session 9fbef1286127
1mo ago First seen · 76 lines · 21 tokens per session scan A e9325cdfb92c

Subscribe to this mod's changes

technical-documentation is a skill published in the GitHub repository vincentkoc/dotskills (111 stars, last pushed yesterday), licensed MIT. It adds 58 tokens to every session and 2,085 once invoked, about $0.0002 per session on Opus 5.5. A static security scan graded it A with 0 findings. It is 94% identical to technical-documentation, differing in 126 lines, and is treated as a copy.

LLM Writing and docs agentic-workflows ai-assistant automation codex developer-tools

systematic-debugging

Use when encountering any bug, test failure, or unexpected behavior. 4-phase root cause investigation — NO fixes without understanding the problem first.

moltis-org/moltis · 33 tokens

ideation

Generate project ideas through creative constraints. Use when the user says 'I want to build something', 'give me a project idea', 'I'm bored', 'what should I make', 'inspire me', or any variant of 'I have tools but no direction'. Works for code, art, hardware, writing, tools, and anything that can be made.

moltis-org/moltis · 75 tokens

technical-documentation