superself — Claude Code skill: what it does, how to install

---
name: superself
description: 'Use when a project keeps its state in Superself (a `<!-- superself:begin` block in AGENTS.md or CLAUDE.md, or `self setup` resolves the directory to a registered project): read `self context` at session start, attach work to a work unit, report with evidence, and record confirmed decisions so the next session picks up where this one left off.'
---

# Superself

Superself is an Apache-2.0 CLI (`npm install -g [email protected]`, Node 22.12+) that
version-controls a project's state — goals, decisions, work units, reports —
as an append-only event log in a git repository separate from the code. The
state is derived on demand, so nothing in it is hand-maintained. This skill
tells an agent how to read and write that state through the `self` CLI. It is
maintained by the Superself authors: https://github.com/fxylabs/superself

## When this skill applies

- The project's `AGENTS.md` or `CLAUDE.md` contains a block between
  `<!-- superself:begin` and `<!-- superself:end -->`, or `self setup` prints
  the workspace, project, and store this directory resolves to.
- Skip the skill when `self --version` fails: the project does not use
  Superself, and nothing below should be invented by hand. This skill is
  written against `[email protected]`; a different major or minor version may
  have moved a verb or flag, so check `self <command> --help` before relying
  on one.

## Session start

1. Run `self context` and treat its output as current truth: the goal, active
   decisions and conventions, open work, recent reports. It is folded from the
   log, never written by hand.
2. Something missing from context was placed out of the rendered set on
   purpose; `self search <query>` finds live records context left out, and
   `self work show <id>` prints one unit's full brief and report history.

## While working

- Substantive work attaches to a work unit. Create one with
  `self work add "<required outcome>"` — the outcome is what must become true,
  not the task — then `self work start <id>`. `start` reads the brief and
  records that this session picked the unit up; if another session holds it,
  the CLI says who and since when and does not refuse. Judge and proceed.
- After committing, report progress: `self report <id> "<what happened>"`. The
  current HEAD commit is attached as evidence automatically; `--evidence
  <commit|note>` attaches something else, `--file <path>` attaches a longer
  brief.
- Record a decision the user confirmed: `self decide "<text>" --why "<reason>"`.
  Use `--proposed` when the user has not confirmed it. One decision per event.
- Blocked? `self work block <id> --on decision|dependency|external --why "..."`.
  Superseded or moved? `self work retire <id> --why "..." [--successor <id>]`.
  Never mark such a unit done, and never leave it falsely blocked.
- Found a gap between an objective and the current state? Propose the work with
  `self work propose` and its brief; the user accepts or declines it.
- The user approved a next step or a continuation? Register it at once with
  `self work add` and the context behind it. A plan that lives only in the
  conversation is lost when the conversation ends.

## Closing

- `self work done <id>` closes a unit only when a report carries a commit or an
  artifact, or the done itself states what verifiably happened:
  `self work done <id> --report "<what verifiably happened>"`. A bare claim is
  refused, and declared criteria gate it until each is covered.
- A record's text is immutable once confirmed. Correct it by restating:
  `--supersedes <id>` on any add verb records the new wording and keeps the
  lineage. `retract` withdraws a record with nothing replacing it.

## Rules that keep the state trustworthy

- Records — events, decisions, reports, conventions — are written in English
  so whoever opens them next can read them; answer the person in their own
  language.
- A branch reaches main through a pull request: PR review and CI own merge
  control. Superself owns context and the work graph, not the merge gate.
- Never hand-edit generated state files or anything under `.superself/`.
- In a project without a superself block, run `self setup` first. If it
  resolves the directory to a registered project, ask the user once whether
  to run `self connect`, which writes the managed block into `AGENTS.md` or
  `CLAUDE.md`. If it resolves no project, ask once whether to register it with
  `self project init`. Never register or connect a project on your own.

## Going deeper

`self --help` lists every verb; `self <command> --help` prints one command's
flags without touching state. Topic guides ship with the CLI:

- `self help agents` — how a session drives this CLI, start to finish
- `self help context` — what `self context` renders, and why something is missing from it
- `self help records` — one entity behind every record kind, and how a record is corrected
- `self help placement` — scope, priority and exposure — how a record earns its place in context
- `self help work` — the work graph: outcomes, evidence, criteria, and proposals
- `self help goals` — long-term goals, objectives, milestones, and what reaching one takes
- `self help workspace` — the store, the projects in it, and moving it between machines