Nickcrew Claude Cortex Reference Documentation

Reference Documentation

Create exhaustive, searchable, and precisely organized technical reference documentation that serves as the definitive source of truth for APIs, configurations, and system interfaces.

When to Use This Skill

• Building API reference documentation (REST, GraphQL, gRPC)
• Creating configuration guides with every parameter documented
• Writing schema documentation for databases or data models
• Producing CLI reference with all commands, flags, and examples
• Generating complete technical specifications
• Documenting error codes, status codes, and exception catalogs
• Creating migration guides for version upgrades

Quick Reference

Workflow Overview

Phase 1: Inventory    → Catalog all public interfaces, parameters, and constraints
Phase 2: Author       → Draft structured entries with examples and cross-links
Phase 3: Verify       → Validate against implementation and tests
Phase 4: Organize     → Structure for optimal retrieval and searchability
Phase 5: Maintain     → Version tracking, deprecation, and update cadence

Phase 1: Inventory

Enumerate everything that needs documentation before writing anything.

Inventory Checklist

• All public API endpoints / methods / functions
• All configuration parameters and their defaults
• All error codes and exception types
• All environment variables
• All CLI commands and flags
• All schema fields and constraints
• All event types and payloads
• Deprecation timeline for removed features

Source of Truth Priority

1. Implementation code (actual behavior)
2. Tests (expected behavior with assertions)
3. Type definitions / schemas (declared contracts)
4. Existing documentation (may be stale — verify)

Phase 2: Author

Entry Format

Every documented item uses a consistent structure:

### methodName

**Type**: `(param1: string, param2?: number) => Promise<Result>`
**Since**: v2.1.0
**Deprecated**: No

**Description**:
Brief explanation of purpose and behavior.

**Parameters**:

| Name | Type | Required | Default | Description |
|------|------|----------|---------|-------------|
| `param1` | `string` | Yes | — | What this parameter controls |
| `param2` | `number` | No | `10` | What this parameter controls |

**Returns**: `Promise<Result>` — description of return value

**Throws**:
- `ValidationError` — when param1 is empty
- `TimeoutError` — when operation exceeds 30s

**Examples**:

Basic usage:
\`\`\`typescript
const result = await methodName("value");
\`\`\`

With options:
\`\`\`typescript
const result = await methodName("value", 20);
\`\`\`

**See Also**: [relatedMethod](#relatedmethod), [Configuration Guide](#configuration)

Writing Rules

1. Document behavior, not implementation — what it does, not how
2. Every parameter gets a row — no exceptions, even obvious ones
3. Every entry gets an example — at least one working code sample
4. State constraints explicitly — valid ranges, length limits, format requirements
5. Cross-reference related items — link to related methods, configs, and error codes

Phase 3: Verify

Verification Methods

Accuracy Checklist

• All signatures match current implementation
• All default values are correct
• All error conditions are documented
• All examples work against current version
• No removed features are still documented
• No new features are undocumented

Phase 4: Organize

Document Hierarchy

1. Overview          — What this API/system does, quick orientation
2. Quick Reference   — Cheat sheet of common operations with examples
3. Authentication    — How to authenticate (if applicable)
4. Detailed Reference — Complete documentation, grouped logically
5. Error Reference   — All error codes with causes and fixes
6. Glossary          — Terms specific to this system
7. Changelog         — What changed in each version

Navigation Aids

• Table of contents with deep linking at the top
• Alphabetical index for large reference sets
• Category grouping for logical discovery
• Search keywords embedded in headings and descriptions
• Version badges on entries added or changed in recent versions

Phase 5: Maintain

Versioning Strategy

• Tag every entry with the version it was introduced (**Since**: v2.1.0)
• Mark deprecations with migration guidance (**Deprecated**: v3.0 — use newMethod instead)
• Maintain a changelog section at the bottom of reference docs
• Separate docs by major version when breaking changes accumulate

Update Triggers

Reference documentation must be updated when:

• A public API signature changes
• A new parameter, endpoint, or command is added
• Default values or constraints change
• Features are deprecated or removed
• Error codes or behaviors change

Content Patterns

Parameter Tables

Always use tables for parameters — never inline lists:

Status Code Tables

Configuration Blocks

# config.yaml
server:
  port: 3000          # Port to listen on (1024-65535)
  host: "0.0.0.0"     # Bind address
  timeout: 30000      # Request timeout in ms
  max_body_size: "1mb" # Maximum request body size

Anti-Patterns

• Documenting internal/private interfaces that can change without notice
• Using "obvious" or "self-explanatory" instead of writing a real description
• Omitting error documentation because "it's clear from the types"
• Copy-pasting examples without verifying they still work
• Mixing tutorial-style narrative into reference entries (keep them separate)
• Letting documentation fall behind implementation for more than one release

Converted and distributed by TomeVault — claim your Tome and manage your conversions.