### Install Cavekit v4 (Default)

Source: https://github.com/sebest-design/cavekit/blob/main/LAUNCH-POST.md

Install the latest version of Cavekit using npx. This is the recommended installation method for new projects.

```bash
npx skills add JuliusBrussee/cavekit
```

--------------------------------

### Install Cavekit v3 (Legacy)

Source: https://github.com/sebest-design/cavekit/blob/main/LAUNCH-POST.md

Use this command to install the v3 version of Cavekit if you need to maintain compatibility with older projects or features.

```bash
/plugin marketplace add juliusbrussee/cavekit@v3.1.0
/plugin install ck@cavekit
```

--------------------------------

### Drift Report Example

Source: https://github.com/sebest-design/cavekit/blob/main/skills/check/SKILL.md

This is an example of the output format for drift reports, detailing violations and a summary.

```markdown
## §V drift
V2 VIOLATE: auth/mw.go:47 uses `<` not `≤`. see §B.1.
V5 UNVERIFIABLE: no test covers ∀ req path.

## §I drift
I.api DRIFT: POST /x returns `{result}` not `{id}`. route.go:112.
I.cmd MISSING: `foo bar` absent from cli/*.go.

## §T drift
T3 STALE: status `x`, no middleware file exists.

## summary
2 violate. 1 missing. 1 stale. 1 unverifiable.
next: spec skill with `bug:` or fix code at cited lines.
```

--------------------------------

### Install Cavekit v3.1.0

Source: https://github.com/sebest-design/cavekit/blob/main/UPGRADE.md

Use these commands to install a specific version of Cavekit if you need to access v3.1.0.

```bash
/plugin marketplace add juliusbrussee/cavekit@v3.1.0
/plugin install ck@cavekit
```

```bash
git clone -b v3.1.0 https://github.com/juliusbrussee/cavekit.git
```

--------------------------------

### Install Cavekit v4 via Claude Code Marketplace

Source: https://github.com/sebest-design/cavekit/blob/main/LAUNCH-POST.md

Alternative installation method for Cavekit v4 using the Claude Code marketplace.

```bash
/plugin marketplace add juliusbrussee/cavekit
/plugin install ck@cavekit
```

--------------------------------

### Create SPEC.md with /ck:spec new command

Source: https://context7.com/sebest-design/cavekit/llms.txt

Example of invoking `/ck:spec` to create a new `SPEC.md` file from a project idea, specifying technologies and requirements.

```bash
# Invocation
/ck:spec a REST API for managing TODO items, Node 20, Postgres, JWT auth

# Claude creates SPEC.md:
# SPEC

## §G GOAL
REST API: manage TODO items. Node 20, Postgres, JWT auth.

## §C CONSTRAINTS
- lang: TypeScript
- runtime: Node 20
- db: Postgres (pg driver)
- auth: JWT, expiry 1h

```

--------------------------------

### Drift Report Example

Source: https://github.com/sebest-design/cavekit/blob/main/commands/check.md

This is an example of the output generated by the /check command, detailing various types of drifts and violations found in the codebase compared to the specification.

```text
## §V drift
V2 VIOLATE: auth/mw.go:47 uses `<` not `≤`. see §B.1.
V5 UNVERIFIABLE: no test covers ∀ req path.

## §I drift
I.api DRIFT: POST /x returns `{result}` not `{id}`. route.go:112.
I.cmd MISSING: `foo bar` absent from cli/*.go.

## §T drift
T3 STALE: status `x`, no middleware file exists.

## summary
2 violate. 1 missing. 1 stale. 1 unverifiable.
next: `/spec bug:` or fix code at cited lines.
```

--------------------------------

### SPEC.md Structure Example

Source: https://github.com/sebest-design/cavekit/blob/main/FORMAT.md

Illustrates the fixed sections and headers within a SPEC.md file, including GOAL, CONSTRAINTS, INTERFACES, INVARIANTS, TASKS, and BUGS.

