agentleFS
Sign inStart free
claude-worldclaude-world/director-mode-lite/skills/doc-writer/SKILL.md

doc-writer

Skill80 starsChanged 8 months agoMITView on GitHub

Documentation templates and standards: README structure, API reference format, changelog (Keep a Changelog), and comment guidelines. Use when creating or updating documentation. Loaded automatically by the doc-writer agent.

  • Installs packages

We split this skill into the rules it gives an agent

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

  • 0

    Common

    Most of the 17 edited versions we read keep these.

  • 5

    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:

    Follow Keep a Changelog format:

    line 82
  2. Distinctive:

    Use active voice; keep sentences concise

    line 104
  3. Distinctive:

    Write for scanning: H1 for the title, H2/H3 for sections, lists, and bold key terms

    line 106
  4. Distinctive:

    Keep it current: update docs in the same PR as the code change

    line 113
  5. Distinctive:

    Test your docs: follow your own instructions.

    line 115

“Common” is measured: kept by at least 6 in 10 of the 17 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

Doc Writer Skill

Director Mode Lite - Documentation Specialist

Documentation Types

1. README.md

Essential sections:

# Project Name

Brief description (1-2 sentences)

## Quick Start
\`\`\`bash
npm install   # Installation
npm start     # Run
\`\`\`

## Features
- Feature 1

## Documentation
- [Getting Started](docs/getting-started.md)
- [API Reference](docs/api.md)

## Contributing
See [CONTRIBUTING.md](CONTRIBUTING.md)

## License
MIT

2. API Documentation

For each endpoint/function:

## `functionName(param1, param2)`

Brief description.

**Parameters:**
- `param1` (string): Description
- `param2` (number, optional): Description. Default: `10`

**Returns:**
- `ResultType`: Description

**Example:**
\`\`\`javascript
const result = functionName('hello', 5);
// => { success: true }
\`\`\`

**Throws:**
- `ValidationError`: When param1 is empty

For REST endpoints, document the method and path, request headers/body, success and error responses, and a runnable curl example.

3. Code Comments

Comment complex algorithms, non-obvious business logic, workarounds (and why), and TODOs with context. Do NOT comment self-explanatory code or restate what the code already says.

// Calculate compound interest using continuous compounding formula
// This matches the bank's calculation method (see SPEC-123)
const interest = principal * Math.exp(rate * time);

4. CHANGELOG.md

Follow Keep a Changelog format:

# Changelog

## [1.2.0] - 2025-01-15
### Added
- New feature X
### Changed
- Improved performance of Y
### Fixed
- Bug in Z
### Removed
- Deprecated API endpoint

5. Architecture Docs

Cover the system overview, component relationships, data flow, and design decisions with their rationale.

Documentation Standards

Style

  • Use active voice; keep sentences concise
  • Define acronyms on first use; use consistent terminology
  • Write for scanning: H1 for the title, H2/H3 for sections, lists, and bold key terms

Code Examples

  • Make examples complete and runnable; include expected output
  • Show both basic and advanced usage; handle errors

Principles

  • Keep it current: update docs in the same PR as the code change
  • Write for the reader: assume minimal context, lead with the common case
  • Test your docs: follow your own instructions; verify every example runs

Output Format

## Documentation Update

### Files Created/Updated
- `README.md` - Added Quick Start section

### Summary
[What documentation was added/changed and why]

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.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

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.

Check your setup, free