agentleFS
tmcfarlanetmcfarlane/team-avatar/skills/documentation-engineer/SKILL.md

documentation-engineer

Skill111 starsChanged 14 days agoMITView on GitHub

Technical documentation expert for creating clear, comprehensive documentation. Use when user asks to write docs, create README, or document code.

We split this skill into the rules it gives an agent

11 rules. 0 are common, 11 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 4 edited versions we read keep these.

  • 11

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Ask to write documentation

    line 20
  2. Distinctive:

    Every project should have a README with:

    line 28
  3. Distinctive:

    Be Clear: Use simple, direct language

    line 102
  4. Distinctive:

    Be Accurate: Keep docs in sync with code

    line 104
  5. Distinctive:

    Be Current: Update docs when code changes

    line 106
  6. Distinctive:

    Use sentence case for headings

    line 111
  7. Distinctive:

    Start with a verb or noun

    line 112
  8. Distinctive:

    Use relative links for internal docs

    line 122
  9. Distinctive:

    Test that links work

    line 124
  10. Distinctive:

    Use Mermaid for flowcharts and sequences

    line 127
  11. Distinctive:

    Add a title and legend

    line 129

“Common” is measured: kept by at least 6 in 10 of the 4 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Documentation Engineer

Expert in creating clear, comprehensive, and maintainable technical documentation.

When This Skill Activates

Activates when you:

  • Ask to write documentation
  • Request README creation
  • Mention "docs" or "document this"
  • Need API documentation

Documentation Types

1. README

Every project should have a README with:

# Project Name

Brief description (what it does, why it exists)

## Quick Start

Installation and usage in 3 steps or less.

## Installation

Detailed installation instructions.

## Usage

Examples of common usage patterns.

## Configuration

Environment variables and configuration options.

## Development

How to run tests, build, and develop locally.

## Contributing

Guidelines for contributors.

## License

License information.

2. API Documentation

For each endpoint/function:

  • Description: What it does
  • Parameters: Name, type, required/optional, description
  • Return value: Type and structure
  • Errors: Possible errors and conditions
  • Examples: Usage examples

3. Code Comments

Comment why, not what:

// Bad: Sets the count to zero
count = 0;

// Good: Reset count for new measurement cycle
count = 0;

// Bad: Check if user is admin
if (user.role === 'admin') {

// Good: Only admins can bypass approval workflow
if (user.role === 'admin') {

4. Architecture Documentation

  • System overview
  • Component relationships
  • Data flow
  • Design decisions
  • Trade-offs considered

Documentation Principles

  1. Be Clear: Use simple, direct language
  2. Be Concise: Respect the reader's time
  3. Be Accurate: Keep docs in sync with code
  4. Be Complete: Cover all public interfaces
  5. Be Current: Update docs when code changes

Writing Guidelines

Headings

  • Use sentence case for headings
  • Start with a verb or noun
  • Be descriptive

Code Examples

  • Show before/after when appropriate
  • Include import statements
  • Show expected output
  • Handle edge cases

Links

  • Use relative links for internal docs
  • Include anchors for sections
  • Test that links work

Diagrams

  • Use Mermaid for flowcharts and sequences
  • Keep diagrams simple
  • Add a title and legend

Documentation Checklist

README

  • Project description
  • Quick start guide
  • Installation instructions
  • Usage examples
  • Configuration guide
  • Contributing guidelines

Code Docs

  • All public functions documented
  • Parameters and returns documented
  • Examples provided for complex functions
  • Edge cases documented

API Docs

  • All endpoints documented
  • Request/response schemas
  • Authentication requirements
  • Error responses documented
  • Rate limits documented

Scripts

Generate documentation structure:

python scripts/generate_docs.py

Validate documentation:

python scripts/validate_docs.py

References

  • references/readme-template.md - README template
  • references/api-template.md - API documentation template
  • references/style-guide.md - Documentation style guide

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.