```markdown
# SPEC

## §G GOAL
one line. what code must do.

## §C CONSTRAINTS
- bullet. non-negotiable boundary.
- bullet. tech/lang/lib locked in.

## §I INTERFACES
external surface. what world sees.
- cmd: `foo bar` → stdout JSON
- api: POST /x → 200 {id}
- file: `config.yaml` schema …
- env: `FOO_KEY` required

## §V INVARIANTS
numbered. testable. each ! MUST hold.
V1: ∀ req → auth check before handler
V2: token expiry ≤ ⊥ allowed
V3: DB write ! in transaction

## §T TASKS
pipe table. ids monotonic (never reused). status: `x` done / `~` wip / `.` todo.
id|status|task|cites
T1|.|scaffold repo|-
T2|.|impl §I.api POST /x|V2
T3|x|add §V.1 middleware|V1,I.api

## §B BUGS
pipe table. backprop log. each row = bug + invariant that catches recurrence.
id|date|cause|fix
B1|2026-04-20|token `<` not `≤`|V2
B2|2026-04-21|race on write|V3

```

--------------------------------

### Good Invariant Criteria Example

Source: https://context7.com/sebest-design/cavekit/llms.txt

Illustrates the criteria for writing effective invariants within the Cavekit system, contrasting a 'BAD' example with a 'GOOD' one.

```text
# Good invariant criteria:
# BAD:  V8: code should be correct.
# GOOD: V8: ∀ pg_query ! params via driver, ⊥ string concat
```

--------------------------------

### Install Cavekit via Git Clone

Source: https://github.com/sebest-design/cavekit/blob/main/README.md

Clones the cavekit repository directly into your Claude plugins directory. This method is useful for development or if direct plugin installation is not preferred.

```bash
git clone https://github.com/juliusbrussee/cavekit.git ~/.claude/plugins/cavekit
```

--------------------------------

### Caveman Example: Authentication Requirement

Source: https://github.com/sebest-design/cavekit/blob/main/skills/caveman/SKILL.md

Illustrates the Caveman encoding for a requirement, contrasting a verbose English description with a concise, symbolic representation.

```caveman
V1: ∀ req → auth check before handler
```

--------------------------------

### Backprop Spec Example

Source: https://github.com/sebest-design/cavekit/blob/main/skills/backprop/SKILL.md

An example of a backprop spec change, including a row entry and a line entry for a new invariant.

```markdown
§B row: B3|2026-04-20|refund job ran twice on retry|V7
§V line: V7: ∀ refund → idempotency key check before charge reversal
```

--------------------------------

### Good vs Bad Invariant Example

Source: https://github.com/sebest-design/cavekit/blob/main/skills/backprop/SKILL.md

Illustrates the difference between a good, testable invariant and a vague one. Good invariants are specific and actionable.

```text
Bad: V8: code should be correct.
Good: V8: ∀ pg_query ! params interpolated via driver, ⊥ string concat.
```

--------------------------------

### Caveman Encoding Example: Invariant

Source: https://github.com/sebest-design/cavekit/blob/main/FORMAT.md

Shows the 'caveman' encoding for an invariant, demonstrating how to express complex requirements like 'for all requests, perform an authentication check before the handler executes' concisely.

```markdown
V1: ∀ req → auth check before handler

```

--------------------------------

### Install Older Cavekit Version via Git

Source: https://github.com/sebest-design/cavekit/blob/main/README.md

Clones a specific older version (v3.1.0) of the cavekit repository. This allows access to the features of the previous generation without using the marketplace.

```bash
git clone -b v3.1.0 https://github.com/juliusbrussee/cavekit.git
```

--------------------------------

### Caveman Encoding Example: Bug Note

Source: https://github.com/sebest-design/cavekit/blob/main/FORMAT.md

Demonstrates the 'caveman' encoding style for bug notes, contrasting it with verbose prose. It shows how to concisely describe a bug and its fix using symbols and abbreviations.

```markdown
B1: token `<` not `<=` ∴ tokens rejected @ expiry. §V.2 now ! `≤`.

```

--------------------------------

### Caveman Example: Token Expiry Bug

Source: https://github.com/sebest-design/cavekit/blob/main/skills/caveman/SKILL.md

