undo

---
name: undo
description: Revert changes Kaizen applied — the last batch, a specific batch id, or everything — restoring settings, removing installed hooks, rule blocks, skills and agents. Use when the user wants to roll back, disable or remove something Kaizen set up.
argument-hint: "[batch-id | --all]"
allowed-tools: Bash(node "*kaizen.mjs" *) Read
---

# Kaizen undo

1. Kit root = `${CLAUDE_PLUGIN_ROOT}` or the clone path. Run `node "${CLAUDE_PLUGIN_ROOT}/scripts/kaizen.mjs" status` as one literal line (no shell variable or alias) and list the applied batches (id, date, recipe ids) in the user's language.
2. Decide the target: the batch the user named, `--last` (default) or `--all`. One Kaizen run can leave several batches (the main `apply`, then one per drafted rule or skill) and plain `undo` or `--last` reverts only the newest one: to revert a whole run, list its batch ids from `status` and undo each, newest first, or use `--all` when no older Kaizen batch should stay. If the user names a single recipe inside a multi-recipe batch, explain that undo works per batch and offer only the whole batch: undo it, then re-apply the recipes the user wants to keep with `apply --from-batch <id> --recipe <ids to keep>` (run it right after the undo). `--from-batch` reuses the scope, project directory and parameters that batch was applied with (hook modes and branches, drafted CLAUDE.md rules, skill bodies); a plain `apply --recipe <ids>` would fall back to the defaults and lose them, and a text recipe whose parameter is empty is skipped. Add `--dry-run` first, as in `apply`. Custom recipes (`custom.*`) are re-applied with the text the batch applied (the batch saves it); a batch of an older version did not, so `--from-batch` then needs the same `--add <extra recipes file>` they were applied with, applies the CURRENT draft with a warning on stderr (tell the user it may differ from what the batch had), and stops without writing anything when the draft no longer has the recipe: then ask whether to leave that recipe out with `--recipe`. The re-apply is a new batch with a new id. Never edit `settings.json`, `CLAUDE.md` or `~/.claude.json` by hand to remove one item: only `apply` and `undo` write there, and a hand edit would make a later `undo` of that batch report "kept: … modified since apply".
3. `node "${CLAUDE_PLUGIN_ROOT}/scripts/kaizen.mjs" undo <id|--all> --dry-run` → show what will be reverted. A dry run changes nothing: its last line says "Dry run: nothing reverted. N change(s) … would be reverted", so do not tell the user the undo has happened yet.
4. `node "${CLAUDE_PLUGIN_ROOT}/scripts/kaizen.mjs" undo <id|--all>`. Items reported as "kept: … modified since apply" were changed by the user after Kaizen wrote them; Kaizen leaves them alone — say which ones. The batch then stays in the journal as partly undone: running `undo <id>` again retries only the kept items, and `undo <id> --force` reverts them anyway after saving their current state under `applied/<id>/undo/<run>/backups/` (`<run>` is a timestamp folder, one per undo run; list the batch's `undo` folder to find it). Offer `--force` only after the user has looked at what they would lose.
5. Confirm the result and remind that a restart of the Claude Code session may be needed for hook changes to take effect.
6. If the user wants Kaizen gone altogether: `undo --all` first, then (only then) the state directory may be deleted (`stateDir` from `node "${CLAUDE_PLUGIN_ROOT}/scripts/kaizen.mjs" paths`). The installed hook scripts and the status line live in that folder, and so does the undo journal: deleting it first leaves hooks in `settings.json` pointing at missing files (they fail on every event and stop guarding anything) and makes `undo` impossible. Do not delete it yourself; tell the user the path.