ndomo 0.1.0

package/skills/bash-scripting/SKILL.md

@@ -0,0 +1,201 @@
+---
+name: bash-scripting
+description: "Bash scripting workflow for creating production-ready shell scripts with defensive patterns, error handling, and testing."
+category: granular-workflow-bundle
+risk: safe
+source: personal
+date_added: "2026-02-27"
+---
+
+# Bash Scripting Workflow
+
+## Overview
+
+Specialized workflow for creating robust, production-ready bash scripts with defensive programming patterns, comprehensive error handling, and automated testing.
+
+## When to Use This Workflow
+
+Use this workflow when:
+- Creating automation scripts
+- Writing system administration tools
+- Building deployment scripts
+- Developing backup solutions
+- Creating CI/CD scripts
+
+## Workflow Phases
+
+### Phase 1: Script Design
+
+#### Skills to Invoke
+- `bash-pro` - Professional scripting
+- `bash-defensive-patterns` - Defensive patterns
+
+#### Actions
+1. Define script purpose
+2. Identify inputs/outputs
+3. Plan error handling
+4. Design logging strategy
+5. Document requirements
+
+#### Copy-Paste Prompts
+```
+Use @bash-pro to design production-ready bash script
+```
+
+### Phase 2: Script Structure
+
+#### Skills to Invoke
+- `bash-pro` - Script structure
+- `bash-defensive-patterns` - Safety patterns
+
+#### Actions
+1. Add shebang and strict mode
+2. Create usage function
+3. Implement argument parsing
+4. Set up logging
+5. Add cleanup handlers
+
+#### Copy-Paste Prompts
+```
+Use @bash-defensive-patterns to implement strict mode and error handling
+```
+
+### Phase 3: Core Implementation
+
+#### Skills to Invoke
+- `bash-linux` - Linux commands
+- `linux-shell-scripting` - Shell scripting
+
+#### Actions
+1. Implement main functions
+2. Add input validation
+3. Create helper functions
+4. Handle edge cases
+5. Add progress indicators
+
+#### Copy-Paste Prompts
+```
+Use @bash-linux to implement system commands
+```
+
+### Phase 4: Error Handling
+
+#### Skills to Invoke
+- `bash-defensive-patterns` - Error handling
+- `error-handling-patterns` - Error patterns
+
+#### Actions
+1. Add trap handlers
+2. Implement retry logic
+3. Create error messages
+4. Set up exit codes
+5. Add rollback capability
+
+#### Copy-Paste Prompts
+```
+Use @bash-defensive-patterns to add comprehensive error handling
+```
+
+### Phase 5: Logging
+
+#### Skills to Invoke
+- `bash-pro` - Logging patterns
+
+#### Actions
+1. Create logging function
+2. Add log levels
+3. Implement timestamps
+4. Configure log rotation
+5. Add debug mode
+
+#### Copy-Paste Prompts
+```
+Use @bash-pro to implement structured logging
+```
+
+### Phase 6: Testing
+
+#### Skills to Invoke
+- `bats-testing-patterns` - Bats testing
+- `shellcheck-configuration` - ShellCheck
+
+#### Actions
+1. Write Bats tests
+2. Run ShellCheck
+3. Test edge cases
+4. Verify error handling
+5. Test with different inputs
+
+#### Copy-Paste Prompts
+```
+Use @bats-testing-patterns to write script tests
+```
+
+```
+Use @shellcheck-configuration to lint bash script
+```
+
+### Phase 7: Documentation
+
+#### Skills to Invoke
+- `documentation-templates` - Documentation
+
+#### Actions
+1. Add script header
+2. Document functions
+3. Create usage examples
+4. List dependencies
+5. Add troubleshooting section
+
+#### Copy-Paste Prompts
+```
+Use @documentation-templates to document bash script
+```
+
+## Script Template
+
+```bash
+#!/usr/bin/env bash
+set -euo pipefail
+
+readonly SCRIPT_NAME=$(basename "$0")
+readonly SCRIPT_DIR=$(cd "$(dirname "$0")" && pwd)
+
+log() { echo "[$(date '+%Y-%m-%d %H:%M:%S')] $*"; }
+error() { log "ERROR: $*" >&2; exit 1; }
+
+usage() { cat <<EOF
+Usage: $SCRIPT_NAME [OPTIONS]
+Options:
+    -h, --help      Show help
+    -v, --verbose   Verbose output
+EOF
+}
+
+main() {
+    log "Script started"
+    # Implementation
+    log "Script completed"
+}
+
+main "$@"
+```
+
+## Quality Gates
+
+- [ ] ShellCheck passes
+- [ ] Bats tests pass
+- [ ] Error handling works
+- [ ] Logging functional
+- [ ] Documentation complete
+
+## Related Workflow Bundles
+
+- `os-scripting` - OS scripting
+- `linux-troubleshooting` - Linux troubleshooting
+- `cloud-devops` - DevOps automation
+
+## Limitations
+- Use this skill only when the task clearly matches the scope described above.
+- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
+- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.

