From change-lifecycle
Tear down a shipped change's jj workspace, bookmark, and working directory once its PR has merged, so workspaces don't accumulate. Takes an issue id (e.g. <ID>) or a change slug. DESTRUCTIVE — before removing anything it runs a safety assessment (PR merged? bookmark pushed and current? uncommitted or untracked files that would be lost?) then a MANDATORY multiple-choice confirmation gate. Use AFTER end-change + merge, when the user says "tear down <X>", "clean up the workspace for <ID>", "remove the <slug> workspace", or wants to prune a finished change. Removes only — it does not start the next change (that's start-change) and does not merge anything.
How this skill is triggered — by the user, by Claude, or both
Slash command
/change-lifecycle:teardown-changeThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
The cleanup bookend of the change workflow: `… → end-change → (merge) → **teardown-change** → start-change`
The cleanup bookend of the change workflow: … → end-change → (merge) → **teardown-change** → start-change
the next one. Once a change's PR is merged, its sibling jj workspace (../<slug>), bookmark
(<type>/<slug>), and on-disk directory are dead weight — this removes them, safely and on purpose.
Delegate all jj mechanics to the jj-vcs:jj skill. This plugin hard-requires the jj-vcs plugin.
Be precise about blast radius so the gate is honest:
jj workspace forget + deleting the bookmark do not destroy commits —
jj keeps them in the op log; jj op log / the change-id can restore them. So committed work survives.rm -rf ../<slug> destroys anything not in jj
and not on the remote: a hydrated .env.local, node_modules (both regenerable), and any ad-hoc
untracked file the user created there (not regenerable). This is the real irreversible loss.rm -rf.From an issue id or a slug, resolve the workspace ../<slug> and bookmark <type>/<slug> (the same
resolution change-context uses). For an issue, resolve the issue→change binding per
${CLAUDE_PLUGIN_ROOT}/references/issue-tracking.md and read the 🤖 start/end-change cross-link comment
to recover the slug. Confirm the workspace exists; if it doesn't, say so and stop (nothing to tear down).
gh pr view <type>/<slug> --json state,mergedAt (or check the bookmark commit is an
ancestor of main@origin). Merged → safe.<type>/<slug> pushed and equal to its remote-tracking bookmark? Unpushed
commits → unsafe.../<slug>, jj st for uncommitted changes; list untracked files
beyond the standard .env.local / node_modules (those are the irrecoverable ones).See references/safety-and-recovery.md for the exact commands.
Present a single-select multiple-choice question (AskUserQuestion) summarising the assessment and recoverability. Do not run any destructive command until the user picks an affirmative option. Recommend the safe answer based on the assessment. Shape it like:
Tear down
../<slug>()? Forgets the jj workspace, deletes bookmark<type>/<slug>, andrm -rfs the directory. PR is <merged|NOT merged>; bookmark <pushed|unpushed>; untracked file(s) in the dir (.env.local,node_modules, …) will be permanently lost (commits recoverable viajj op log; untracked files not). This cannot be undone.
Run from the primary workspace (you can't forget the workspace you're standing in):
cd <primary> # e.g. the repo root
jj workspace forget <slug> # detach the workspace
rm -rf ../<slug> # remove the working directory
jj bookmark delete <type>/<slug> # local bookmark (remote branch usually gone on merge)
jj workspace list # confirm <slug> is gone
State what was removed and the recovery path for committed work (jj op log → change-id / op hash) in
case of regret. Then stop. (Starting the next change is start-change, not this skill.)
jj workspace/bookmark ops from the primary checkout; you can't forget the
workspace you're standing in.references/safety-and-recovery.md — merged/pushed/untracked assessment commands, the exact teardown
sequence, and how to recover a torn-down change from jj op log.${CLAUDE_PLUGIN_ROOT}/references/issue-tracking.md — issue-tracking binding (Linear → GitHub → none),
used to resolve the slug from an issue id.npx claudepluginhub dannygoodall/jj-openspec-linear --plugin change-lifecycleProvides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.