# Human Centric Engineering Sunrise Docs Writer > Documentation Writer Skill - Skill: `tomevault-io/human-centric-engineering-sunrise-docs-writer` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tomevault-io/human-centric-engineering-sunrise-docs-writer` - Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/human-centric-engineering-sunrise-docs-writer/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Docs & Writing - Author: tomevault-io (https://skillmd.com/u/tomevault-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tomevault-io/human-centric-engineering-sunrise-docs-writer --- # 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: ````markdown ## Rate Limiting **Don't:** ```typescript // Creating custom rate limiters const myLimiter = new RateLimiter({ ... }); ``` ```` **Do:** ```typescript // Use pre-configured limiters import { apiLimiter, authLimiter } from '@/lib/security/rate-limit'; ``` ### 4. Verify Against Implementation Before documenting any pattern: 1. Find the actual implementation file 2. Read the code to confirm the pattern exists 3. Use actual function names, file paths, and signatures 4. 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:** ```typescript // 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:** ```markdown # 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: 1. **Update links** in related files that should reference this doc 2. **Update CLAUDE.md** if this adds new utilities or patterns developers should know 3. **Update substrate.md** if adding a new domain ## Templates ### New Feature Documentation ````markdown # [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] ```typescript // Actual code example from codebase ``` ### Anti-Patterns **Don't:** [What not to do] ```typescript // Bad example ``` **Do:** [Correct approach] ```typescript // Good example ``` ## Configuration | Variable | Purpose | Default | | --------- | ----------- | ------- | | `ENV_VAR` | Description | `value` | ## Related Documentation - [Related](./related.md) - 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](https://tomevault.io/claim/human-centric-engineering) — claim your Tome and manage your conversions.