home / skills / plurigrid / asi / code-documentation

code-documentation skill

This skill helps you generate clear, consistent code documentation including API references, README files, and inline comments, improving maintainability and

npx playbooks add skill plurigrid/asi --skill code-documentation

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
6.6 KB
---
name: code-documentation
description: Writing effective code documentation - API docs, README files, inline
version: 1.0.0
---


# Code Documentation

## README Structure

### Standard README Template
```markdown
# Project Name

Brief description of what this project does.

## Quick Start

\`\`\`bash
npm install
npm run dev
\`\`\`

## Installation

Detailed installation instructions...

## Usage

\`\`\`typescript
import { something } from 'project';

// Example usage
const result = something.doThing();
\`\`\`

## API Reference

### `functionName(param: Type): ReturnType`

Description of what the function does.

**Parameters:**
- `param` - Description of parameter

**Returns:** Description of return value

**Example:**
\`\`\`typescript
const result = functionName('value');
\`\`\`

## Configuration

| Option | Type | Default | Description |
|--------|------|---------|-------------|
| `option1` | `string` | `'default'` | What it does |

## Contributing

How to contribute...

## License

MIT
```

## API Documentation

### JSDoc/TSDoc Style
```typescript
/**
 * Creates a new user account.
 *
 * @param userData - The user data for account creation
 * @param options - Optional configuration
 * @returns The created user object
 * @throws {ValidationError} If email is invalid
 * @example
 * ```ts
 * const user = await createUser({
 *   email: '[email protected]',
 *   name: 'John'
 * });
 * ```
 */
async function createUser(
  userData: UserInput,
  options?: CreateOptions
): Promise<User> {
  // Implementation
}

/**
 * Configuration options for the API client.
 */
interface ClientConfig {
  /** The API base URL */
  baseUrl: string;
  /** Request timeout in milliseconds @default 5000 */
  timeout?: number;
  /** Custom headers to include in requests */
  headers?: Record<string, string>;
}
```

### OpenAPI/Swagger
```yaml
openapi: 3.0.0
info:
  title: My API
  version: 1.0.0

paths:
  /users:
    post:
      summary: Create a user
      description: Creates a new user account
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/UserInput'
      responses:
        '201':
          description: User created successfully
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/User'
        '400':
          description: Invalid input

components:
  schemas:
    UserInput:
      type: object
      required:
        - email
        - name
      properties:
        email:
          type: string
          format: email
        name:
          type: string
    User:
      type: object
      properties:
        id:
          type: string
        email:
          type: string
        name:
          type: string
        createdAt:
          type: string
          format: date-time
```

## Inline Comments

### When to Comment
```typescript
// GOOD: Explain WHY, not WHAT

// Use binary search because the list is always sorted and
// can contain millions of items - O(log n) vs O(n)
const index = binarySearch(items, target);

// GOOD: Explain complex business logic
// Users get 20% discount if they've been members for 2+ years
// AND have made 10+ purchases (per marketing team decision Q4 2024)
if (user.memberYears >= 2 && user.purchaseCount >= 10) {
  applyDiscount(0.2);
}

// GOOD: Document workarounds
// HACK: Safari doesn't support this API, fallback to polling
// TODO: Remove when Safari adds support (tracking: webkit.org/b/12345)
if (!window.IntersectionObserver) {
  startPolling();
}
```

### When NOT to Comment
```typescript
// BAD: Stating the obvious
// Increment counter by 1
counter++;

// BAD: Explaining clear code
// Check if user is admin
if (user.role === 'admin') { ... }

// BAD: Outdated comments (worse than no comment)
// Returns the user's full name  <-- Actually returns email now!
function getUserIdentifier(user) {
  return user.email;
}
```

## Architecture Documentation

### ADR (Architecture Decision Record)
```markdown
# ADR-001: Use PostgreSQL for Primary Database

## Status
Accepted

## Context
We need a database for storing user data and transactions.
Options considered: PostgreSQL, MySQL, MongoDB, DynamoDB.

## Decision
Use PostgreSQL with Supabase hosting.

## Rationale
- Strong ACID compliance needed for financial data
- Team has PostgreSQL experience
- Supabase provides auth and realtime features
- pgvector extension for future AI features

## Consequences
- Need to manage schema migrations
- May need read replicas for scale
- Team needs to learn Supabase-specific features
```

