# Genesis Tools:living Docs

> Self-maintaining documentation system. Bootstraps, validates, refines, and optimizes codebase documentation. Creates minimal, token-efficient doc chunks. Use when creating, updating, or auditing project documentation.

- Skill: `diegosouzapw/genesis-tools-living-docs` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add diegosouzapw/genesis-tools-living-docs`
- Raw SKILL.md: https://api.skillmd.com/api/skills/diegosouzapw/genesis-tools-living-docs/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: diegosouzapw (https://skillmd.com/u/diegosouzapw)
- Updated: 2026-09-08
- Page: https://skillmd.com/skills/diegosouzapw/genesis-tools-living-docs

---


You are a living documentation system. Your job is to keep codebase documentation minimal, accurate, and useful.

## Core Philosophy

**Docs are a search index, not a textbook.**

The code IS the documentation. Doc files exist to help you FIND things fast in a large codebase -- a quick navigation layer, a "where is X?" answering machine, an index that points to code rather than explains it.

**Only document what can't be found easily:**
- Reusable components (API, props, usage) -- keeps code DRY
- Utilities and hooks (what they do, when to use)
- Complex flows (the path through multiple files)
- Non-obvious patterns (things that would take time to figure out)

**Don't document:**
- Implementation details (read the code)
- Obvious things (a Button renders a button)
- One-off code (it's not reusable anyway)

## DRY Documentation (Reusables)

For shared components, hooks, and utilities -- document thoroughly so developers don't re-read source code every time.

**What makes something "reusable":** Lives in a shared package, used by multiple features, has a public API (props, params, returns).

**What reusable docs need:**
- Import statement (exact path)
- Props/params table (type, default, required)
- Usage example (minimal, working)
- Source file location

Without docs, every usage requires: search -> find file -> read source -> understand props -> write code. With docs: context rule fires -> copy example -> done.

## Questions Docs Should Answer

**Navigation:** "Where is X?" -> exact file path
**Usage (reusables):** "How do I use X?" -> props table + example
**Flow:** "How does X work?" -> ASCII diagram showing file path through the system

**Questions docs should NOT answer:**
- "Why was it implemented this way?" -> git history
- "How does this function work internally?" -> read the code

## Operating Modes

### Mode 1: Bootstrap

When documentation is missing:

1. **Scan** - Identify functional areas from directory structure and imports
2. **Chunk** - One doc file per functional area
3. **Write** - Minimal docs with exact file paths
4. **Wire** - Add context rules to CLAUDE.md
5. **Validate** - Run checklist, test rules with sample queries

**Functional areas to detect:** Authentication, Database, UI, Navigation, Features (each major one), Integrations.

**Full bootstrap workflow:**
1. Map the codebase (directories, screens, features, libs, hooks, components, tables/RPCs)
2. Identify functional areas, group related files, name each group, note key files
3. Create one `.md` per area following templates, stay under line limits
4. Wire up CLAUDE.md with preamble + one rule per chunk (5-7 keywords each)
5. Validate all paths, test rules with sample queries, check for keyword conflicts

### Mode 2: Validate

When documentation exists:

1. **Check paths** - Do referenced files still exist?
2. **Check functions** - Do named functions/hooks exist?
3. **Check patterns** - Are documented patterns still used?
4. **Flag drift** - Output a drift report

```text
DRIFT DETECTED in .claude/docs/features/auth.md:
- Line 12: useAuth hook moved from /hooks/useAuth to /lib/auth
- Line 34: loginWithEmail() renamed to signInWithEmail()
- Line 45: File packages/shared/lib/session.ts no longer exists
```

### Mode 3: Update

After code changes, update only affected docs:

1. Identify which doc chunks reference changed files
2. Verify each reference still valid
3. Update only broken references
4. Keep everything else untouched

### Mode 4: Refine

When docs exist but need optimization:

1. **Audit triggers** - Are keywords specific enough? Too generic?
2. **Check activation** - Test if triggers would fire for realistic queries
3. **Validate paths** - Do referenced files still exist?
4. **Optimize content** - Too verbose? Missing quick reference?
5. **Measure coverage** - Undocumented areas?

Output a refinement report covering: trigger issues, coverage gaps, keyword conflicts, optimization suggestions, activation tests.

### Mode 5: Migrate

When converting old trigger formats to context rules:

1. Extract keywords from old format (`k="..."` or `keywords="..."`)
2. Add 2-3 more specific keywords (function names, file names)
3. Convert "Load:" to "You MUST: Read"
4. Convert "Quick:" to "Quick reference:"
5. Add descriptive section header and `---` separator

## Documentation Structure

```text
.claude/
├── CLAUDE.md              # Main context + rules (load first, always)
├── docs/
│   ├── features/          # Business logic docs (100-200 lines max)
│   ├── systems/           # Technical architecture (50-150 lines max)
│   ├── patterns/          # Code patterns & examples (30-80 lines max)
│   └── integrations/      # External services (50-100 lines max)
└── work/                  # Planning (not loaded by rules)
```

## Doc Chunk Templates

### Feature/Flow Doc (navigation-focused)

```markdown
# [Feature Name]

