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

---
name: selvedge
description: Use before editing a tracked entity (a DB column, table, function, API endpoint, dependency, or env var) and after any substantive change. Call prior_attempts first to learn whether the change was tried and reverted before, then log_change to record what changed and why. Selvedge is this project's change memory — a local MCP server and CLI, no LLM calls.
---

## Selvedge — change tracking

Use Selvedge for change tracking through its CLI or optional MCP connection
(MCP server: `selvedge`). Both use the same local store. Use whichever route is
available in the current workflow.

**Rules:**

- Call `selvedge.log_change` immediately after adding, modifying, or
  removing any DB column, table, function, API endpoint, dependency,
  or env variable.
- Set `reasoning` to the user's original request or the problem being
  solved. Write at least one full sentence — the server will warn on
  empty, very short, or generic values like "user request" or "done".
  Good example: "User asked to add 2FA — needs phone number to send
  SMS verification codes."
- Set `agent` to a stable name for the agent or tool making the change.
- Set `session_id` if you have access to the current session/conversation ID.
- Set `git_commit` to the commit hash once you know it.
- For multi-entity changes (e.g. adding a whole feature), set a shared
  `changeset_id` on all related `log_change` calls — use a short slug
  like `add-stripe-billing`. This lets anyone query the full scope of
  the change with `selvedge.changeset()`.
- Before editing an entity, call `selvedge.prior_attempts` on it — if the
  same change was tried before and reverted, you'll see the prior
  reasoning and why it was rejected, and can change your plan instead of
  repeating a rejected approach. Where a compatible edit-gate hook is
  installed and active, watched edits require this lookup. Hook capabilities
  and activation depend on the client.
- A reverted decision is not a permanent ban. If the constraint that
  killed it no longer holds, re-open it explicitly with
  `change_type="supersede"` (never re-apply a reverted change without
  superseding it first).
- Log abandoned paths too: use `change_type="reject"` when you considered
  an approach and decided against it without writing it, and
  `change_type="revert"` when you rolled a change back — ideally with
  `stale_when` or `expires_when` naming the condition that would
  invalidate the verdict, so `stale_decisions` can surface it later.
- Then call `selvedge.diff` or `selvedge.blame` for the entity's broader
  history before conflicting with past decisions.

**The same operations are on your shell.** The CLI and MCP interface use the
same local store (`selvedge` is on your PATH after install). The CLI does not
require a running MCP server. Use the route that fits the current workflow
and keeps context light:

- Check an entity first: `selvedge prior-attempts <entity>` (was it tried and
  reverted before?), then `selvedge blame <entity>` / `selvedge diff <entity>`
  for its broader history.
- Log a change: `selvedge log <entity> <change_type> --reasoning "<why>"`
  (change_type: add, remove, modify, rename, retype, create, delete,
  index_add, index_remove, migrate, revert, reject, supersede; for a
  rename add `--rename-from <old>`).
- Re-open a reverted decision: `selvedge supersede <entity> --reasoning "<why>"`.
- Find things: `selvedge search "<query>"`, `selvedge history --since 7d`,
  `selvedge stale` (decisions now due for a revisit).

Add `--json` to any read command; `selvedge <command> --help` gives detail on
demand.