AgentSkillsCN

docs-writer

Sunrise的.docx/substrate文档编写者。遵循既定规范,撰写并更新文档:以行动为导向而非单纯描述,优先关注项目特有的细节与反模式,并以实际代码为依据进行验证。在为新功能添加文档或更新现有文档时使用此功能。

SKILL.md
--- frontmatter
name: docs-writer
version: 1.0.0
description: |
  Documentation writer for Sunrise's .context/ substrate. Creates and updates
  documentation following established patterns: actionable over descriptive,
  project-specific quirks, anti-patterns first, verified against actual code.
  Use when adding documentation for new features or updating existing docs.

triggers:
  - 'document this'
  - 'update documentation'
  - 'write docs for'
  - 'add to .context'
  - 'document the'

contexts:
  - '.context/substrate.md'
  - '.context/guidelines.md'
  - '.context/workflow.md'
  - 'CLAUDE.md'

parameters:
  doc_location: '.context/'
  format: 'markdown'
  style: 'ai-optimized'

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 TypeAction
New feature documentationCreate new file or add section to existing file
Update existing docsRead current docs, verify against code, update
New domainCreate new folder with overview.md
Fix driftCompare 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:

code
.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

FunctionPurposeLocation
functionName()Brief descriptionlib/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

VariablePurposeDefault
ENV_VARDescriptionvalue

Related Documentation

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

DomainPurposeKey Files
api/REST endpoints, headers, examplesendpoints.md, headers.md, examples.md
auth/Authentication, sessions, guardsoverview.md, integration.md
database/Prisma schema, models, migrationsschema.md, models.md
security/CSP, CORS, rate limiting, sanitizationoverview.md
errors/Error handling, loggingoverview.md, logging.md
email/Email templates, sendingoverview.md
testing/Test patterns, mockingpatterns.md
deployment/Platform guidesoverview.md, platforms/
environment/Environment variablesoverview.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:

code
User: "Document the new getClientIP utility"
Assistant: [Reads lib/security/ip.ts, adds to security docs, updates CLAUDE.md utility table]

Update outdated docs:

code
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:

code
User: "Create documentation for the new notifications feature"
Assistant: [Creates .context/notifications/overview.md, links from substrate.md]