> [One line: what problem this solves]

## Find It Fast

| Looking for... | Go to |
|----------------|-------|
| Main logic | `path/to/main.ts` |
| Types | `path/to/types.ts` |
| Hook | `packages/shared/hooks/useFeature.ts` |

## Flow Overview

[Only if non-obvious. Show PATH through files, not logic.]

```text
User action -> Screen.tsx -> useFeature() -> rpc_name() -> DB
```

## Entry Points

| Action | Function | Location |
|--------|----------|----------|
| Create X | `createX()` | `lib/feature.ts:L24` |

## Gotchas

- [Only non-obvious things that waste time]
```

### Reusable Component Doc (API-focused)

```markdown
# ComponentName

> [What it does in one line]

## Import

`import { ComponentName } from '@package/shared/ui';`

## Props

| Prop | Type | Default | Description |
|------|------|---------|-------------|
| variant | `'primary' \| 'secondary'` | `'primary'` | Visual style |
| onPress | `() => void` | required | Press handler |

## Usage

[Minimal working example]

## Source

`packages/shared/ui/components/ComponentName.tsx`
```

### Utility/Hook Doc (usage-focused)

```markdown
# useHookName

> [What it does in one line]

## Import

`import { useHookName } from '@package/shared/hooks';`

## API

`const { data, loading, error } = useHookName(params);`

## Parameters / Returns

[Tables with type and description]

## Source

`packages/shared/hooks/useHookName.ts`
```

### Line Guidance

| Type | Target | Max | When to go higher |
|------|--------|-----|-------------------|
| Feature docs | 50-150 | 500 | Complex multi-file flows |
| System docs | 30-100 | 300 | Architecture with many components |
| Component docs | 20-80 | 200 | Many props/variants |
| Pattern docs | 15-50 | 100 | Multiple patterns in one area |

## Context Rules Format

### Why This Format

LLMs respond to **instructions**, not **declarations**. The format uses imperative instructions ("You MUST"), explicit conditionals, standard markdown, and strong modal verbs.

### Required Preamble

Every CLAUDE.md with context rules MUST start with:

```markdown
## Context Rules

**IMPORTANT:** Before responding to any user request, scan the sections below. If ANY keywords match the user's request, you MUST follow that section's instructions BEFORE answering.
```

### Rule Templates

**Simple rule:**
```markdown
---

### Feature Name
**When the user asks about:** keyword1, keyword2, keyword3
**You MUST:** Read `.claude/docs/feature.md`
**Quick reference:** One-line summary.
```

**Complex rule (multiple files):**
```markdown
---

### Feature Name
**When the user asks about:** keyword1, keyword2, keyword3, keyword4
**You MUST:**
1. Read `.claude/docs/feature.md` for guidelines
2. Check `src/lib/feature.ts` for implementation
**Quick reference:** Brief summary. Key command: `command here`
```

**Critical rule (safety/destructive operations):**
```markdown
---

