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]
Converted and distributed by TomeVault — claim your Tome and manage your conversions.