agentsclimarketplace

Technical writer

Skill pinkpixel-dev/skills-collection-2/SKILLS/technical-writer

Write comprehensive technical documentation including user guides, how-to articles, system architecture docs, onboarding materials, and knowledge base articles. Creates clear, structured documentation for technical and non-technical audiences. Use when users need technical writing, documentation, tutorials, or knowledge base content.From its SKILL.md

Install
npx -y skills add pinkpixel-dev/skills-collection-2 --skill technical-writer

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 1 stars1 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.

SKILL.md

7.6 KB, ~1.7k tokens by cl100k_base, as published. Nobody here has run it

Technical Writer

Create clear, comprehensive technical documentation for any audience.

Instructions

When a user needs technical documentation:

  1. Identify Documentation Type:

    • User guide / end-user documentation
    • Developer documentation / API docs
    • System architecture documentation
    • Tutorial / how-to guide
    • Troubleshooting guide
    • README file
    • Release notes / changelog
    • Onboarding documentation
    • Knowledge base article
    • Standard Operating Procedure (SOP)
  2. Determine Audience:

    • Technical level (beginner, intermediate, expert)
    • Role (end user, developer, admin, stakeholder)
    • Prior knowledge assumptions
    • Context (internal team, external customers, open source community)
  3. Structure Documentation:

    User Guide Format:

    # [Product/Feature Name]
    
    ## Overview
    [What it is, what it does, why use it - 2-3 sentences]
    
    ## Prerequisites
    - [Required knowledge]
    - [Required tools/access]
    - [System requirements]
    
    ## Getting Started
    [Quick start guide with minimal steps to first success]
    
    ### Step 1: [Action]
    [Detailed instructions with screenshots/code]
    
    ### Step 2: [Action]
    [Detailed instructions]
    
    ## Key Concepts
    ### [Concept 1]
    [Explanation with examples]
    
    ## Common Tasks
    ### How to [Task]
    1. [Step]
    2. [Step]
    3. [Expected result]
    
    ## Advanced Features
    [Optional advanced functionality]
    
    ## Troubleshooting
    ### Problem: [Common issue]
    **Symptoms**: [What users see]
    **Solution**: [How to fix]
    
    ## FAQ
    **Q: [Question]**
    A: [Answer]
    
    ## Additional Resources
    - [Link to related docs]
    - [Support channels]
    

    Tutorial Format:

    # How to [Accomplish Goal]
    
    **Time required**: [X minutes]
    **Difficulty**: [Beginner/Intermediate/Advanced]
    
    ## What You'll Learn
    - [Learning objective 1]
    - [Learning objective 2]
    
    ## Prerequisites
    - [Required knowledge]
    - [Tools needed]
    
    ## Step-by-Step Instructions
    
    ### 1. [First Major Step]
    [Explanation of why this step matters]
    
    ```[language]
    [Code example]
    

    Expected output:

    [What users should see]
    

    2. [Next Major Step]

    [Continue pattern]

    Verification

    [How to confirm it worked]

    Next Steps

    [What to learn next]

    Troubleshooting

    [Common issues]

    
    **Architecture Documentation Format**:
    ```markdown
    # [System Name] Architecture
    
    ## Overview
    [High-level description, purpose, key characteristics]
    
    ## Architecture Diagram
    [ASCII diagram or description for diagram]
    
    ## Components
    ### [Component 1]
    **Purpose**: [What it does]
    **Technology**: [Stack/framework]
    **Responsibilities**:
    - [Responsibility 1]
    - [Responsibility 2]
    
    **Interfaces**:
    - Input: [Data/requests it receives]
    - Output: [Data/responses it produces]
    
    ## Data Flow
    1. [Step-by-step flow through system]
    
    ## Technology Stack
    - **Frontend**: [Technologies]
    - **Backend**: [Technologies]
    - **Database**: [Technologies]
    - **Infrastructure**: [Technologies]
    
    ## Design Decisions
    ### Why [Technology/Pattern]?
    [Rationale, alternatives considered, trade-offs]
    
    ## Scalability Considerations
    [How system scales, bottlenecks, mitigation strategies]
    
    ## Security
    [Authentication, authorization, data protection]
    
    ## Monitoring & Observability
    [Logging, metrics, alerting]
    
  4. Apply Technical Writing Best Practices:

    Clarity:

    • Use short sentences (aim for 15-20 words)
    • Avoid jargon or define it when first used
    • Use active voice ("Click the button" not "The button should be clicked")
    • Be specific ("Set timeout to 30 seconds" not "Set a reasonable timeout")

    Structure:

    • Use descriptive headings
    • Break content into scannable sections
    • Use numbered lists for sequences
    • Use bullet points for unordered items
    • Add table of contents for long docs

    Visuals:

    • Include screenshots with annotations
    • Add code examples with syntax highlighting
    • Use diagrams for complex concepts
    • Show expected outputs
    • Add tables for comparison or reference

    Code Examples:

    • Include language identifier
    • Show both good and bad examples
    • Add comments explaining complex parts
    • Use realistic, runnable examples
    • Include error handling

    User-Focused:

    • Start with most common use case
    • Include "why" not just "how"
    • Anticipate user questions
    • Address common pitfalls
    • Provide troubleshooting
  5. Format Complete Output:

    πŸ“š TECHNICAL DOCUMENTATION
    Type: [User Guide/Tutorial/Architecture/etc.]
    Audience: [Target audience]
    Level: [Beginner/Intermediate/Advanced]
    
    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
    [Full markdown documentation]
    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
    
    πŸ“‹ DOCUMENTATION CHECKLIST
    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
    
    βœ… Clear overview and purpose
    βœ… Prerequisites listed
    βœ… Step-by-step instructions
    βœ… Code examples included
    βœ… Expected outputs shown
    βœ… Troubleshooting section
    βœ… Links to related docs
    βœ… Scannable structure
    βœ… Appropriate for audience level
    
    πŸ’‘ MAINTENANCE NOTES
    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
    
    Review Triggers:
    β€’ [When to update this doc]
    β€’ [Dependencies that might change]
    
    Related Documentation:
    β€’ [Link to related docs]
    
  6. Special Documentation Types:

    README.md:

    • Project name and description
    • Installation instructions
    • Quick start example
    • Features list
    • Documentation links
    • Contributing guidelines
    • License

    Release Notes:

    • Version number and date
    • New features
    • Improvements
    • Bug fixes
    • Breaking changes
    • Migration guide
    • Deprecation notices

    Troubleshooting Guide:

    • Symptom-based organization
    • Root cause analysis
    • Step-by-step resolution
    • Prevention tips
    • When to escalate

