Documentation structure and templates for READMEs, API docs, guides, and CLI references. Use when creating docs, writing READMEs, or structuring a docs/ directory.
Provides structured templates and standards for creating comprehensive project documentation including READMEs, API references, and guides.
npx claudepluginhub outfitter-dev/outfitterThis skill inherits all available tools. When active, it can use any tool Claude has access to.
templates/COMMAND-REFERENCE.mdtemplates/DOCUMENT.mdtemplates/README.mdStructure and templates for project documentation — the human-facing docs that help developers understand and use your project.
This skill covers what to include and where it goes. For how to write it:
outfitter-styleguide skill for sentence rhythm, metaphors, structural movesoutfitter-voice skill for philosophical foundation (apply as review pass)For agent-specific documentation (CLAUDE.md, AGENTS.md), load the outfitter-agents-setup skill.
Documentation is prioritized in this order:
docs/ — Broader architectural and reference materialAll three levels matter. Types express intent through code, comments explain why, and docs provide context.
Standardized directory layout for documentation across repositories.
| File | Purpose |
|---|---|
README.md | Entry point for humans — quick start, links to docs |
CONTRIBUTING.md | Contribution guidelines (if applicable) |
CHANGELOG.md | Version history (auto-generated preferred) |
project/
└── docs/
├── architecture/ # System design, ADRs
├── api/ # API reference (if applicable)
├── cli/ # CLI command reference
├── guides/ # How-to guides, tutorials
└── development/ # Dev setup, workflows
| Directory | Content |
|---|---|
architecture/ | System design docs, Architecture Decision Records (ADRs), diagrams |
api/ | API reference, endpoint documentation, type definitions |
cli/ | Command reference, flags, usage examples, exit codes |
guides/ | How-to tutorials, walkthroughs, use-case guides |
development/ | Contributing setup, local dev, testing, release process |
Each type of documentation should have one canonical location:
docs/api/docs/cli/ or generated from help textdocs/architecture/ or ADRsAvoid duplicating content across locations. Link instead of copy.
READMEs are the entry point for new contributors. Keep them focused and scannable.
See templates/README.md for the full template.
docs/)| README | docs/ |
|---|---|
| Quick start (5-10 steps max) | Full tutorials |
| Feature list (bullet points) | Feature deep-dives |
| Installation options | Configuration reference |
| Links to detailed docs | The detailed docs themselves |
Choose based on project type:
When documenting packages or components with different maturity levels, use these labels:
| Label | Meaning | Guidance |
|---|---|---|
| Stable | APIs locked, breaking changes rare | Safe to depend on |
| Active | APIs evolving based on usage | Watch for updates |
| Early | APIs will change, not production-ready | Use with caution |
Avoid metaphorical labels (Cold/Warm/Hot, etc.) — literal labels require no interpretation.
Make it copy-paste runnable. Use heredoc format when showing file creation:
cat > example.ts << 'EOF'
import { ok, err } from '@org/contracts';
// ... code
EOF
bun run example.ts
Show output, including errors. Demonstrate both success and failure:
$ my-tool search --query "test"
Found: [ "result-1", "result-2" ]
$ my-tool search
Error [validation]: Query is required
Showing error output proves your error handling works.
End with a memorable closer. After the output block, add a confident one-liner:
**Output:**
```
Found: [ "result-1", "result-2" ]
```
Done. You're building type-safe infrastructure.
Use domain-relevant examples. Avoid generic "Hello, World!" — use examples that demonstrate actual value.
For projects with CLIs, document commands in docs/cli/.
See templates/COMMAND-REFERENCE.md for the full template.
Every technical document should follow the structure in templates/DOCUMENT.md.
interface UserConfig {
timeout: number;
retries: number;
}
function configureUser(options: UserConfig): void {
// Validate timeout is positive
if (options.timeout <= 0) {
throw new Error("Timeout must be positive");
}
applyConfig(options);
}
// Usage
configureUser({ timeout: 5000, retries: 3 });
// Incomplete, lacks context
function configure(opts) {
// ...
}
/**
* Processes user data according to specified rules.
*
* @param userData - The raw user data to process
* @param rules - Processing rules to apply
* @returns Processed user data with applied transformations
*
* @example
* ```typescript
* const processed = processUser(
* { name: 'John', age: 30 },
* { uppercase: true }
* );
* // Returns: { name: 'JOHN', age: 30 }
* ```
*
* @throws {ValidationError} When userData is invalid
* @throws {RuleError} When rules cannot be applied
*/
function processUser(userData: UserData, rules: ProcessRules): ProcessedUser;
Always document:
| Option | Type | Default | Description |
| --------- | --------- | ------- | ------------------------------- |
| `port` | `number` | `3000` | Server port |
| `timeout` | `number` | `30000` | Request timeout in milliseconds |
| `debug` | `boolean` | `false` | Enable debug logging |
Before finalizing documentation:
This skill should be used when the user asks about libraries, frameworks, API references, or needs code examples. Activates for setup questions, code generation involving libraries, or mentions of specific frameworks like React, Vue, Next.js, Prisma, Supabase, etc.