Demonstrates the Caveman encoding for a specific bug related to token expiry, showing how a complex issue is summarized using symbols and short descriptions.

```caveman
B1: token `<` not `≤` → reject @ expiry boundary.
```

--------------------------------

### Caveman Example: API Endpoint

Source: https://github.com/sebest-design/cavekit/blob/main/skills/caveman/SKILL.md

Shows the Caveman encoding for an API endpoint, specifying the HTTP method, path, expected response code, and a simplified representation of the response body.

```caveman
api: POST /x → 200 {id}
```

--------------------------------

### Generate Spec from Code

Source: https://context7.com/sebest-design/cavekit/llms.txt

Use this command when code exists but no SPEC.md. It reverse-engineers a specification from the codebase.

```bash
# Invocation
/ck:spec from-code

# Claude walks the repo and produces:
## §G GOAL
? infer from package.json: "Todo API"

## §I INTERFACES
- api: POST /todos → 201 {id} (src/routes/todos.ts:12)
- api: GET /todos → 200 [{id,title,done}] (src/routes/todos.ts:28)
- env: DATABASE_URL ! set (src/db.ts:3)
- env: JWT_SECRET ! set (src/auth/mw.ts:7)

## §V INVARIANTS
V1: ? auth mw applied — seen in src/auth/mw.ts, coverage unclear
V2: ∀ handler → try/catch present (src/routes/todos.ts:12,28)

# Items marked ? need user confirmation
```

--------------------------------

### SPEC.md format with Caveman Encoding

Source: https://context7.com/sebest-design/cavekit/llms.txt

Illustrates the structure of a `SPEC.md` file using Caveman Encoding, including sections for Goal, Constraints, Interfaces, Invariants, Tasks, and Bugs.

```markdown
# SPEC

## §G GOAL
one line. what code must do.

## §C CONSTRAINTS
- bullet. non-negotiable boundary.
- lang: TypeScript. lib: Zod. runtime: Node 20.

## §I INTERFACES
external surface. what world sees.
- api: POST /users → 200 {id:string}
- cmd: `app sync --dry` → stdout JSON
- env: DATABASE_URL ! required
- file: `config.yaml` schema {port:int, debug:bool}

## §V INVARIANTS
numbered. testable. each ! MUST hold.
V1: ∀ req → auth check before handler
V2: token expiry ≤ current_time → reject
V3: DB write ! in transaction

## §T TASKS
pipe table. ids monotonic (never reused). status: `x` done / `~` wip / `.` todo.
id|status|task|cites
T1|x|scaffold repo|-
T2|~|impl §I.api POST /users|V2
T3|.|add §V.1 middleware|V1,I.api

## §B BUGS
pipe table. backprop log. each row = bug + invariant that catches recurrence.
id|date|cause|fix
B1|2026-04-20|token `<` not `≤`|V2
B2|2026-04-21|race on write|V3

```

--------------------------------

### Backprop Skill - Claude's Internal Steps

Source: https://context7.com/sebest-design/cavekit/llms.txt

This snippet outlines the six internal steps Claude follows when using the backprop skill for bug analysis and resolution. It details TRACE, ANALYZE, PROPOSE, GENERATE TEST, VERIFY, and LOG phases.

```text
# Six steps Claude follows internally:

# 1. TRACE — find exact file:line, name root cause in one caveman sentence
#    "auth/mw.ts:47: token `<` not `≤` → tokens rejected at expiry boundary"

# 2. ANALYZE — three questions:
#    - Would a §V invariant catch this class? → yes
#    - Is §I wrong (spec promised wrong shape)? → no
#    - Is §T wrong (built wrong thing)? → no

# 3. PROPOSE — draft §B row + §V entry:
#    B1|2026-04-20|token `<` not `≤`|V2
#    V2: token expiry ≤ current_time → reject

# 4. GENERATE TEST — invariant without test = lie:
#    describe("V2", () => {
#      it("rejects token exactly at expiry", () => {
#        const token = sign({}, secret, { expiresIn: 0 });
#        expect(verify(token)).toThrow("TokenExpiredError");
#      });
#    });
#    // Test name cites invariant: TestV2_TokenExpiryBoundary

# 5. VERIFY — fix code, run test (pass), run full suite (no regression)

# 6. LOG — single commit containing spec edit + test + code fix:
#    "backprop §B.1 + §V.2: token < not ≤ → reject at expiry boundary
#     Co-Authored-By: Claude <noreply@anthropic.com>"
```