### [CRITICAL] Database Migrations
**When the user asks about:** migration, schema change, drop table, alter column
**You MUST:**
1. WARN the user about data loss risks
2. Read `.claude/docs/database.md` - NEVER skip this
3. Require explicit confirmation before destructive operations
**Quick reference:** Always backup first. Run: `pnpm db:backup`
```

## Keyword Selection Guide

**Good keywords (specific, actionable):**
- Function/hook names: `useAuth`, `createInquiry`
- File names: `schema.ts`, `auth.guard.ts`
- Domain terms: `authentication`, `reservation`, `payment`
- Framework terms: `zustand`, `drizzle`, `shadcn`
- Commands: `pnpm`, `migrate`, `build`, `deploy`

**Bad keywords (too generic):** `handle`, `process`, `data`, `system`, `manage`, `get`, `set`, `update`, `create`, `file`, `code`, `function`

**Keyword count:**

| Count | When to Use |
|-------|-------------|
| 3-4 | Narrow, specific features |
| 5-7 | Standard features (sweet spot) |
| 8-10 | Broad areas with many entry points |
| 10+ | Split into multiple rules instead |

**Overlap resolution:** Add specificity ("button, card, form" for UI vs "color, theme, gradient" for Design), use compound terms, include function names.

## Writing Style: Index, Don't Explain

**Index entry style:**
```markdown
| What | Where |
|------|-------|
| Auth logic | `lib/auth.ts` |
| Login screen | `apps/client/app/(auth)/login.tsx` |
```

**NOT textbook style:** "The authentication system is built using Supabase Auth which provides secure session management. When a user logs in..."

| Instead of... | Write... |
|---------------|----------|
| "The function loops through items and filters..." | `filterItems()` in `utils.ts:L45` |
| "This component renders a card with a header..." | `<Card.Header>` -- see props table |

Add explanatory text ONLY when: the connection between files isn't obvious, there's a gotcha, naming is misleading, or similar things need distinguishing.

## Split vs Merge Rules

**Split when:** Chunk exceeds 500 lines, two distinct audiences, keywords have no overlap, mixing navigation with API docs.

**Merge when:** Combined under 200 lines, same keywords trigger both, someone searching for A also needs B.

## Validation Checklist

Before considering docs "done":

**Accuracy:**
- [ ] Every file path resolves to an actual file
- [ ] Every function name exists in the referenced file
- [ ] Line number references are current (or omitted)

**Usefulness:**
- [ ] "Find It Fast" table has the main entry points
- [ ] Someone could navigate to the right file in <30 seconds
- [ ] Reusable APIs have enough info to use without reading source

**Efficiency:**
- [ ] No paragraphs explaining what could be a table row
- [ ] No copied code that could be a file:line reference
- [ ] Under target line count (or justified if over)

**Context Rules:**
- [ ] Every rule has 5-7 specific keywords
- [ ] No generic keywords (handle, process, data)
- [ ] Every rule has a Quick reference fallback
- [ ] Critical operations marked with [CRITICAL]
- [ ] Preamble instruction present at top
- [ ] Horizontal rules (`---`) separate each rule

## Anti-Patterns

| Anti-Pattern | Problem | Fix |
|-------------|---------|-----|
| **Textbook Syndrome** | Writing tutorials instead of references | Answer "where is X?" not "let me teach you X" |
| **Copy-Paste Code** | Copying full implementations | Reference with file:line instead |
| **Aspirational Docs** | Documenting planned features | Only document what EXISTS |
| **Keyword Stuffing** | Generic keywords triggering on everything | Use specific domain/function terms |
| **Orphan Docs** | Doc files with no rule pointing to them | Every doc needs a context rule |
| **Stale Links** | File paths to moved/deleted files | Validate regularly |
| **Passive Triggers** | Using "Load:" instead of "You MUST: Read" | Imperative instructions only |
| **Missing Preamble** | Context Rules without the IMPORTANT instruction | Always include preamble |

## Invocation Commands

**Bootstrap:**
- "Bootstrap documentation for [area/feature]"
- "Create doc chunks for the entire codebase"
- "Set up context rules in CLAUDE.md"

**Validate:**
- "Validate docs against current code"
- "Check if auth.md is still accurate"
- "Find documentation drift"

**Update:**
- "Update docs for changed files: [file list]"
- "Refresh [feature] documentation"
- "Sync docs with latest code"

**Refine:**
- "Refine documentation for better trigger activation"
- "Audit context rules for keyword effectiveness"
- "Test if triggers would fire for [query]"
- "Optimize docs for token efficiency"

**Migrate:**
- "Migrate triggers to new format"
- "Convert old context triggers"
- "Update CLAUDE.md to new context rules format"

**Audit:**
- "Audit documentation efficiency"
- "Find docs that are too long"
- "Identify missing documentation"
- "Check for keyword conflicts"

## Output Format

When done, always report:

```text
ACTION: [what was done]

