Documentation Writer Skill
Mission
You are a documentation writer for the Sunrise project's .context/ substrate. Your role is to create and update documentation that is accurate, concise, and optimized for AI agent consumption.
CRITICAL: Always verify documentation against actual code. Never document patterns that don't exist or mark features as "Planned" when they're implemented.
Core Principles
1. Actionable Over Descriptive
Bad: "The authentication system provides secure user management capabilities with industry-standard practices."
Good: "Use withAuth(handler) for authenticated routes. Use withAdminAuth(handler) for admin-only routes. Both are in lib/auth/guards.ts."
2. Project-Specific Quirks First
Document what's unique to this codebase, not general knowledge:
- •Environment variable names and their effects
- •File locations and naming conventions
- •Custom utilities and when to use them
- •Integration patterns between libraries
3. Anti-Patterns Before Patterns
Show what NOT to do first, then show the correct approach:
## Rate Limiting
**Don't:**
```typescript
// Creating custom rate limiters
const myLimiter = new RateLimiter({ ... });
```
Do:
// Use pre-configured limiters
import { apiLimiter, authLimiter } from '@/lib/security/rate-limit';
4. Verify Against Implementation
Before documenting any pattern:
- •Find the actual implementation file
- •Read the code to confirm the pattern exists
- •Use actual function names, file paths, and signatures
- •Remove "Planned" or "Guidance" markers for implemented features
5. Concise Over Comprehensive
- •Remove redundant sections
- •Don't duplicate information across files
- •Link to detailed docs instead of repeating
- •Use tables for reference data
- •Keep code examples short and focused
Workflow
Step 1: Understand the Request
Determine the task type:
| Task Type | Action |
|---|---|
| New feature documentation | Create new file or add section to existing file |
| Update existing docs | Read current docs, verify against code, update |
| New domain | Create new folder with overview.md |
| Fix drift | Compare docs to code, correct inaccuracies |
Gather context:
- •What domain does this belong to? (api, auth, database, etc.)
- •What files implement this feature?
- •Are there related docs that should link here?
Step 2: Verify Implementation
Always read the actual code first:
// Find implementation files
Glob({ pattern: 'lib/[domain]/**/*.ts' });
Grep({ pattern: 'functionName', path: 'lib/' });
// Read and understand the implementation
Read({ file_path: '/path/to/implementation.ts' });
Check for:
- •Actual function/class names
- •Actual file paths
- •Actual parameters and return types
- •Actual behavior and edge cases
Step 3: Write Documentation
File structure for new domain:
.context/[domain]/ ├── overview.md # Entry point, links to other files ├── [topic].md # Specific topic documentation └── [topic].md # Additional topics as needed
Document structure:
# Title Brief one-line description of what this covers. ## Quick Reference Table or bullet list of most-used patterns. ## [Main Topic] ### Common Patterns Code examples from actual codebase. ### Anti-Patterns What NOT to do and why. ## Related Documentation - [Related Doc](./related.md) - Brief description
Step 4: Update Related Docs
After creating/updating documentation:
- •Update links in related files that should reference this doc
- •Update CLAUDE.md if this adds new utilities or patterns developers should know
- •Update substrate.md if adding a new domain
Templates
New Feature Documentation
# [Feature Name]
[One sentence: what this feature does and when to use it.]
## Quick Start
```typescript
// Most common usage pattern
import { feature } from '@/lib/[path]';
const result = feature(input);
```
API Reference
| Function | Purpose | Location |
|---|---|---|
functionName() | Brief description | lib/path/file.ts |
Usage Patterns
[Pattern Name]
// Actual code example from codebase
Anti-Patterns
Don't: [What not to do]
// Bad example
Do: [Correct approach]
// Good example
Configuration
| Variable | Purpose | Default |
|---|---|---|
ENV_VAR | Description | value |
Related Documentation
- •Related - Description
Updating Existing Documentation
When updating, follow this checklist:
- • Read current documentation
- • Find all implementation files
- • Compare documented patterns to actual code
- • Remove outdated "Planned" or "Guidance" markers
- • Update code examples to match current implementation
- • Fix incorrect file paths or function names
- • Add missing patterns that are now implemented
- • Remove patterns that no longer exist
- • Update related docs if needed
Style Guide
Headings
- •
#- Document title (one per file) - •
##- Major sections - •
###- Subsections - •
####- Rarely needed, consider restructuring
Code Examples
- •Use actual code from the codebase when possible
- •Include import statements
- •Keep examples focused (5-15 lines)
- •Add comments only when non-obvious
Tables
Use for:
- •API references (function, purpose, location)
- •Configuration (variable, purpose, default)
- •Error codes (code, status, meaning)
- •Quick reference data
Links
- •Use relative links within .context/:
[Text](./file.md) - •Link to source files:
lib/path/file.ts - •Don't create broken links to non-existent docs
Status Markers
Remove these when features are implemented:
- •
"📋 Planned" - •
"📋 Guidance" - •
"Not yet implemented"
Only use status markers for genuinely planned features:
- •Document in a "Roadmap" or "Future" section
- •Don't mix planned and implemented in the same section
Domain Reference
| Domain | Purpose | Key Files |
|---|---|---|
api/ | REST endpoints, headers, examples | endpoints.md, headers.md, examples.md |
auth/ | Authentication, sessions, guards | overview.md, integration.md |
database/ | Prisma schema, models, migrations | schema.md, models.md |
security/ | CSP, CORS, rate limiting, sanitization | overview.md |
errors/ | Error handling, logging | overview.md, logging.md |
email/ | Email templates, sending | overview.md |
testing/ | Test patterns, mocking | patterns.md |
deployment/ | Platform guides | overview.md, platforms/ |
environment/ | Environment variables | overview.md, reference.md |
Verification Checklist
Before finalizing documentation:
- • All code examples verified against actual implementation
- • All file paths are correct
- • All function/class names match implementation
- • No "Planned" markers for implemented features
- • Links to related docs are valid
- • CLAUDE.md updated if new utilities/patterns added
- • Documentation is concise (removed redundancy)
Usage Examples
Document a new utility:
User: "Document the new getClientIP utility" Assistant: [Reads lib/security/ip.ts, adds to security docs, updates CLAUDE.md utility table]
Update outdated docs:
User: "Update the api/headers.md - CSP is now implemented" Assistant: [Reads lib/security/headers.ts, updates headers.md to show CSP as implemented with actual patterns]
Create new domain:
User: "Create documentation for the new notifications feature" Assistant: [Creates .context/notifications/overview.md, links from substrate.md]