--------------------------------

### Caveman Encoding: Prose vs. Compressed Bug Note

Source: https://context7.com/sebest-design/cavekit/llms.txt

Compares a verbose prose bug note with its compressed Caveman Encoding equivalent, demonstrating token efficiency.

```markdown
# BAD — prose bug note (40 tokens)
B1: Fixed a bug where token expiry comparison used strict less-than instead of
    less-than-or-equal, causing tokens to be rejected exactly at their expiry.

# GOOD — caveman bug row (12 tokens)
B1|2026-04-20|token `<` not `≤` → reject @ expiry boundary|V2

```

--------------------------------

### Environment Variables

Source: https://context7.com/sebest-design/cavekit/llms.txt

Required environment variables for the application.

```APIDOC
## Environment Variables

### DATABASE_URL
- **Required**: Yes
- **Description**: Connection string for the database.

### JWT_SECRET
- **Required**: Yes
- **Description**: Secret key for JSON Web Token generation and verification.
```

--------------------------------

### Caveman Encoding: Prose vs. Compressed Interface

Source: https://context7.com/sebest-design/cavekit/llms.txt

Compares a prose description of an API interface with its compressed Caveman Encoding equivalent.

```markdown
# BAD — prose interface
api: The POST endpoint at /x accepts JSON and returns a 200 response with id.

# GOOD — caveman interface
api: POST /x → 200 {id:string}

```

--------------------------------

### Build Task Against Spec

Source: https://context7.com/sebest-design/cavekit/llms.txt

Executes tasks defined in SPEC.md, respecting all invariants and interfaces. It plans, executes, verifies, and auto-backprops on failure.

```bash
# Build the next pending task
/ck:build --next

# Build a specific task
/ck:build §T.4

# Build all pending tasks
/ck:build --all

# --- What Claude does internally for /ck:build §T.4 ---

# 1. LOAD: reads SPEC.md, identifies T4: "POST /todos handler | cites V3,I.api"
# 2. PLAN (shown to user):
#    Invariants in scope: V3 (DB write in transaction)
#    Interfaces: I.api (POST /todos → 201 {id,title})
#    Files: src/routes/todos.ts (create), src/routes/todos.test.ts (create)
#    Verification: npm test
# 3. EXECUTE on user OK:
#    - Flip T4 status: . → ~  (writes SPEC.md)
#    - Write src/routes/todos.ts with transactional insert
#    - Write src/routes/todos.test.ts with TestV3_TodoCreateTransactional
#    - Run: npm test
# 4. PASS → flip T4: ~ → x, commit:
#    "T4: POST /todos handler (V3,I.api)
#     Co-Authored-By: Claude <noreply@anthropic.com>"
# 5. FAIL → auto-backprop (see backprop skill), then resume

# Check task status at any time (no command needed):
cat SPEC.md | grep "§T" -A 20
```

```bash
# Test failure during /ck:build §T.3:
# Error: INSERT fails outside transaction in edge-case retry path

# Claude classifies: (b) spec wrong — V3 did not cover retry paths
# Invokes backprop:
#   B2|2026-05-11|insert outside tx on retry|V6
#   V6: ∀ retry path → explicit transaction wrap
# Resumes build against updated spec.
# Never silently fixes without updating §B.
```

--------------------------------

### Caveman Encoding: Prose vs. Compressed Invariant

Source: https://context7.com/sebest-design/cavekit/llms.txt

Compares a verbose prose invariant with its compressed Caveman Encoding equivalent, highlighting token reduction.

