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/ithinkihaveacat/dotfiles/technical-writingnpx skills add ithinkihaveacat/dotfiles --skill technical-writinggit clone --depth 1 https://github.com/ithinkihaveacat/dotfilesWrote 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/ithinkihaveacat/dotfiles/technical-writing)<a href="https://agentmods.dev/skills/ithinkihaveacat/dotfiles/technical-writing"><img src="https://agentmods.dev/badge/skills/ithinkihaveacat/dotfiles/technical-writing.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.00087 | $0.00782 |
| Opus 5 | $0.00044 | $0.00391 |
| Sonnet 5 | $0.00017 | $0.00156 |
| Haiku 4.5 | $0.00009 | $0.00078 |
Grade A, and why
technical-writing 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 5d 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 — 68 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Technical Writing Style Guidelines
This skill provides guidelines and formatting standards for authoring various types of technical and engineering documents.
Core Principles
When writing or editing technical content, adhere to the following tonal and structural principles:
- Plain English: Be direct, clear, and factual. Avoid corporate speak, overly formal detachment, and excessive jargon.
- Constructive & Collegial: Position yourself as an enthusiastic peer who wants the tool to succeed. Be supportive of the tool/library authors while remaining objective about the facts. Frame friction as opportunities for clarity, not as failures.
- Avoid Exaggeration: Do not use colloquial "cheerleading", subjective, or exclamatory language (e.g., avoid phrases like "massive quality-of-life improvement," "this tool shines," or "absolute powerhouse"). State the benefit factually instead (e.g., "This significantly simplifies parsing").
- Focus on the "Why" & Context: Assume the reader knows the codebase but not the specific problem you are solving. Provide enough background that the document makes sense in isolation. The code/log explains what changed and how; your writing must explain why.
- Defend Your Decisions: Proactively explain controversial choices, trade-offs, or omissions (e.g., why tests weren't added, why a specific library was chosen).
- Prohibition on Speculation: Maintain objectivity. Do not interpret intent or attach qualitative judgment to behavior. Describe observable symptoms and factual outcomes. Save technical reasoning, hypotheses, and root cause analysis for dedicated "Analysis" or "Rationale" sections (or, in TODO items, the "Sketch" field).
Document Types & Reference Material
Depending on the specific document you are authoring or reviewing, consult the relevant reference guide:
- Friction Logs — Documenting first-time user journeys, setup hurdles, and CLI walkthroughs.
- Bug Reports — Documenting defects, crashes, reproduction steps, and unexpected behaviors factually.
- Known Issues — Explaining "working as intended" constraints, upstream limitations, and workarounds for end users.
- Commit Messages — Authoring the technical "why", context, and permanent history behind changes.
- PR Descriptions — Summarizing intent, justifying trade-offs, and guiding reviewers through diffs.
- Comments — Writing direct, concise, and factual code review or issue comments.
- TODO Items — Capturing tasks with Goal, Criteria, and Sketch fields without hardening into premature plans.
- Getting Started Guides — Building action-oriented onboarding golden paths from zero to first result.
- Agent Skills — Authoring modular, decoupled, and
self-contained
SKILL.mdfiles and reference documents.
What ships with it
9 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.
- references/bug-reports.md 8.0 KB
- references/comments.md 2.4 KB
- references/commit-messages.md 4.5 KB
- references/friction-logs.md 3.5 KB
- references/getting-started-guides.md 8.8 KB
- references/known-issues.md 5.5 KB
- references/pr-descriptions.md 4.9 KB
- references/skills.md 6.8 KB
- references/todos.md 13 KB
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.
- 5d ago First seen · 68 lines · 87 tokens per session scan A 73baf582157f
technical-writing is a skill published in the GitHub repository ithinkihaveacat/dotfiles (48 stars, last pushed today), licensed Apache-2.0. It adds 87 tokens to every session and 782 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
aish-add-skills
Create new skills from documents, tutorials, or examples. Use when user wants to create a skill from learning materials or existing content.
diagnose_system_lag
Local Linux lag and performance diagnosis. Run read-only probes based on the user's symptoms to find CPU, memory, disk, or local network bottlenecks, then give safe advice. Never auto-remediate. Also matches Chinese requests such as 系统卡顿、机器好慢、内存不足、突然重启、OOM、磁盘很慢.
devops-platform-engineering
Platform engineering expert specializing in internal developer platforms, self-service infrastructure, Backstage service catalogs, GitOps with ArgoCD, and golden path templates. Use for building developer portals and platform-as-a-product.
dns-diagnose
Local DNS resolution troubleshooting with dig/resolvectl/whois. Investigate NXDOMAIN, wrong answers, records not taking effect, and resolver failures. Read-only; do not change DNS config. Also matches Chinese requests such as DNS 解析失败、域名解析不了、NXDOMAIN、解析不到.
devops-docker-patterns
Docker containerization expert specializing in multi-stage builds, image optimization, Docker Compose patterns, and production container security. Use for Dockerfile optimization, compose configurations, and container best practices.
network-path-diagnose
Diagnose network path quality from this host to a target using ping/mtr/curl. Investigate packet loss, high latency, jitter, and reachability failures; interpret hop results and suggest follow-up tests. Do not change network config. Also matches Chinese requests such as 网络丢包、延迟高、链路质量、ping 不通、网络抖动.