Example Triggers

  • "Write user documentation for my feature"
  • "Create a tutorial for setting up the development environment"
  • "Document this system architecture"
  • "Write a troubleshooting guide"
  • "Create onboarding documentation for new developers"
  • "Write a README for this project"

Output Quality

Ensure documentation:

  • Has clear, descriptive title
  • Starts with overview/context
  • Lists prerequisites upfront
  • Uses consistent formatting
  • Includes code examples where appropriate
  • Shows expected outputs
  • Has troubleshooting section
  • Uses appropriate technical level for audience
  • Is structured logically (simple to complex)
  • Includes visual aids (diagrams, screenshots)
  • Has table of contents for long docs
  • Links to related documentation
  • Is easy to scan
  • Uses active voice
  • Avoids ambiguity
  • Includes examples from user perspective

Generate professional, comprehensive technical documentation that enables users to succeed.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 1 of the 12 instructions most technical docs skills give in ~1.7k tokens

Counted across 160 of the 186 authors here whose files we hold, read 2026-09-06

  • Review runbooks after every incidentin 6 of 160, across 4 files
  • Test runbooks regularlyin 6 of 160, across 4 files
  • Include rollback steps in every runbookin 6 of 160, across 4 files
  • Clarify goals, constraints, and required inputsin 6 of 160, across 4 files
  • Apply relevant best practices and validate outcomesin 6 of 160, across 4 files
  • Provide actionable steps and verificationin 6 of 160, across 4 files
  • Identify the audience before writingin 6 of 160
  • Write short sentences in active voicehere, and in 6 of 160
  • Open the implementation playbook for detailed examplesin 5 of 160, across 3 files
  • Escalate early during incidentsin 5 of 160, across 3 files
  • Keep stakeholders informedin 5 of 160, across 3 files
  • Document assumptions in runbooksin 5 of 160, across 3 files

Said here and by no other author read

  • Determine audience technical level and role
  • Structure content with the matching template
  • Include runnable code examples with language identifiers
  • Show expected outputs for each step
  • List prerequisites upfront
  • Include a troubleshooting section

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.