package/skills/bun/SKILL.md

@@ -0,0 +1,313 @@
+---
+name: Bun
+description: Use when building, running, testing, or bundling JavaScript/TypeScript applications. Reach for Bun when you need to execute scripts, manage dependencies, run tests, or bundle code for production. Bun is a drop-in replacement for Node.js with integrated package manager, test runner, and bundler.
+metadata:
+    mintlify-proj: bun
+    version: "1.0"
+---
+
+# Bun Skill Reference
+
+## Product Summary
+
+Bun is an all-in-one JavaScript/TypeScript toolkit that replaces Node.js, npm, Jest, and esbuild. It ships as a single binary and includes:
+
+- **Runtime**: Execute `.js`, `.ts`, `.jsx`, `.tsx` files with native transpilation (4x faster startup than Node.js)
+- **Package Manager**: `bun install` (25x faster than npm) with workspaces, lockfiles, and global cache
+- **Test Runner**: Jest-compatible `bun test` with snapshots, mocking, and watch mode
+- **Bundler**: `bun build` for browsers, servers, and standalone executables
+
+Key files and commands:
+- `bunfig.toml` — Configuration file (optional, zero-config by default)
+- `bun run <script>` — Execute package.json scripts or files
+- `bun install` — Install dependencies
+- `bun test` — Run tests
+- `bun build` — Bundle code
+- `package.json` — Standard Node.js manifest (Bun reads this)
+
+Primary docs: https://bun.com/docs
+
+---
+
+## When to Use
+
+**Use Bun when:**
+- Running TypeScript/JSX files directly without compilation overhead
+- Installing packages and managing dependencies (faster than npm/yarn/pnpm)
+- Writing and running tests (Jest-compatible API)
+- Bundling applications for production or deployment
+- Building full-stack applications with server and client code
+- Creating standalone executables from JavaScript/TypeScript
+- Working in monorepos with workspaces
+- Needing HTTP servers with `Bun.serve()`
+
+**Bun replaces:**
+- Node.js (runtime)
+- npm/yarn/pnpm (package manager)
+- Jest (test runner)
+- esbuild/webpack (bundler)
+
+---
+
+## Quick Reference
+
+### Runtime Commands
+
+| Command | Purpose |
+|---------|---------|
+| `bun run file.ts` | Execute a TypeScript/JavaScript file |
+| `bun run script-name` | Run a package.json script |
+| `bun --watch run file.ts` | Watch mode (re-run on file changes) |
+| `bun run -` | Read and execute code from stdin |
+| `bun --bun run script` | Force script to use Bun instead of Node.js |
+
+### Package Manager Commands
+
+| Command | Purpose |
+|---------|---------|
+| `bun install` | Install all dependencies from package.json |
+| `bun add <pkg>` | Add a package to dependencies |
+| `bun add -d <pkg>` | Add as dev dependency |
+| `bun add -g <pkg>` | Install globally |
+| `bun remove <pkg>` | Remove a package |
+| `bun update` | Update packages |
+| `bun install --frozen-lockfile` | CI mode: fail if lockfile out of sync |
+| `bun ci` | Equivalent to `bun install --frozen-lockfile` |
+
+### Test Runner Commands
+
+| Command | Purpose |
+|---------|---------|
+| `bun test` | Run all tests |
+| `bun test --watch` | Watch mode |
+| `bun test --test-name-pattern <pattern>` | Filter tests by name |
+| `bun test --concurrent` | Run tests in parallel |
+| `bun test --coverage` | Generate coverage report |
+| `bun test --update-snapshots` | Update snapshot files |
+
+### Bundler Commands
+
+| Command | Purpose |
+|---------|---------|
+| `bun build ./index.ts --outdir ./dist` | Bundle for browser (default) |
+| `bun build ./index.ts --target bun --outdir ./dist` | Bundle for Bun runtime |
+| `bun build ./index.ts --target node --outdir ./dist` | Bundle for Node.js |
+| `bun build ./index.ts --outfile ./cli --compile` | Create standalone executable |
+| `bun build ./index.ts --watch` | Watch mode |
+
+### Configuration File (bunfig.toml)
+
+```toml
+# Runtime settings
+preload = ["./setup.ts"]
+jsx = "react"
+logLevel = "debug"
+
+# Package manager
+[install]
+optional = true
+dev = true
+peer = true
+linker = "hoisted"  # or "isolated"
+
+# Test runner
+[test]
+root = "./__tests__"
+coverage = true
+coverageThreshold = 0.9
+
+# Server defaults
+[serve]
+port = 3000
+
+# Script execution
+[run]
+shell = "system"  # or "bun"
+bun = true        # alias node to bun
+```
+
+---
+
+## Decision Guidance
+
+### When to use `bun run` vs `bun`
+
+| Scenario | Use |
+|----------|-----|
+| Running a file: `bun run index.ts` | `bun run` (explicit) |
+| Running a package.json script | `bun run script-name` (required) |
+| Executing a file directly | `bun index.ts` (shorthand, same as `bun run`) |
+| Running a system command | `bun run ls` (via `bun run`) |
+
+### Installation strategy: hoisted vs isolated
+
+| Strategy | Use When |
+|----------|----------|
+| `hoisted` (default for single packages) | Traditional npm behavior; dependencies flattened in `node_modules` |
+| `isolated` (default for workspaces) | Strict dependency isolation; prevents phantom dependencies (pnpm-like) |
+
+Set in `bunfig.toml`: `[install] linker = "hoisted"` or `"isolated"`
+
+### Bundler target selection
+
+| Target | Use For |
+|--------|---------|
+| `browser` (default) | Client-side code; prioritizes `"browser"` export condition |
+| `bun` | Server-side code; optimized for Bun runtime; enables full-stack builds |
+| `node` | Node.js compatibility; outputs `.mjs` with Node export conditions |
+
+### Test execution: serial vs concurrent
+
+| Mode | Use When |
+|------|----------|
+| Sequential (default) | Tests have shared state or order dependencies |
+| `test.concurrent()` | Tests are independent and can run in parallel |
+| `test.serial()` | Force sequential even with `--concurrent` flag |
+
+---
+
+## Workflow
+
+### 1. Initialize a Project
+
+```bash
+bun init my-app
+cd my-app
+```
+
+Bun creates `package.json`, `tsconfig.json`, and a starter file. Choose template: Blank, React, or Library.
+
+### 2. Install Dependencies
+
+```bash
+bun install
+# or add a specific package
+bun add react
+bun add -d @types/react
+```
+
+Bun creates `bun.lock` (text-based lockfile) and `node_modules/`.
+
+### 3. Configure (Optional)
+
+Create `bunfig.toml` in project root for Bun-specific settings. Most projects work without it.
+
+```toml
+[install]
+linker = "isolated"
+
+[test]
+coverage = true
+```
+
+### 4. Run Code
+
+Execute TypeScript/JavaScript directly:
+
+```bash
+bun run src/index.ts
+# or via package.json script
+bun run dev
+```
+
+### 5. Write Tests
+
+Create `*.test.ts` or `*.spec.ts` files:
+
+```ts
+import { test, expect } from "bun:test";
+
+test("addition", () => {
+  expect(2 + 2).toBe(4);
+});
+```
+
+Run tests:
+
+```bash
+bun test
+bun test --watch
+bun test --coverage
+```
+
+### 6. Bundle for Production
+
+```bash
+# Browser bundle
+bun build ./src/index.tsx --outdir ./dist
+
+# Server bundle
+bun build ./src/server.ts --target bun --outdir ./dist
+
+# Standalone executable
+bun build ./cli.ts --outfile ./mycli --compile
+```
+
+### 7. Deploy
+
+Commit `bun.lock` to version control. In CI/CD:
+
+```bash
+bun ci  # Install with frozen lockfile
+bun run build
+bun test
+```
+
+---
+
+## Common Gotchas
+
+**Lockfile format**: Bun v1.2+ uses text-based `bun.lock` by default. Old projects may have binary `bun.lockb`. Migrate with: `bun install --save-text-lockfile --frozen-lockfile --lockfile-only`
+
+**Lifecycle scripts**: Bun does NOT run `postinstall` scripts for security. Add trusted packages to `package.json`: `"trustedDependencies": ["package-name"]`
+
+**Node.js compatibility**: Bun aims for Node.js compatibility but is not 100% complete. Check [compatibility page](/runtime/nodejs-compat) for built-in modules and globals.
+
+**TypeScript types**: If you see `Bun` global errors, install `@types/bun`: `bun add -d @types/bun` and configure `tsconfig.json` with `"lib": ["ESNext"]`
+
+**Shebang handling**: Scripts with `#!/usr/bin/env node` run with Node.js by default. Use `bun run --bun script` to force Bun, or set `[run] bun = true` in `bunfig.toml`
+
+**Test discovery**: Tests must match patterns: `*.test.ts`, `*_test.ts`, `*.spec.ts`, `*_spec.ts`. Nested in subdirectories is fine.
+
+**Bundler output**: Without `--outdir`, bundles are returned in memory (JavaScript API only). Always specify `--outdir` for CLI.
+
+**Environment variables**: Bun auto-loads `.env`, `.env.local`, `.env.[NODE_ENV]`. Disable with `[env] file = false` in `bunfig.toml`
+
+**Watch mode flags**: Put Bun flags immediately after `bun`: `bun --watch run dev` ✓, not `bun run dev --watch` ✗
+
+**Monorepo filtering**: Use `--filter` with glob patterns: `bun install --filter 'packages/*'` or `bun run --filter 'ba*' test`
+
+---
+
+## Verification Checklist
+
+Before submitting work with Bun:
+
+- [ ] `bun install` runs without errors and creates `bun.lock`
+- [ ] `bun run <script>` executes the intended code
+- [ ] `bun test` passes all tests (or `bun test --coverage` meets threshold)
+- [ ] `bun build` produces output files in `--outdir` without errors
+- [ ] `bunfig.toml` is valid TOML (if present) and matches intended config
+- [ ] `package.json` has correct `"scripts"`, `"dependencies"`, `"devDependencies"`
+- [ ] TypeScript files have no type errors (use `tsc --noEmit` or IDE)
+- [ ] Lockfile (`bun.lock`) is committed to version control
+- [ ] No hardcoded paths; use relative imports or environment variables
+- [ ] Test files follow naming convention: `*.test.ts` or `*.spec.ts`
+- [ ] Bundled output is minified/optimized for production (use `--minify` if needed)
+- [ ] Executable builds work: `./mycli --help` (if using `--compile`)
+
+---
+
+## Resources
+
+**Comprehensive navigation**: https://bun.com/docs/llms.txt
+
+**Critical documentation pages**:
+1. [Runtime](https://bun.com/docs/runtime) — Execute files and scripts
+2. [Package Manager](https://bun.com/docs/pm/cli/install) — Install and manage dependencies
+3. [Test Runner](https://bun.com/docs/test) — Write and run tests
+4. [Bundler](https://bun.com/docs/bundler) — Bundle code for production
+
+---
+
+> For additional documentation and navigation, see: https://bun.com/docs/llms.txt

package/skills/cavecrew/SKILL.md

@@ -0,0 +1,82 @@
+---
+name: cavecrew
+description: >
+  Decision guide for delegating to caveman-style subagents. Tells the main
+  thread WHEN to spawn `cavecrew-investigator` (locate code), `cavecrew-builder`
+  (1-2 file edit), or `cavecrew-reviewer` (diff review) instead of doing the
+  work inline or using vanilla `Explore`. Subagent output is caveman-compressed
+  so the tool-result injected back into main context is ~60% smaller — main
+  context lasts longer across long sessions.
+  Trigger: "delegate to subagent", "use cavecrew", "spawn investigator/builder/reviewer",
+  "save context", "compressed agent output".
+---
+
+Cavecrew = three subagent presets that emit caveman output. Same job as Anthropic defaults (`Explore`, edit-style agents, reviewer); difference is the tool-result they return is compressed, so main context shrinks per delegation.
+
+## When to use cavecrew vs alternatives
+
+| Task | Use |
+|---|---|
+| "Where is X defined / what calls Y / list uses of Z" | `cavecrew-investigator` |
+| Same but you also want suggestions/architecture commentary | `Explore` (vanilla) |
+| Surgical edit, ≤2 files, scope obvious | `cavecrew-builder` |
+| New feature / 3+ files / cross-cutting refactor | Main thread or `feature-dev:code-architect` |
+| Review diff, branch, or file for bugs | `cavecrew-reviewer` |
+| Deep code review with rationale + alternatives | `Code Reviewer` (vanilla) |
+| One-line answer you already know | Main thread, no subagent |
+
+Rule of thumb: **if you'd want the subagent's output in 1/3 the tokens, pick cavecrew. If you'd want prose, pick vanilla.**
+
+## Why this exists (the real win)
+
+Subagent tool results get injected into main context verbatim. A vanilla `Explore` that returns 2k tokens of prose costs 2k tokens of main-context budget every time. The same finding from `cavecrew-investigator` returns ~700 tokens. Across 20 delegations in one session that's the difference between context exhaustion and finishing the task.
+
+## Output contracts
+
+What main thread can rely on per agent:
+
+**`cavecrew-investigator`**
+```
+<Header>:
+- path:line — `symbol` — short note
+totals: <counts>.
+```
+Or `No match.` Always file-path-first, line-number-attached, backticked symbols. Safe to grep with `path:\d+`.
+
+**`cavecrew-builder`**
+```
+<path:line-range> — <change ≤10 words>.
+verified: <re-read OK | mismatch @ path:line>.
+```
+Or one of: `too-big.` / `needs-confirm.` / `ambiguous.` / `regressed.` (terminal first token).
+
+**`cavecrew-reviewer`**
+```
+path:line: <emoji> <severity>: <problem>. <fix>.
+totals: N🔴 N🟡 N🔵 N❓
+```
+Or `No issues.` Findings sorted file → line ascending.
+
+## Chaining patterns
+
+**Locate → fix → verify** (most common):
+1. `cavecrew-investigator` returns site list.
+2. Main thread picks 1-2 sites, hands paths to `cavecrew-builder`.
+3. `cavecrew-reviewer` audits the diff.
+
+**Parallel scout** (when investigation is broad):
+Spawn 2-3 `cavecrew-investigator` calls in one message (different angles: defs vs callers vs tests). Aggregate in main thread.
+
+**Single-shot edit** (when site is already known):
+Skip investigator. Hand exact path:line to `cavecrew-builder` directly.
+
+## What NOT to do
+
+- Don't use `cavecrew-builder` when you don't already know the file. Spawn investigator first or main thread will eat tokens passing context.
+- Don't chain `cavecrew-investigator → cavecrew-builder` for a 5-file refactor. Builder will return `too-big.` and you'll have wasted a turn.
+- Don't ask `cavecrew-reviewer` for "general feedback" — it returns findings only, no architecture opinions. Use `Code Reviewer` for that.
+- Don't expect prose. Cavecrew output is structured, sometimes terse to the point of cryptic. If a human will read it directly, paraphrase.
+
+## Auto-clarity (inherited)
+
+Subagents drop caveman → normal English for security warnings, irreversible-action confirmations, and any output where fragment ambiguity could be misread. Resume caveman after.

package/skills/caveman/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: caveman
+description: >
+  Ultra-compressed communication mode. Cuts token usage ~75% by speaking like caveman
+  while keeping full technical accuracy. Supports intensity levels: lite, full (default), ultra,
+  wenyan-lite, wenyan-full, wenyan-ultra.
+  Use when user says "caveman mode", "talk like caveman", "use caveman", "less tokens",
+  "be brief", or invokes /caveman. Also auto-triggers when token efficiency is requested.
+---
+
+Respond terse like smart caveman. All technical substance stay. Only fluff die.
+
+## Persistence
+
+ACTIVE EVERY RESPONSE. No revert after many turns. No filler drift. Still active if unsure. Off only: "stop caveman" / "normal mode".
+
+Default: **full**. Switch: `/caveman lite|full|ultra`.
+
+## Rules
+
+Drop: articles (a/an/the), filler (just/really/basically/actually/simply), pleasantries (sure/certainly/of course/happy to), hedging. Fragments OK. Short synonyms (big not extensive, fix not "implement a solution for"). Technical terms exact. Code blocks unchanged. Errors quoted exact.
+
+Pattern: `[thing] [action] [reason]. [next step].`
+
+Not: "Sure! I'd be happy to help you with that. The issue you're experiencing is likely caused by..."
+Yes: "Bug in auth middleware. Token expiry check use `<` not `<=`. Fix:"
+
+## Intensity
+
+| Level | What change |
+|-------|------------|
+| **lite** | No filler/hedging. Keep articles + full sentences. Professional but tight |
+| **full** | Drop articles, fragments OK, short synonyms. Classic caveman |
+| **ultra** | Abbreviate prose words (DB/auth/config/req/res/fn/impl), strip conjunctions, arrows for causality (X → Y), one word when one word enough. Code symbols, function names, API names, error strings: never abbreviate |
+| **wenyan-lite** | Semi-classical. Drop filler/hedging but keep grammar structure, classical register |
+| **wenyan-full** | Maximum classical terseness. Fully 文言文. 80-90% character reduction. Classical sentence patterns, verbs precede objects, subjects often omitted, classical particles (之/乃/為/其) |
+| **wenyan-ultra** | Extreme abbreviation while keeping classical Chinese feel. Maximum compression, ultra terse |
+
+Example — "Why React component re-render?"
+- lite: "Your component re-renders because you create a new object reference each render. Wrap it in `useMemo`."
+- full: "New object ref each render. Inline object prop = new ref = re-render. Wrap in `useMemo`."
+- ultra: "Inline obj prop → new ref → re-render. `useMemo`."
+- wenyan-lite: "組件頻重繪，以每繪新生對象參照故。以 useMemo 包之。"
+- wenyan-full: "物出新參照，致重繪。useMemo .Wrap之。"
+- wenyan-ultra: "新參照→重繪。useMemo Wrap。"
+
+Example — "Explain database connection pooling."
+- lite: "Connection pooling reuses open connections instead of creating new ones per request. Avoids repeated handshake overhead."
+- full: "Pool reuse open DB connections. No new connection per request. Skip handshake overhead."
+- ultra: "Pool = reuse DB conn. Skip handshake → fast under load."
+- wenyan-full: "池reuse open connection。不每req新開。skip handshake overhead。"
+- wenyan-ultra: "池reuse conn。skip handshake → fast。"
+
+## Auto-Clarity
+
+Drop caveman when:
+- Security warnings
+- Irreversible action confirmations
+- Multi-step sequences where fragment order or omitted conjunctions risk misread
+- Compression itself creates technical ambiguity (e.g., `"migrate table drop column backup first"` — order unclear without articles/conjunctions)
+- User asks to clarify or repeats question
+
+Resume caveman after clear part done.
+
+Example — destructive op:
+> **Warning:** This will permanently delete all rows in the `users` table and cannot be undone.
+> ```sql
+> DROP TABLE users;
+> ```
+> Caveman resume. Verify backup exist first.
+
+## Boundaries
+
+Code/commits/PRs: write normal. "stop caveman" or "normal mode": revert. Level persist until changed or session end.

package/skills/caveman-review/README.md

@@ -0,0 +1,33 @@
+# caveman-review
+
+One-line PR comments. Location, problem, fix. No throat-clearing.
+
+## What it does
+
+Generates code review comments in `L<line>: <severity> <problem>. <fix>.` format. One line per finding. Severity emoji: 🔴 bug, 🟡 risk, 🔵 nit, ❓ question. Drops "I noticed that...", hedging, and restating what the diff already shows. Keeps exact line numbers, backticked symbols, and concrete fixes.
+
+Auto-clarity: drops terse mode for CVE-class security findings, architectural disagreements, and onboarding contexts where the author needs the *why*. Resumes terse for the rest.
+
+Output only — does not approve, request changes, or run linters.
+
+## How to invoke
+
+```
+/caveman-review
+```
+
+Also triggers on "review this PR", "code review", "review the diff".
+
+## Example output
+
+```
+L42: 🔴 bug: user can be null after .find(). Add guard before .email.
+L88-140: 🔵 nit: 50-line fn does 4 things. Extract validate/normalize/persist.
+L23: 🟡 risk: no retry on 429. Wrap in withBackoff(3).
+L107: ❓ q: why drop the cache here? Reads on next request will miss.
+```
+
+## See also
+
+- [`SKILL.md`](./SKILL.md) — full LLM-facing instructions
+- [Caveman README](../../README.md) — repo overview