Tech writing
Skill peizh/tech-writing
Agent skill for clear, reader-first technical writing workflows
npx -y skills add peizh/tech-writingAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Draft, rewrite, review, and structure technical content so it is clear, concise, reader-first, accessible, evidence-backed, and action-oriented. Use when Codex needs to write or improve documentation, README files, design docs, API docs, tutorials, onboarding guides, release notes, specs, comments, CLI help, support content, or Chinese technical prose that needs evidence-first reasoning, less filler, and fewer buzzwords.
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
5.4 KB, as published. Nobody here has run it
Tech Writing
Overview
Apply practical technical writing principles with one goal: help the target reader understand something quickly and take the right action. Prefer simple wording, explicit structure, consistent terminology, accessible presentation, and concrete examples.
For Chinese technical prose that needs evidence-first reasoning, less filler, or buzzword cleanup, load references/chinese-technical-prose.md.
Workflow
- Identify the reader and outcome.
- Infer who the reader is, what they already know, and what they need to do after reading.
- State the purpose early. Narrow the scope if the request is broad.
- Choose the right document shape.
- Use task-oriented structure for how-to content.
- Use concept -> key points -> examples for explanatory content.
- Use reference structure for APIs, commands, flags, schemas, and limits.
- Use tables only when comparison is faster than prose.
- Draft for clarity.
- Prefer common words over jargon unless the technical term is required.
- Prefer active voice.
- Keep sentences short. Split stacked clauses.
- Use precise verbs and concrete nouns.
- Keep pronouns unambiguous. Repeat the noun if needed.
- Use one term for one concept throughout.
- For strong claims, show the evidence, observation, metric, trace, example, or constraint that supports the conclusion.
- Organize for scanning.
- Start sections and paragraphs with the main point.
- Use informative headings that describe a task or takeaway.
- Convert dense enumerations into lists.
- Keep list items parallel in structure.
- Put prerequisites, limits, and caveats before the reader hits them.
- Make examples earn their length.
- Use the smallest realistic example that proves the point.
- Explain why the example matters when it is not obvious.
- Avoid long sample code with irrelevant setup.
- Include anti-examples only when they clarify a likely mistake.
- Make the content accessible.
- Avoid color-only references such as "click the red button."
- Use meaningful link text.
- Write alt text for informative images.
- Use inclusive language.
- Avoid dense screenshots or diagrams that are not explained in text.
- Write helpful error messages when relevant.
- Explain what failed.
- Explain why, if known.
- Tell the user exactly how to fix it.
- Name the invalid value, required format, limit, or conflicting state.
- Keep the tone neutral and direct.
- Edit aggressively.
- Remove filler, throat-clearing, and repeated context.
- Check that each paragraph has one clear job.
- Verify terms, commands, filenames, flags, and examples.
- Cut any sentence that does not help the reader decide or act.
- In Chinese technical prose, delete narrator-style transition sentences that only announce the writing flow.
Default Output Pattern
For new documents, prefer this order:
- Title
- One-sentence summary
- Audience or prerequisites
- Main sections in reader task order
- Examples
- Edge cases or troubleshooting
- Links to deeper reference material
Rewrite Heuristics
- Replace "allows you to" with the verb.
- Replace abstract nouns with actions.
- Replace "simply", "just", "obviously", or "easy" with concrete instruction or remove them.
- Replace long lead-ins with the point.
- Replace passive constructions when the actor matters.
- Define acronyms on first use unless the audience clearly already knows them.
- Replace unsupported Chinese buzzwords or empty evaluative words with specific actors, actions, constraints, data, or effects.
Review Checklist
- Can the target reader understand the first paragraph without extra context?
- Does each heading help someone scan to the right section?
- Are terms consistent?
- Are commands, paths, and identifiers exact?
- Does each example earn its length?
- Are prerequisites and constraints explicit?
- Are strong claims backed by evidence or clearly marked as assumptions?
- For Chinese prose, are buzzwords, empty evaluations, and narrator-style transition sentences removed?
- If there is an error state, does the text explain recovery?
- Would this still work for a reader using assistive technology?
Response Modes
- Draft: produce the requested document directly.
- Rewrite: preserve meaning and improve clarity and structure.
- Review: identify ambiguity, missing context, structural problems, and weak examples before suggesting edits.
- Condense: keep substance and remove redundancy.
- Expand: add missing prerequisites, examples, caveats, or recovery steps without bloating.
Style Guardrails
- Prefer concise, production-friendly wording.
- Do not over-explain obvious engineering basics to expert readers.
- Do not add marketing tone unless the user asks.
- Do not invent facts, APIs, constraints, or examples.
- If information is missing, make the gap explicit or ask one focused question.
References
references/chinese-technical-prose.md: use for Chinese technical prose that needs evidence-first reasoning, narrator-style filler removal, and buzzword or empty-word cleanup.
Gives 0 of the 12 instructions most readme changelog skills give
Counted across 471 of the 478 authors here whose files we hold, read 2026-08-06
- follow the Keep a Changelog formatin 31 of 471, across 26 files
- omit empty sectionsin 21 of 471
- Run from the git repository rootin 20 of 471, across 7 files
- save output directly to CHANGELOG.mdin 20 of 471, across 7 files
- Group commits into logical categoriesin 19 of 471, across 6 files
- Review the generated changelog before publishingin 19 of 471, across 6 files
- Apply changelog guidelines and brand voicein 18 of 471, across 5 files
- Exclude internal commits like refactoring and testsin 18 of 471, across 5 files
- Specify date ranges for focused changelogsin 17 of 471, across 4 files
- Convert technical commits into customer languagein 17 of 471, across 4 files
- group commits by conventional commit typein 14 of 471
- insert new entry below unreleased sectionin 14 of 471
Said here and by no other author read
- Identify the target reader and desired outcome
- State the document purpose early
- Use task-oriented structure for how-to content
- Prefer common words over jargon
- Prefer active voice over passive voice
- Keep sentences short and split stacked clauses
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.