change-lifecycle

Implement a change whose OpenSpec proposal and tasks live in a downstream jj WORKSPACE (created by start-change), not the base checkout. Before touching anything it points the tooling at the workspace — cwd for the CLI/tests, Claude Code's native Read/Edit/Write for all workspace file ops — because a base-rooted agent cannot see the change (`openspec` resolves by cwd) and, worse, Serena would SILENTLY edit the wrong checkout (its project stays on base; `claude-code` excludes activate_project). Then it delegates apply mechanics to the OpenSpec apply skill, implements tasks.md, and verifies. Use when the user says "make / implement / apply the change", "do <ID>", or wants to work through the tasks of a change start-change set up in a workspace — the implement step between start-change and end-change. It does NOT push or open the PR (that's end-change) and does NOT re-derive the design (that's start-change).

Kick off a tracked code change on jj workspaces: create the tracking issue, spin up a dedicated jj workspace for it, and — only when the change touches OpenSpec specs — author the proposal via the OpenSpec propose skill. One slug names the workspace (../<slug>), the bookmark (<type>/<slug>), and the OpenSpec change-id, so everything (including the eventual PR) stays coordinated. Use when the user wants to "start a change", "open/spin up a workspace for this", or "kick off a change/feature/bugfix" before implementing. Setup only — stops once the issue, workspace, and (if needed) approved proposal exist; does NOT implement and does NOT open the PR. The issue tracker is pluggable (Linear, GitHub Issues, or none).

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.

Deep technical triage of a SINGLE issue: read the issue, the governing OpenSpec specs, and the code (via Serena symbol tools), then return a determination — what the fix actually requires, whether it impacts OpenSpec or is a code-only change that leaves specs and code in sync, plus a proposed type/slug and fix-sketch. Applies a canonical triage label (ready-for-agent / ready-for-human / needs-info) via the active issue-tracking binding as its final step. Understands; does NOT fix and does NOT create a workspace. Use to "triage this change/bug", "scope <ID>", "what would it take to fix X", "does this touch the spec / need OpenSpec", or "is this ready for an agent". Complements (does not replace) the board-level `triage` skill, and feeds `start-change`.

Redirect the conversation's working context to the jj WORKSPACE that holds a change (proposal/tasks/code) that does NOT exist in the base checkout. Given an issue reference (e.g. <ID>) or a change slug (e.g. lane-stacking), it resolves the workspace dir (../<slug>), verifies it, loads the change's proposal/tasks/design (or, code-only, the issue body), and states a working contract — cwd = the workspace for every CLI/test/dev command, all workspace file ops via native Read/Edit/Write/Grep/Glob on absolute ../<slug>/ paths, Serena reserved for base-checkout work — so the agent operates there for the rest of the session. Use at the START of a conversation, in the same agent (no second instance), to "focus on workspace X" without re-explaining it each turn. Triggers: "/change-context <ID>", "focus on the workspace for <slug>", "work in the jj workspace called X". It only SETS context — it does not implement, push, or open a PR (that's make-change / end-change). The issue tracker is pluggable.