```markdown
# BAD — prose invariant (32 tokens)
V1: The authentication middleware must verify the token expiry on every
    request before allowing the handler to execute.

# GOOD — caveman invariant (8 tokens)
V1: ∀ req → auth check before handler

```

--------------------------------

### Todo API Endpoints

Source: https://context7.com/sebest-design/cavekit/llms.txt

These are the available API endpoints for interacting with the todo list.

```APIDOC
## POST /todos

### Description
Creates a new todo item.

### Method
POST

### Endpoint
/todos

### Request Body
(Not specified in source)

### Response
#### Success Response (201)
- **id** (string) - The unique identifier for the created todo.
- **title** (string) - The title of the todo item.

### Response Example
```json
{
  "id": "string",
  "title": "string"
}
```
```

```APIDOC
## GET /todos

### Description
Retrieves a list of all todo items.

### Method
GET

### Endpoint
/todos

### Parameters
(Not specified in source)

### Response
#### Success Response (200)
- **id** (string) - The unique identifier for the todo item.
- **title** (string) - The title of the todo item.
- **done** (boolean) - Indicates if the todo item is completed.

### Response Example
```json
[
  {
    "id": "string",
    "title": "string",
    "done": "boolean"
  }
]
```
```

```APIDOC
## PATCH /todos/:id

### Description
Updates an existing todo item, specifically its completion status.

### Method
PATCH

### Endpoint
/todos/:id

### Parameters
#### Path Parameters
- **id** (string) - Required - The unique identifier of the todo item to update.

### Request Body
(Not specified in source)

### Response
#### Success Response (200)
- **id** (string) - The unique identifier for the todo item.
- **done** (boolean) - The updated completion status of the todo item.

### Response Example
```json
{
  "id": "string",
  "done": "boolean"
}
```
```

```APIDOC
## DELETE /todos/:id

### Description
Deletes a specific todo item.

### Method
DELETE

### Endpoint
/todos/:id

### Parameters
#### Path Parameters
- **id** (string) - Required - The unique identifier of the todo item to delete.

### Response
#### Success Response (204)
(No content)

### Response Example
(No content)
```

--------------------------------

### SPEC.md Writes Table

Source: https://github.com/sebest-design/cavekit/blob/main/FORMAT.md

Details the commands that modify the SPEC.md file and which sections they affect. This table outlines the write operations for commands like `/spec new`, `/spec amend`, `/spec bug`, and `/build`.

```markdown
| command | writes | section |
|---|---|---|
| `/spec new` | creates | all |
| `/spec amend` | edits | chosen |
| `/spec bug` | appends | §B + §V |
| `/build` | flips | §T status cell `.` → `~` → `x` |
| `/check` | — | read only |

```

--------------------------------

### Backprop Spec Template

Source: https://github.com/sebest-design/cavekit/blob/main/skills/backprop/SKILL.md

Use this template to draft spec changes when backpropagating a bug fix. Always include a §B entry and usually a §V entry.

```markdown
§B row: B<next>|<date>|<root cause>|V<N>
§V line: V<next>: <testable rule that would have caught it>
```

--------------------------------

### Caveman Interface Shape

Source: https://github.com/sebest-design/cavekit/blob/main/skills/caveman/SKILL.md

Describes interfaces using a concise format that specifies the kind, name, and shape of the interface. Supports API endpoints, command-line interfaces, and environment variables.

```caveman
<kind>: <name> → <shape>
api: POST /x → 200 {id:string}
cmd: `foo bar <arg>` → stdout JSON
env: FOO_KEY ! set
```

--------------------------------

### Record Bug and Propose Invariant

Source: https://context7.com/sebest-design/cavekit/llms.txt

Records a bug in the `§B` section of SPEC.md and suggests a new `§V` invariant to prevent its recurrence. This is useful for documenting regressions and ensuring they are addressed.

```bash
# Invocation
/ck:spec bug: refund job ran twice on retry — charged customer twice

# Claude produces diff:
+§B row: B3|2026-05-10|refund job ran twice on retry|V7
+§V line: V7: ∀ refund → idempotency key check before charge reversal

# Show diff → Apply? yes
# Result in SPEC.md:
# §B
# id|date|cause|fix
# B3|2026-05-10|refund job ran twice on retry|V7
# §V
# V7: ∀ refund → idempotency key check before charge reversal
```

