reference-docs
Reference documentation patterns for API and symbol documentation. Use when writing reference docs, API docs, parameter tables, or technical specifications. Triggers on reference docs, API reference, function reference, parameters table, symbol documentation.
Install via CLI (Recommended)
clawhub install openclaw/skills/skills/anderskev/reference-docsReference Documentation Patterns
Reference documentation is information-oriented - helping experienced users find precise technical details quickly. This skill provides patterns for writing clear, scannable reference pages.
Dependency: Always use this skill in conjunction with docs-style for core writing principles.
Purpose and Audience
- Who: Experienced users seeking specific information
- Goal: Quick lookup of technical details
- Mode: Not for learning, for looking up
- Expectation: Brevity, consistency, completeness
Document Structure Template
Use this template when creating reference documentation:
---
title: "[Symbol/API Name]"
description: "One-line description of what it does"
---
# [Name]
Brief description (1-2 sentences). State what it is and its primary purpose.
## Parameters
| Name | Type | Required | Description |
|------|------|----------|-------------|
| `param1` | `string` | Yes | What this parameter controls |
| `param2` | `number` | No | Optional behavior modification. Default: `10` |
## Returns
| Type | Description |
|------|-------------|
| `ReturnType` | What the function returns and when |
## Example
```language
import { symbolName } from 'package';
// Complete, runnable example showing common use case
const result = symbolName({
param1: 'realistic-value',
param2: 42
});
console.log(result);
// Expected output: { ... }
Related
- RelatedSymbol - Brief description
- AnotherSymbol - Brief description
## Writing Principles
### Brevity Over Explanation
- State facts, not rationale
- Avoid "why" - save that for Explanation docs
- Cut unnecessary words
**Do:**
```markdown
Returns the user's display name.
Avoid:
This function is useful when you need to get the user's display name
because it handles all the edge cases for you automatically.
Scannable Tables, Not Prose
Do:
| Name | Type | Description |
|------|------|-------------|
| `userId` | `string` | Unique user identifier |
| `options` | `Options` | Configuration object |
Avoid:
The first parameter is `userId`, which should be a string containing
the unique user identifier. The second parameter is `options`, which
is an Options object containing the configuration.
Consistent Format Across Entries
All reference pages for similar items should follow identical structure:
- Same heading order
- Same table columns
- Same code example format
- Same related links section
Every Example Must Be Runnable
- Include all imports
- Show complete, working code
- Use realistic values (not "foo", "bar", "test123")
- Include expected output when helpful
Code Example Patterns
Show Common Use Case First
## Example
### Basic Usage
```typescript
const user = await getUser('user-123');
console.log(user.name);
With Options
Metadata
Not sure this is the right skill?
Describe what you want to build — we'll match you to the best skill from 16,000+ options.
Find the right skillPaste this into your clawhub.json to enable this plugin.
{
"plugins": {
"official-anderskev-reference-docs": {
"enabled": true,
"auto_update": true
}
}
}Related Skills
tutorial-docs
Tutorial patterns for documentation - learning-oriented guides that teach through guided doing
fetch-pr-feedback
Fetch review comments from a PR and evaluate with receive-feedback skill
swift-testing-code-review
Reviews Swift Testing code for proper use of
rust-testing-code-review
Reviews Rust test code for unit test patterns, integration test structure, async testing, mocking approaches, and property-based testing. Covers Rust 2024 edition changes including async fn in traits for mocks,
explanation-docs
Explanation documentation patterns for understanding-oriented content - conceptual guides that explain why things work the way they do