### Component Documentation
```markdown
## Authentication Module

### Overview
Handles user authentication using JWT tokens with refresh rotation.

### Flow
1. User submits credentials to `/auth/login`
2. Server validates and returns access + refresh tokens
3. Access token used for API requests (15min expiry)
4. Refresh token used to get new access token (7d expiry)

### Dependencies
- `jsonwebtoken` - Token generation/validation
- `bcrypt` - Password hashing
- `redis` - Refresh token storage

### Configuration
- `JWT_SECRET` - Secret for signing tokens
- `ACCESS_TOKEN_EXPIRY` - Access token lifetime
- `REFRESH_TOKEN_EXPIRY` - Refresh token lifetime
```

## Documentation Principles

1. **Write for your audience** - New devs vs API consumers
2. **Keep it close to code** - Docs in same repo, near relevant code
3. **Update with code** - Stale docs are worse than none
4. **Examples over explanations** - Show, don't just tell
5. **Progressive disclosure** - Quick start first, details later



## Scientific Skill Interleaving

This skill connects to the K-Dense-AI/claude-scientific-skills ecosystem:

### Graph Theory
- **networkx** [○] via bicomodule
  - Universal graph hub

### Bibliography References

- `dynamical-systems`: 41 citations in bib.duckdb



## SDF Interleaving

This skill connects to **Software Design for Flexibility** (Hanson & Sussman, 2021):

### Primary Chapter: 8. Degeneracy

**Concepts**: redundancy, fallback, multiple strategies, robustness

### GF(3) Balanced Triad

```
code-documentation (−) + SDF.Ch8 (−) + [balancer] (−) = 0
```

**Skill Trit**: -1 (MINUS - verification)


### Connection Pattern

Degeneracy provides fallbacks. This skill offers redundant strategies.
## Cat# Integration

This skill maps to **Cat# = Comod(P)** as a bicomodule in the equipment structure:

```
Trit: 0 (ERGODIC)
Home: Prof
Poly Op: ⊗
Kan Role: Adj
Color: #26D826
```

### GF(3) Naturality

The skill participates in triads satisfying:
```
(-1) + (0) + (+1) ≡ 0 (mod 3)
```

This ensures compositional coherence in the Cat# equipment structure.

Overview

This skill helps you write clear, maintainable code documentation: README files, API docs (JSDoc/OpenAPI), inline comments, and architecture records. It focuses on practical templates, examples, and principles that keep docs accurate and discoverable. The guidance is suited for Python projects and generalizes to multi-language codebases.

How this skill works

I provide templates, example snippets, and rules-of-thumb for each documentation artifact: standard README layout, JSDoc/TSDoc-style API comments, OpenAPI snippets for REST schemas, inline-comment heuristics, and ADR/component docs. I inspect common gaps—missing examples, outdated comments, unclear configuration tables—and recommend concrete edits to improve clarity and reduce maintenance cost. The output is actionable: copyable templates, sample text, and prioritized checklists to apply immediately.

When to use it

  • Creating or refreshing a project README to improve onboarding
  • Documenting public APIs or client libraries with examples and type annotations
  • Adding inline comments for complex algorithms, business rules, or workarounds
  • Capturing architecture decisions with ADRs for future reference
  • Producing OpenAPI/Swagger specs for REST endpoints

Best practices

  • Write for your audience: quick start for newcomers, details for maintainers
  • Keep docs close to code and update them in the same PR as code changes
  • Prefer examples and sample requests/responses over long prose
  • Comment why, not what — explain rationale, tradeoffs, and non-obvious constraints
  • Use machine-readable formats (OpenAPI, JSDoc) to enable tooling and clients

Example use cases

  • A concise README with Quick Start, Installation, Usage, API Reference, Configuration, Contributing, and License sections
  • JSDoc-style comments for public functions and interfaces including @param, @returns, @throws, and examples
  • An OpenAPI fragment describing /users POST with request/response schemas and 201/400 responses
  • Inline comments that explain complex business logic, algorithm choice, or browser-specific hacks with TODO/tracking links
  • An ADR documenting the choice of PostgreSQL, rationale, consequences, and migration considerations

FAQ

How often should I update documentation?

Update docs whenever code changes affect behavior, API shape, configuration, or setup; treat docs updates as part of the same PR that changes code.

When should I remove a comment?

Remove comments that state the obvious, duplicate clear code, or are outdated; prefer rewriting code for clarity when possible.

Which format should I use for API docs?

Use OpenAPI for REST endpoints to enable client generation; complement it with JSDoc/TSDoc or typed examples inside the codebase for developer discoverability.