--------------------------------

### Caveman Task Row Shape

Source: https://github.com/sebest-design/cavekit/blob/main/skills/caveman/SKILL.md

Defines the structure for task entries in a pipe-delimited table, including 'id', 'status', 'task', and 'cites'. The status field uses specific characters to denote completion.

```caveman
id|status|task|cites
T3|x|add auth mw|V1,I.api
```

--------------------------------

### Report Code Drift

Source: https://context7.com/sebest-design/cavekit/llms.txt

A read-only drift detector that compares SPEC.md against the current codebase. It reports violations grouped by severity and never modifies files.

```bash
# Check all sections
/ck:check --all

# Check invariants only (default)
/ck:check §V

# Check interfaces only
/ck:check §I

# Check task status vs code
/ck:check §T

# --- Sample output for /ck:check --all ---

## §V drift
V2 VIOLATE: auth/mw.ts:47 uses `<` not `≤`. see §B.1.
V5 UNVERIFIABLE: no test covers ∀ req path.

## §I drift
I.api DRIFT: POST /todos returns `{result}` not `{id,title}`. routes/todos.ts:34.
I.cmd MISSING: `app sync --dry` absent from cli/*.ts.

## §T drift
T3 STALE: status `x`, no middleware file exists.
```

--------------------------------

### Caveman Encoding Symbols

Source: https://github.com/sebest-design/cavekit/blob/main/FORMAT.md

Defines a set of symbols used in caveman encoding for concise and machine-readable representation of concepts like 'leads to', 'therefore', 'for all', and 'must'.

```markdown
→   leads to / becomes / triggers
∴   therefore / fix
∀   for all / every
∃   exists / some
!   must
?   may / optional
⊥   never / impossible / forbidden
≠   not equal / differs from
∈   in / member of
∉   not in
≤   at most
≥   at least
&   and
|   or

```

--------------------------------

### Caveman Bug Row Shape

Source: https://github.com/sebest-design/cavekit/blob/main/skills/caveman/SKILL.md

Represents a bug entry using a pipe-delimited table format. The 'id', 'date', 'cause', and 'fix' fields are used to document issues.

```caveman
id|date|cause|fix
B1|2026-04-20|token `<` not `≤`|V2
```

--------------------------------

### Caveman Symbols

Source: https://github.com/sebest-design/cavekit/blob/main/skills/caveman/SKILL.md

Common symbols used in Caveman encoding to represent logical and relational concepts, offering a more concise alternative to words.

```caveman
→   leads to / becomes / on <x>
∴   therefore / fix
∀   for all / every
∃   exists / some
!   must / required
?   may / optional / unknown
⊥   never / forbidden / nil
≠   not equal
∈   in
∉   not in
≤   at most
≥   at least
&   and
|   or
§   section reference
```

--------------------------------

### Amend Spec Section

Source: https://context7.com/sebest-design/cavekit/llms.txt

Edits a specific section of the SPEC.md file without altering other parts. Useful for adding new invariants or modifying existing tasks.

```bash
# Invocation — add a new invariant
/ck:spec amend §V

# Claude shows current §V, asks what to add, then shows diff:
+V5: ∀ pg_query ! params via driver, ⊥ string concat

# Apply? yes

# Invocation — amend a single task
/ck:spec amend §T.3
# Claude shows T3, asks for change, shows diff, applies on OK.
```

--------------------------------

### Caveman Invariant Shape

Source: https://github.com/sebest-design/cavekit/blob/main/skills/caveman/SKILL.md

Defines the structure for representing invariants, which are conditions that must always hold true. It follows the pattern V<n>: <subject> <relation> <condition>.

```caveman
V<n>: <subject> <relation> <condition>
V1: ∀ req → auth check before handler
V2: token expiry ≤ current_time → reject
```

=== COMPLETE CONTENT === This response contains all available snippets from this library. No additional content exists. Do not make further requests.