technical-writing-clarity
Technical Writing for Clarity
Principles:
- Lead with the purpose: What is this document for and who is it for?
- One idea per paragraph. Long paragraphs hide key information.
- Use active voice:
Run the scriptnotThe script should be run. - Concrete over abstract: Show an example rather than describing it abstractly.
- Avoid jargon you have not defined unless the audience definitely knows it.
Structure for runbooks/how-tos:
- Overview (1–2 sentences)
- Prerequisites
- Steps (numbered, imperative)
- Verification / expected output
- Troubleshooting
Anti-patterns: Documenting what without why, outdated examples, walls of text without headers.
More from aiming-lab/metaclaw
structured-step-by-step-reasoning
Use this skill for any problem that involves multiple steps, tradeoffs, or non-trivial logic. Think out loud before answering to improve accuracy and transparency. Apply whenever the answer is not immediately obvious.
13avoid-hallucinating-specifics
Common mistake — stating specific facts (API endpoints, library versions, config options, function signatures) with false confidence when uncertain. Always flag uncertainty rather than guessing specifics.
12codebase-navigation
Use this skill when exploring an unfamiliar codebase, tracing code paths, or answering questions about how the system works. Read before writing, and build a mental model of the architecture before making changes.
12graceful-error-recovery
Use this skill when a tool call, command, or API request fails. Diagnose the root cause systematically before retrying or changing approach. Do not retry the same failing call without first understanding why it failed.
11uncertainty-acknowledgment
Use this skill when you are not sure about a fact, have outdated knowledge, or the question is contested. Explicitly communicate the level of confidence instead of asserting uncertain things as fact.
11secure-code-review
Use this skill when reviewing or writing code that handles user input, authentication, file I/O, network requests, or database queries. Always check for common security vulnerabilities before considering the code complete.
10