Documentation
READMEs, API references, code comments, changelogs and developer guides.
Download all 30
- Document a public API
Writes reference docs for a module's exported functions, classes or endpoints in the native doc-comment format, covering real behaviour, errors and edge cases. Use before a release.
- Write a changelog entry
Turns the commits and pull requests in a release range into a user-facing changelog entry in Keep a Changelog format, with breaking changes first. Use when cutting a release.
- Write a migration guide
Writes an upgrade guide for a breaking release that lists each breaking change with how to find affected code, before-and-after examples and a way to verify. Use when shipping a major version.
- Write a README
Writes or improves a project README from what the code actually does, with an install and quick start that work when copied. Use for a new project or a README that has drifted.
- Audit a documentation set
Audits documentation for accuracy against the code, gaps in the user journey, stale pages, duplication and findability, and returns a prioritised fix list. Use before a docs overhaul or release.
- Audit a README for conversion
Audits an open-source README or landing page as a funnel from first glance to first successful run, and returns ranked fixes with rewritten sections. Use before a launch.
- Code comment rules
Standing rules for the comments and docstrings an assistant writes - explain why not what, document public APIs fully, no commented-out code, owned TODOs, and keep comments true when code changes.
- Docs site overhaul track
Overhauls developer docs in gated steps, from inventory and reader journeys to a new structure with redirects, rewritten top pages, tested code samples and a process that keeps docs current.
- Document configuration options
Writes a configuration reference from code or a schema, with every option and env var, its type, default, allowed values, precedence, restart needs and old names, kept in sync by generation.
- Document error codes
Turns the error codes and messages in a codebase or API into an error catalog with cause, fix, retry safety and a stable URL per error that the message can link to. Use for APIs, SDKs and CLIs.
- Document a firmware hardware interface
Writes the hardware interface document for a board and its firmware, with pinout, buses and addresses, power and reset, timing limits, debug connectors and the board revision it applies to.
- Find and fix broken links in documentation
Checks a documentation folder or site source for broken internal links, anchors and images, fixes the internal ones, and lists external replacements for a person to confirm. Use before a docs release.
- Open-source maintainer
Acts as an experienced open-source maintainer who protects project scope, writes welcoming but firm replies, reviews contributions and keeps releases sustainable.
- Reorganise docs by Diátaxis
Sorts every page of a docs tree into tutorial, how-to, reference or explanation, finds pages that mix modes, and proposes a new navigation with splits, merges and redirects.
- Review developer docs for translation
Reviews docs-as-code source for translation blockers like text in images, built sentences, code mixed into prose and unstable anchors, and returns fixes, a do-not-translate list and page priorities.
- Update the docs a code change made stale
Finds the documentation a code change affects, such as READMEs, API docs, guides and examples, updates it to match, and runs the code snippets to prove they still work. Use before merging a change.
- Technical writer
Writes and edits developer documentation that is accurate to the code, task-oriented and easy to scan. Use as the voice for READMEs, API references, guides and changelogs.
- Test the code in docs
Makes the code samples in docs and READMEs run in CI with doctests, extracted snippets or compiled example files, plus fixtures for secrets and network, so broken samples fail the build.
- Write an API quickstart
Writes an API quickstart that gets a developer to a first successful call in minutes, with credentials, one request, the expected response and common errors. Use for a new or hard-to-adopt API.
- Write a CLI reference
Writes the help text, man page and web reference for a command-line tool from its argument parser, with synopsis, options grouped by task, exit codes, environment variables and real examples.
- Write code samples for an SDK or API
Writes runnable code samples for SDK or API operations across languages, with one shared structure, idiomatic error handling and expected output. Use when docs need multi-language samples.
- Write a step-by-step code tutorial
Writes a technical tutorial a reader can follow end to end, with pinned prerequisites, complete runnable snippets and a checkpoint after every step. Use for docs, blog tutorials or workshop material.
- Write a CONTRIBUTING guide
Writes a CONTRIBUTING.md from a repository's real setup, covering the dev environment, tests, branch and commit rules, PR checklist, review process and where newcomers can start.
- Write dataset documentation
Documents a maintained dataset that a data team publishes for other teams or partners, with grain, schema and units, freshness, known gaps, privacy, change policy and an example query.
- Write a docs style guide
Writes a short style guide for developer docs from existing pages, covering voice, terms, headings, code samples, admonitions, screenshots and versioning, plus lint rules to enforce it.
- Write a modding guide
Writes a modding guide for a game's players, covering file layout, data formats, the scripting API, a first working mod in 15 minutes, load order, compatibility and what is unsupported.
- Write a developer onboarding guide
Writes an onboarding guide for a repository covering setup, an architecture map, first tasks and known gotchas, with every command checked against the repo. Use for new hires or contributors.
- Write an ownership handover doc
Writes the handover for a system whose owner is leaving or changing team, with what it does, where it runs, deploy and rollback, known issues, jobs, where secrets live and a first-week checklist.
- Write release notes
Turns merged pull requests or commits into release notes for a chosen audience, grouped by impact and written as outcomes without internal jargon. Use when shipping a version.
- Write a troubleshooting guide
Writes a troubleshooting guide organised by symptom, with likely causes in order, diagnostic commands, fixes and when to escalate, from support tickets or issue threads.
Not: non-technical writing (writing-communication domain); ADRs (architecture).