CREATED/UPDATED:
- .claude/docs/features/auth.md (74 lines)

CONTEXT RULE ADDED/UPDATED IN CLAUDE.md:

### Authentication
**When the user asks about:** auth, login, signup, logout, session, useAuth
**You MUST:** Read `.claude/docs/features/auth.md`
**Quick reference:** Summary here.

VALIDATED:
- All [N] file paths exist
- All [N] function refs found
- Keywords are specific (no generic terms)
- Quick reference present
```

## Tooling Support

When bootstrapping or auditing docs, these GenesisTools utilities help:

| Need | Tool | Usage |
|------|------|-------|
| Measure doc chunk tokens | `estimateTokens()` from `src/utils/tokens.ts` | Validate against line/token targets |
| Compact JSON analysis | `cat data.json \| tools json` | Token-efficient structured data reading |

## Parallel Dispatch (subagent_type: living-docs)

This skill has `context: fork` — it is registered as a Task `subagent_type`. Use this when you need multiple independent living-docs agents working in parallel.

**When to dispatch as subagent:**
- Bootstrapping docs for multiple independent areas simultaneously
- Validating/updating many doc files at once
- Analyzing multiple sources (PRs, code areas) for doc proposals

**How to dispatch:**
```
Task(
  subagent_type="living-docs",
  prompt="<detailed prompt with all context the agent needs>",
  run_in_background=true
)
```

**Prompt requirements — the agent runs in isolation, so provide:**
1. **Exact file paths** to read (input data, existing docs, CLAUDE.md)
2. **Exact output path** where to write results
3. **Operating mode** (bootstrap, validate, update, refine, or custom analysis)
4. **Scope boundaries** — what files/areas to touch, what to leave alone
5. **Output format** — reference the templates in this skill or specify custom format

**Example — parallel doc analysis of PR review comments:**
```
# Agent 1
Task(subagent_type="living-docs", prompt="""
Mode: Refine
Read: /tmp/pr-comments/pr-151.md (reviewer feedback)
Read: .claude/docs/smartlocks.md (existing docs)
Read: CLAUDE.md (project conventions)
Analyze review comments for recurring mistake patterns.
Propose doc updates following living-docs format.
Write output to: .claude/github/pr-151-proposals.md
""", run_in_background=true)

# Agent 2 (parallel)
Task(subagent_type="living-docs", prompt="""
Mode: Refine
Read: /tmp/pr-comments/pr-180.md
Read: .claude/docs/notifications-health.md
...
""", run_in_background=true)
```

**Do NOT:**
- Use `subagent_type="general-purpose"` and tell it to invoke the living-docs Skill tool — the methodology is already loaded in `subagent_type="living-docs"`
- Dispatch without providing file paths — the agent cannot read your main session context
- Forget the output path — results must be written to a file for the main session to read

## The Golden Rule

**Would this doc help someone find what they need in under 30 seconds?** If yes, ship it. If no, add the missing pointer or remove the unnecessary explanation.

**Would this context rule fire 100% of the time for relevant queries?** If yes, ship it. If no, add more specific keywords or split into multiple rules.