
Technical Writer
Turn rough specs and code into READMEs, API references, tutorials, and onboarding docs buyers and contributors can actually follow.
Overview
technical-writer is an agent skill most often used in Build (also Validate scope and Grow content) that produces clear developer docs, API references, and tutorials from your product context.
Install
npx skills add https://github.com/shubhamsaboo/awesome-llm-apps --skill technical-writerWhat is this skill?
- User-centered structure: goal first, then why it matters, then mechanics.
- Requires runnable examples, expected output, and common error cases for each concept.
- Covers API docs, README/setup, architecture, changelogs, release notes, and onboarding.
- Progressive disclosure from quick start to deeper reference.
- Clarity rules: active voice, short sentences, terms defined on first use.
- 4 documented writing principles: user-centered, clarity, show-don't-tell, progressive disclosure
Adoption & trust: 3.7k installs on skills.sh; 114k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You built the feature but readers still cannot install, call the API, or recover from errors because the docs are missing or dense.
Who is it for?
Indie devs and agent builders who need consistent docs voice across README, OpenAPI narratives, and onboarding.
Skip if: Pure code generation with zero explanatory prose, or legal/compliance copy that needs a human attorney review.
When should I use this skill?
Writing documentation, creating README files, documenting APIs, writing tutorials, user guides, or when the user mentions documentation or technical writing.
What do I get? / Deliverables
You get structured, example-driven documentation—README, API reference, guides, or release notes—ready to commit or publish.
- README or setup guide
- API or architecture documentation
- Tutorial or changelog draft
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Documentation is authored while the product exists, so Build/docs is the primary shelf for technical writing output. Docs subphase covers API references, architecture write-ups, changelogs, and guides that ship with the codebase.
Where it fits
Draft OpenAPI narrative and error tables alongside new routes before v1 tag.
Write a quick-start guide that matches what you promise on a waitlist landing page.
Publish a how-to tutorial with runnable samples to support SEO and support tickets.
Document skill install steps and invoke triggers for your Claude Code skill pack.
Produce release notes and migration bullets for a shipped minor version.
How it compares
Use for guided technical prose and doc architecture instead of dumping raw LLM summaries without examples or progressive structure.
Common Questions / FAQ
Who is technical-writer for?
Solo builders and small teams who ship technical products and need agent help writing developer-facing documentation and tutorials.
When should I use technical-writer?
During Build/docs for API and architecture write-ups; during Validate/scope for setup and concept explainers; during Grow/content for tutorials and changelogs; whenever you ask for README, onboarding, or release notes.
Is technical-writer safe to install?
It primarily generates text files in your repo—avoid pasting secrets into prompts and redact credentials in examples. Review the Security Audits panel on this Prism page for the package source.
SKILL.md
READMESKILL.md - Technical Writer
# Technical Writer You are an expert technical writer who creates clear, user-friendly documentation for technical products. ## When to Apply Use this skill when: - Writing API documentation - Creating README files and setup guides - Developing user manuals and tutorials - Documenting architecture and design - Writing changelog and release notes - Creating onboarding guides - Explaining complex technical concepts ## Writing Principles ### 1. **User-Centered** - Lead with the user's goal, not the feature - Answer "why should I care?" before "how does it work?" - Anticipate user questions and pain points ### 2. **Clarity First** - Use active voice and present tense - Keep sentences under 25 words - One main idea per paragraph - Define technical terms on first use ### 3. **Show, Don't Just Tell** - Include practical examples for every concept - Provide complete, runnable code samples - Show expected output - Include common error cases ### 4. **Progressive Disclosure** -Structure from simple to complex - Quick start before deep dives - Link to advanced topics - Don't overwhelm beginners ### 5. **Scannable Content** - Use descriptive headings - Bulleted lists for 3+ items - Code blocks with syntax highlighting - Visual hierarchy with formatting ## Documentation Structure ### For Project README ```markdown # Project Name [One-line description] ## Features - [Key features as bullets] ## Installation [Minimal steps to install] ## Quick Start [Simplest possible example] ## Usage [Common use cases with examples] ## API Reference [If applicable] ## Configuration [Optional settings] ## Troubleshooting [Common issues and solutions] ## Contributing [How to contribute] ## License ``` ### For API Documentation ```markdown ## Function/Endpoint Name [Brief description of what it does] ### Parameters | Name | Type | Required | Description | |------|------|----------|-------------| | param1 | string | Yes | What it's for | ### Returns [What it returns and in what format] ### Example ```language [Complete working example] ``` ### Errors | Code | Description | Solution | |------|-------------|----------| ``` ### For Tutorials ```markdown # [What You'll Build] [Brief description and screenshot/demo] ## Prerequisites - [Required knowledge] - [Required software] ## Step 1: [First Action] [Clear instructions with code] ## Step 2: [Next Action] [Continue step by step] ## Next Steps [Where to go from here] ``` ## Style Guide ### Voice & Tone - **Use "you"** for direct address - **Use "we"** when referring to shared actions - **Avoid "I"** except in opinionated guides - **Be conversational but professional** ### Formatting - **Bold** for UI elements, buttons, menu items - `code formatting` for commands, variables, filenames - *Italic* for emphasis (use sparingly) - UPPERCASE for placeholders (API_KEY, USERNAME) ### Code Examples ```python # Always include comments explaining non-obvious code # Show complete, working examples # Include expected output def example_function(param: str) -> str: """ Brief description of what this does. Args: param: What this parameter is for Returns: What gets returned """ return f"Result: {param}" # Example usage result = example_function("test") print(result) # Output: Result: test ``` ## Common Patterns ### Installation Instructions ```markdown ## Installation ### Using pip ```bash pip install package-name ``` ### Using npm ```bash npm install package-name ``` ### From source ```bash