bigpowers 2.87.8 → 2.88.1

package/.kilocode/rules/survey-context.md

@@ -4,6 +4,8 @@ model: haiku
 description: "Per-task context bootstrap — reads existing specs/ and tech-architecture docs to map the current lifecycle phase and suggest the next skill. Use at the start of any task, when returning after a break, or when unsure what to do next. For deriving a tech-stack doc from scratch, use map-codebase first."
 ---
 
+# story: e82s02
+
 # Survey Context
 
 Read the project's current state and give a phase map + next-skill recommendation. This is the "where am I?" skill — run it at the start of every task.
@@ -51,15 +53,18 @@ Legacy markdown (`specs/archive/STATE.md`, `RELEASE-PLAN.md`) is **not** SoT if
 
 If `CLAUDE.md` exists at the project root, read it for project context (stack, commands, architecture, conventions).
 
-### 4. Check git state
+### 4. Check VCS state
+
+Read `state.yaml` `vcs.kind` (or resolve `auto`). Use native identity:
 
 ```bash
-git status --short
-git log --oneline -5
-git branch --show-current
+# Git
+git status --short; git log --oneline -5; git branch --show-current
+# Jujutsu
+jj status; jj log -r 'mine() & ::@' -n 5
 ```
 
-Note: is there a feature branch active? Are there uncommitted changes? Do they match `specs/state.yaml` `git` block?
+For Jujutsu, compare stable change IDs and bookmarks with the `vcs` block; never interpret colocated Git's detached HEAD as branch state.
 
 ### 5. Map the lifecycle phase
 
@@ -124,7 +129,7 @@ Loop through all `specs/epics/*/epic.yaml` files and print a summary of story co
 
 ### check-gates (absorbed)
 
-Print the current `active_flow` from `specs/state.yaml`, run `bash scripts/validate-specs-yaml.sh` to verify YAML integrity, and show `git status` to report uncommitted changes and branch state. Use before handoffs or context transitions.
+Print `active_flow`, validate YAML, then show `git status` or `jj status` according to `vcs.kind`. Use before handoffs or context transitions.
 
 ## Handoff
 

package/.mimocode/skills/commit-message/SKILL.md

@@ -4,6 +4,8 @@ model: haiku
 description: "Reviews working-tree changes, then drafts a Conventional Commits title/body and states the semantic-release version bump a single such commit would imply. Also notes which defensive-code categories were touched. Use when the user wants to commit recent work, prepare a Conventional Commits message, or asks for semantic-release / semver-consistent messaging before git commit."
 ---
 
+# story: e82s02
+
 # Commit Message
 > **HARD GATE** — **HARD GATE** — Commits must follow Conventional Commits spec (type(scope): description). Do NOT use vague messages like 'fix' or 'updates.' The message must explain the 'why,' not the 'what.'
 
@@ -15,7 +17,7 @@ description: "Reviews working-tree changes, then drafts a Conventional Commits t
 
 ## What "last chat" means
 
-- **Primary source of truth:** `git status`, `git diff` (unstaged), and `git diff --cached` (staged). Run these in the repo root (or the paths the user changed).
+- **Primary source of truth:** Read `state.yaml` `vcs.kind`. Git uses `git status`, `git diff`, and `git diff --cached`; Jujutsu uses `jj status`, `jj diff`, and `jj log -r @`. Run in the repo root.
 - **Context:** use the current conversation to summarize *intent* and to spot **breaking** API/behavior changes that diff alone may not show.
 - If the user tracks a session baseline (e.g. branch, tag, or `git stash create` at start), you may `git diff <baseline>..HEAD` plus uncommitted diffs; otherwise use only the index and working tree.
 
@@ -30,7 +32,7 @@ description: "Reviews working-tree changes, then drafts a Conventional Commits t
 7. **Deliver** — Output:
    - Proposed **full commit message** (title + optional body + footers).
    - **Release bump** this commit would drive: `patch` | `minor` | `major` | `none`.
-   - Optional `git add …` and `git commit -m` instructions; do **not** run destructive git commands unless the user asked.
+   - Optional native command: Git `git commit -m`; Jujutsu `jj commit -m`. Never omit `-m` or run destructive commands unless asked.
 
 ## Checklist before finalizing
 

package/.mimocode/skills/kickoff-branch/SKILL.md

@@ -1,20 +1,21 @@
 ---
 name: kickoff-branch
 model: haiku
-description: "Create a git worktree and feature branch, then verify a clean test baseline before any code is written. Use when starting a new feature or task, when user wants to work in isolation from main, or mentions \"start a branch\" or \"new worktree\"."
+description: "Create an isolated Git worktree/branch or Jujutsu workspace, then verify a clean test baseline before code. Use when starting a feature or task."
 ---
 
 # story: e51s03
 # story: e20s03
+# story: e82s02
 
 
 # Kickoff Branch
 
-> **HARD GATE** — Direct work on `main` or `master` is PROHIBITED. Every task MUST start with this skill to create a feature branch or worktree.
+> **HARD GATE** — Direct Git work on `main`/`master` or reuse of an unrelated Jujutsu change is prohibited. Create a feature branch/worktree or Jujutsu workspace/change.
 >
 > **HARD GATE** — Do NOT proceed with development until **Preflight** passes on the default branch. Red Preflight blocks branch creation and all forward work — invoke `quick-fix` or `fix-bug` per CONVENTIONS § Discovered Defects.
 
-Create an isolated working environment before touching any code. **Preflight must be green** before you write feature code — solo-default owns the whole tree, not just the current task diff.
+Create an isolated Git worktree or Jujutsu workspace before code. **Preflight must be green** first — solo-default owns the whole tree.
 
 ## Process
 
@@ -22,9 +23,13 @@ Create an isolated working environment before touching any code. **Preflight mus
 
 Ask if not already known: "What's the name of this feature or task?" Use it as the branch name slug (kebab-case, max 40 chars).
 
-### 2. Anchor on default branch (main or master)
+### 2. Select the VCS procedure
 
-> **HARD GATE** — Kickoff MUST start from an updated, clean default branch in the **primary** repository root (not a linked worktree).
+Read `state.yaml` `vcs.kind`. For `jj`, do not run the Git blocks below: verify with `jj status` and `jj log -r '::@' -n 5`, create isolation with `jj workspace add ../<task-slug> -r @`, then run `jj -R ../<task-slug> describe -m "feat: <task>"`. Record the new stable change ID. For `git`, continue below.
+
+### 2a. Anchor Git on the default branch (main or master)
+
+> **HARD GATE** — Git kickoff MUST start from an updated, clean default branch in the **primary** repository root (not a linked worktree).
 
 ```bash
 # Detect default branch
@@ -63,7 +68,7 @@ fi
 - **Non-spec dirty files** (src/, scripts/, SKILL.md, …) still enforce the full clean-tree gate.
 - If not on `$DEFAULT` after checkout, stop and fix before continuing.
 
-### 3. Pre-flight & Conflict Resolution
+### 3. Git pre-flight & conflict resolution
 
 Before creating the worktree, verify the target environment is clean:
 
@@ -83,7 +88,7 @@ git worktree list | grep "<task-slug>"
 - **Branch exists:** If the branch exists but no worktree is attached, ask to use the existing branch (`git worktree add ../<task-slug> <task-slug>`) or delete it.
 - **Ghost worktree:** If `git worktree list` shows the path but the directory is missing, run `git worktree prune` to clear the stale metadata. `bash scripts/cleanup-worktrees.sh` does this plus reports any worktree whose branch is already merged or deleted — advisory only, it prints the `git worktree remove`/`git branch -d` commands rather than running them, so review before acting.
 
-### 4. Create worktree + branch
+### 4. Create Git worktree + branch
 
 ```bash
 # From the main repo root (not another worktree)

package/.mimocode/skills/release-branch/SKILL.md

@@ -8,6 +8,7 @@ description: "Make the merge/PR/keep/discard decision for a feature branch, veri
 <!-- story: e45s15 -->
 <!-- story: e45s32 -->
 <!-- story: e45s39 -->
+<!-- story: e82s02 -->
 <!-- story: e20s02 -->
 
 
@@ -30,7 +31,7 @@ Read `specs/state.yaml` key `workflow_mode` (`team-pr` | `solo-git`). Fall back
 | **solo-local** | `workflow_mode: solo-git` | Auto: `scripts/land-branch.sh` if present, else fallback (Step 5) |
 | **team-pr** | `workflow_mode: team-pr` (default) | `gh pr create` → `gh pr merge --squash` |
 
-If unsure, prefer **solo-local**.
+If unsure, prefer **solo-local**. Also read `state.yaml` `vcs.kind`: Git follows the procedures below; Jujutsu uses workspaces/bookmarks and must not call Git-only landing scripts.
 
 ## Process
 
@@ -73,16 +74,21 @@ Run `gate-trace` before merge. FAIL blocks merge; CONCERNS requires explicit ove
 
 Options: **Release (solo-local)** / **Open PR** / **Keep branch** / **Discard**
 
-### 5. Solo-local integrate
+### 5. Integrate
 
-Run `commit-message` for the squash subject, then land:
+Run `commit-message` first. Git solo-local uses `land-branch.sh`. Jujutsu team mode explicitly advances and pushes a bookmark; `-m` is mandatory for commit/describe operations:
 
 ```bash
-# Path A (preferred):
+# Git solo-local
 bash scripts/land-branch.sh <task-slug> "feat(scope): description"
-# Path B (fallback if land-branch.sh missing): see REFERENCE.md
+# Jujutsu team PR
+jj describe -m "feat(scope): description"
+jj bookmark set <task-slug> -r @
+jj git push -b <task-slug>
 ```
 
+Jujutsu solo-local landing is unsupported: run `bp_require_vcs_operation "$PWD" land-branch` and stop with its remediation instead of invoking the Git backend.
+
 ### 6. Create PR (team-pr only)
 
 Create the pull request with a **literal provenance marker** in the body so agent-generated PRs are identifiable and do not rot silently:
@@ -131,7 +137,7 @@ bash scripts/wait-for-ci.sh --timeout 600 --interval 30
 
 ### 8. Clean up & return
 
-Worktree prune, branch delete, `git checkout main`. Cycle-time: see [REFERENCE.md](REFERENCE.md#cycle-time).
+Git: prune worktree, delete branch, return to main. Jujutsu: `jj workspace forget <workspace>` only after integration; do not delete its bookmark implicitly. Cycle-time: see [REFERENCE.md](REFERENCE.md#cycle-time).
 
 Report: "Branch released."
 

package/.mimocode/skills/survey-context/SKILL.md

@@ -4,6 +4,8 @@ model: haiku
 description: "Per-task context bootstrap — reads existing specs/ and tech-architecture docs to map the current lifecycle phase and suggest the next skill. Use at the start of any task, when returning after a break, or when unsure what to do next. For deriving a tech-stack doc from scratch, use map-codebase first."
 ---
 
+# story: e82s02
+
 # Survey Context
 
 Read the project's current state and give a phase map + next-skill recommendation. This is the "where am I?" skill — run it at the start of every task.
@@ -51,15 +53,18 @@ Legacy markdown (`specs/archive/STATE.md`, `RELEASE-PLAN.md`) is **not** SoT if
 
 If `CLAUDE.md` exists at the project root, read it for project context (stack, commands, architecture, conventions).
 
-### 4. Check git state
+### 4. Check VCS state
+
+Read `state.yaml` `vcs.kind` (or resolve `auto`). Use native identity:
 
 ```bash
-git status --short
-git log --oneline -5
-git branch --show-current
+# Git
+git status --short; git log --oneline -5; git branch --show-current
+# Jujutsu
+jj status; jj log -r 'mine() & ::@' -n 5
 ```
 
-Note: is there a feature branch active? Are there uncommitted changes? Do they match `specs/state.yaml` `git` block?
+For Jujutsu, compare stable change IDs and bookmarks with the `vcs` block; never interpret colocated Git's detached HEAD as branch state.
 
 ### 5. Map the lifecycle phase
 
@@ -124,7 +129,7 @@ Loop through all `specs/epics/*/epic.yaml` files and print a summary of story co
 
 ### check-gates (absorbed)
 
-Print the current `active_flow` from `specs/state.yaml`, run `bash scripts/validate-specs-yaml.sh` to verify YAML integrity, and show `git status` to report uncommitted changes and branch state. Use before handoffs or context transitions.
+Print `active_flow`, validate YAML, then show `git status` or `jj status` according to `vcs.kind`. Use before handoffs or context transitions.
 
 ## Handoff
 

package/.opencode/skills/commit-message/SKILL.md

@@ -4,6 +4,8 @@ model: haiku
 description: "Reviews working-tree changes, then drafts a Conventional Commits title/body and states the semantic-release version bump a single such commit would imply. Also notes which defensive-code categories were touched. Use when the user wants to commit recent work, prepare a Conventional Commits message, or asks for semantic-release / semver-consistent messaging before git commit."
 ---
 
+# story: e82s02
+
 # Commit Message
 > **HARD GATE** — **HARD GATE** — Commits must follow Conventional Commits spec (type(scope): description). Do NOT use vague messages like 'fix' or 'updates.' The message must explain the 'why,' not the 'what.'
 
@@ -15,7 +17,7 @@ description: "Reviews working-tree changes, then drafts a Conventional Commits t
 
 ## What "last chat" means
 
-- **Primary source of truth:** `git status`, `git diff` (unstaged), and `git diff --cached` (staged). Run these in the repo root (or the paths the user changed).
+- **Primary source of truth:** Read `state.yaml` `vcs.kind`. Git uses `git status`, `git diff`, and `git diff --cached`; Jujutsu uses `jj status`, `jj diff`, and `jj log -r @`. Run in the repo root.
 - **Context:** use the current conversation to summarize *intent* and to spot **breaking** API/behavior changes that diff alone may not show.
 - If the user tracks a session baseline (e.g. branch, tag, or `git stash create` at start), you may `git diff <baseline>..HEAD` plus uncommitted diffs; otherwise use only the index and working tree.
 
@@ -30,7 +32,7 @@ description: "Reviews working-tree changes, then drafts a Conventional Commits t
 7. **Deliver** — Output:
    - Proposed **full commit message** (title + optional body + footers).
    - **Release bump** this commit would drive: `patch` | `minor` | `major` | `none`.
-   - Optional `git add …` and `git commit -m` instructions; do **not** run destructive git commands unless the user asked.
+   - Optional native command: Git `git commit -m`; Jujutsu `jj commit -m`. Never omit `-m` or run destructive commands unless asked.
 
 ## Checklist before finalizing
 

package/.opencode/skills/kickoff-branch/SKILL.md

@@ -1,20 +1,21 @@
 ---
 name: kickoff-branch
 model: haiku
-description: "Create a git worktree and feature branch, then verify a clean test baseline before any code is written. Use when starting a new feature or task, when user wants to work in isolation from main, or mentions \"start a branch\" or \"new worktree\"."
+description: "Create an isolated Git worktree/branch or Jujutsu workspace, then verify a clean test baseline before code. Use when starting a feature or task."
 ---
 
 # story: e51s03
 # story: e20s03
+# story: e82s02
 
 
 # Kickoff Branch
 
-> **HARD GATE** — Direct work on `main` or `master` is PROHIBITED. Every task MUST start with this skill to create a feature branch or worktree.
+> **HARD GATE** — Direct Git work on `main`/`master` or reuse of an unrelated Jujutsu change is prohibited. Create a feature branch/worktree or Jujutsu workspace/change.
 >
 > **HARD GATE** — Do NOT proceed with development until **Preflight** passes on the default branch. Red Preflight blocks branch creation and all forward work — invoke `quick-fix` or `fix-bug` per CONVENTIONS § Discovered Defects.
 
-Create an isolated working environment before touching any code. **Preflight must be green** before you write feature code — solo-default owns the whole tree, not just the current task diff.
+Create an isolated Git worktree or Jujutsu workspace before code. **Preflight must be green** first — solo-default owns the whole tree.
 
 ## Process
 
@@ -22,9 +23,13 @@ Create an isolated working environment before touching any code. **Preflight mus
 
 Ask if not already known: "What's the name of this feature or task?" Use it as the branch name slug (kebab-case, max 40 chars).
 
-### 2. Anchor on default branch (main or master)
+### 2. Select the VCS procedure
 
-> **HARD GATE** — Kickoff MUST start from an updated, clean default branch in the **primary** repository root (not a linked worktree).
+Read `state.yaml` `vcs.kind`. For `jj`, do not run the Git blocks below: verify with `jj status` and `jj log -r '::@' -n 5`, create isolation with `jj workspace add ../<task-slug> -r @`, then run `jj -R ../<task-slug> describe -m "feat: <task>"`. Record the new stable change ID. For `git`, continue below.
+
+### 2a. Anchor Git on the default branch (main or master)
+
+> **HARD GATE** — Git kickoff MUST start from an updated, clean default branch in the **primary** repository root (not a linked worktree).
 
 ```bash
 # Detect default branch
@@ -63,7 +68,7 @@ fi
 - **Non-spec dirty files** (src/, scripts/, SKILL.md, …) still enforce the full clean-tree gate.
 - If not on `$DEFAULT` after checkout, stop and fix before continuing.
 
-### 3. Pre-flight & Conflict Resolution
+### 3. Git pre-flight & conflict resolution
 
 Before creating the worktree, verify the target environment is clean:
 
@@ -83,7 +88,7 @@ git worktree list | grep "<task-slug>"
 - **Branch exists:** If the branch exists but no worktree is attached, ask to use the existing branch (`git worktree add ../<task-slug> <task-slug>`) or delete it.
 - **Ghost worktree:** If `git worktree list` shows the path but the directory is missing, run `git worktree prune` to clear the stale metadata. `bash scripts/cleanup-worktrees.sh` does this plus reports any worktree whose branch is already merged or deleted — advisory only, it prints the `git worktree remove`/`git branch -d` commands rather than running them, so review before acting.
 
-### 4. Create worktree + branch
+### 4. Create Git worktree + branch
 
 ```bash
 # From the main repo root (not another worktree)

package/.opencode/skills/release-branch/SKILL.md

@@ -8,6 +8,7 @@ description: "Make the merge/PR/keep/discard decision for a feature branch, veri
 <!-- story: e45s15 -->
 <!-- story: e45s32 -->
 <!-- story: e45s39 -->
+<!-- story: e82s02 -->
 <!-- story: e20s02 -->
 
 
@@ -30,7 +31,7 @@ Read `specs/state.yaml` key `workflow_mode` (`team-pr` | `solo-git`). Fall back
 | **solo-local** | `workflow_mode: solo-git` | Auto: `scripts/land-branch.sh` if present, else fallback (Step 5) |
 | **team-pr** | `workflow_mode: team-pr` (default) | `gh pr create` → `gh pr merge --squash` |
 
-If unsure, prefer **solo-local**.
+If unsure, prefer **solo-local**. Also read `state.yaml` `vcs.kind`: Git follows the procedures below; Jujutsu uses workspaces/bookmarks and must not call Git-only landing scripts.
 
 ## Process
 
@@ -73,16 +74,21 @@ Run `gate-trace` before merge. FAIL blocks merge; CONCERNS requires explicit ove
 
 Options: **Release (solo-local)** / **Open PR** / **Keep branch** / **Discard**
 
-### 5. Solo-local integrate
+### 5. Integrate
 
-Run `commit-message` for the squash subject, then land:
+Run `commit-message` first. Git solo-local uses `land-branch.sh`. Jujutsu team mode explicitly advances and pushes a bookmark; `-m` is mandatory for commit/describe operations:
 
 ```bash
-# Path A (preferred):
+# Git solo-local
 bash scripts/land-branch.sh <task-slug> "feat(scope): description"
-# Path B (fallback if land-branch.sh missing): see REFERENCE.md
+# Jujutsu team PR
+jj describe -m "feat(scope): description"
+jj bookmark set <task-slug> -r @
+jj git push -b <task-slug>
 ```
 
+Jujutsu solo-local landing is unsupported: run `bp_require_vcs_operation "$PWD" land-branch` and stop with its remediation instead of invoking the Git backend.
+
 ### 6. Create PR (team-pr only)
 
 Create the pull request with a **literal provenance marker** in the body so agent-generated PRs are identifiable and do not rot silently:
@@ -131,7 +137,7 @@ bash scripts/wait-for-ci.sh --timeout 600 --interval 30
 
 ### 8. Clean up & return
 
-Worktree prune, branch delete, `git checkout main`. Cycle-time: see [REFERENCE.md](REFERENCE.md#cycle-time).
+Git: prune worktree, delete branch, return to main. Jujutsu: `jj workspace forget <workspace>` only after integration; do not delete its bookmark implicitly. Cycle-time: see [REFERENCE.md](REFERENCE.md#cycle-time).
 
 Report: "Branch released."
 

package/.opencode/skills/survey-context/SKILL.md

@@ -4,6 +4,8 @@ model: haiku
 description: "Per-task context bootstrap — reads existing specs/ and tech-architecture docs to map the current lifecycle phase and suggest the next skill. Use at the start of any task, when returning after a break, or when unsure what to do next. For deriving a tech-stack doc from scratch, use map-codebase first."
 ---
 
+# story: e82s02
+
 # Survey Context
 
 Read the project's current state and give a phase map + next-skill recommendation. This is the "where am I?" skill — run it at the start of every task.
@@ -51,15 +53,18 @@ Legacy markdown (`specs/archive/STATE.md`, `RELEASE-PLAN.md`) is **not** SoT if
 
 If `CLAUDE.md` exists at the project root, read it for project context (stack, commands, architecture, conventions).
 
-### 4. Check git state
+### 4. Check VCS state
+
+Read `state.yaml` `vcs.kind` (or resolve `auto`). Use native identity:
 
 ```bash
-git status --short
-git log --oneline -5
-git branch --show-current
+# Git
+git status --short; git log --oneline -5; git branch --show-current
+# Jujutsu
+jj status; jj log -r 'mine() & ::@' -n 5
 ```
 
-Note: is there a feature branch active? Are there uncommitted changes? Do they match `specs/state.yaml` `git` block?
+For Jujutsu, compare stable change IDs and bookmarks with the `vcs` block; never interpret colocated Git's detached HEAD as branch state.
 
 ### 5. Map the lifecycle phase
 
@@ -124,7 +129,7 @@ Loop through all `specs/epics/*/epic.yaml` files and print a summary of story co
 
 ### check-gates (absorbed)
 
-Print the current `active_flow` from `specs/state.yaml`, run `bash scripts/validate-specs-yaml.sh` to verify YAML integrity, and show `git status` to report uncommitted changes and branch state. Use before handoffs or context transitions.
+Print `active_flow`, validate YAML, then show `git status` or `jj status` according to `vcs.kind`. Use before handoffs or context transitions.
 
 ## Handoff
 

package/.pi/package.json

@@ -1,6 +1,6 @@
 {
   "name": "bigpowers",
-  "version": "2.87.8",
+  "version": "2.88.1",
   "description": "81 skills — 73 agent skills synthesizing 17 years of software engineering discipline into a prescriptive methodology for solo developers",
   "keywords": [
     "pi-package"

package/.pi/prompts/commit-message.md

@@ -3,6 +3,8 @@ name: commit-message
 description: "Reviews working-tree changes, then drafts a Conventional Commits title/body and states the semantic-release version bump a single such commit would imply. Also notes which defensive-code categories were touched. Use when the user wants to commit recent work, prepare a Conventional Commits message, or asks for semantic-release / semver-consistent messaging before git commit."
 ---
 
+# story: e82s02
+
 # Commit Message
 > **HARD GATE** — **HARD GATE** — Commits must follow Conventional Commits spec (type(scope): description). Do NOT use vague messages like 'fix' or 'updates.' The message must explain the 'why,' not the 'what.'
 
@@ -14,7 +16,7 @@ description: "Reviews working-tree changes, then drafts a Conventional Commits t
 
 ## What "last chat" means
 
-- **Primary source of truth:** `git status`, `git diff` (unstaged), and `git diff --cached` (staged). Run these in the repo root (or the paths the user changed).
+- **Primary source of truth:** Read `state.yaml` `vcs.kind`. Git uses `git status`, `git diff`, and `git diff --cached`; Jujutsu uses `jj status`, `jj diff`, and `jj log -r @`. Run in the repo root.
 - **Context:** use the current conversation to summarize *intent* and to spot **breaking** API/behavior changes that diff alone may not show.
 - If the user tracks a session baseline (e.g. branch, tag, or `git stash create` at start), you may `git diff <baseline>..HEAD` plus uncommitted diffs; otherwise use only the index and working tree.
 
@@ -29,7 +31,7 @@ description: "Reviews working-tree changes, then drafts a Conventional Commits t
 7. **Deliver** — Output:
    - Proposed **full commit message** (title + optional body + footers).
    - **Release bump** this commit would drive: `patch` | `minor` | `major` | `none`.
-   - Optional `git add …` and `git commit -m` instructions; do **not** run destructive git commands unless the user asked.
+   - Optional native command: Git `git commit -m`; Jujutsu `jj commit -m`. Never omit `-m` or run destructive commands unless asked.
 
 ## Checklist before finalizing
 

package/.pi/prompts/kickoff-branch.md

@@ -1,19 +1,20 @@
 ---
 name: kickoff-branch
-description: "Create a git worktree and feature branch, then verify a clean test baseline before any code is written. Use when starting a new feature or task, when user wants to work in isolation from main, or mentions \"start a branch\" or \"new worktree\"."
+description: "Create an isolated Git worktree/branch or Jujutsu workspace, then verify a clean test baseline before code. Use when starting a feature or task."
 ---
 
 # story: e51s03
 # story: e20s03
+# story: e82s02
 
 
 # Kickoff Branch
 
-> **HARD GATE** — Direct work on `main` or `master` is PROHIBITED. Every task MUST start with this skill to create a feature branch or worktree.
+> **HARD GATE** — Direct Git work on `main`/`master` or reuse of an unrelated Jujutsu change is prohibited. Create a feature branch/worktree or Jujutsu workspace/change.
 >
 > **HARD GATE** — Do NOT proceed with development until **Preflight** passes on the default branch. Red Preflight blocks branch creation and all forward work — invoke `quick-fix` or `fix-bug` per CONVENTIONS § Discovered Defects.
 
-Create an isolated working environment before touching any code. **Preflight must be green** before you write feature code — solo-default owns the whole tree, not just the current task diff.
+Create an isolated Git worktree or Jujutsu workspace before code. **Preflight must be green** first — solo-default owns the whole tree.
 
 ## Process
 
@@ -21,9 +22,13 @@ Create an isolated working environment before touching any code. **Preflight mus
 
 Ask if not already known: "What's the name of this feature or task?" Use it as the branch name slug (kebab-case, max 40 chars).
 
-### 2. Anchor on default branch (main or master)
+### 2. Select the VCS procedure
 
-> **HARD GATE** — Kickoff MUST start from an updated, clean default branch in the **primary** repository root (not a linked worktree).
+Read `state.yaml` `vcs.kind`. For `jj`, do not run the Git blocks below: verify with `jj status` and `jj log -r '::@' -n 5`, create isolation with `jj workspace add ../<task-slug> -r @`, then run `jj -R ../<task-slug> describe -m "feat: <task>"`. Record the new stable change ID. For `git`, continue below.
+
+### 2a. Anchor Git on the default branch (main or master)
+
+> **HARD GATE** — Git kickoff MUST start from an updated, clean default branch in the **primary** repository root (not a linked worktree).
 
 ```bash
 # Detect default branch
@@ -62,7 +67,7 @@ fi
 - **Non-spec dirty files** (src/, scripts/, SKILL.md, …) still enforce the full clean-tree gate.
 - If not on `$DEFAULT` after checkout, stop and fix before continuing.
 
-### 3. Pre-flight & Conflict Resolution
+### 3. Git pre-flight & conflict resolution
 
 Before creating the worktree, verify the target environment is clean:
 
@@ -82,7 +87,7 @@ git worktree list | grep "<task-slug>"
 - **Branch exists:** If the branch exists but no worktree is attached, ask to use the existing branch (`git worktree add ../<task-slug> <task-slug>`) or delete it.
 - **Ghost worktree:** If `git worktree list` shows the path but the directory is missing, run `git worktree prune` to clear the stale metadata. `bash scripts/cleanup-worktrees.sh` does this plus reports any worktree whose branch is already merged or deleted — advisory only, it prints the `git worktree remove`/`git branch -d` commands rather than running them, so review before acting.
 
-### 4. Create worktree + branch
+### 4. Create Git worktree + branch
 
 ```bash
 # From the main repo root (not another worktree)

package/.pi/prompts/release-branch.md

@@ -7,6 +7,7 @@ description: "Make the merge/PR/keep/discard decision for a feature branch, veri
 <!-- story: e45s15 -->
 <!-- story: e45s32 -->
 <!-- story: e45s39 -->
+<!-- story: e82s02 -->
 <!-- story: e20s02 -->
 
 
@@ -29,7 +30,7 @@ Read `specs/state.yaml` key `workflow_mode` (`team-pr` | `solo-git`). Fall back
 | **solo-local** | `workflow_mode: solo-git` | Auto: `scripts/land-branch.sh` if present, else fallback (Step 5) |
 | **team-pr** | `workflow_mode: team-pr` (default) | `gh pr create` → `gh pr merge --squash` |
 
-If unsure, prefer **solo-local**.
+If unsure, prefer **solo-local**. Also read `state.yaml` `vcs.kind`: Git follows the procedures below; Jujutsu uses workspaces/bookmarks and must not call Git-only landing scripts.
 
 ## Process
 
@@ -72,16 +73,21 @@ Run `gate-trace` before merge. FAIL blocks merge; CONCERNS requires explicit ove
 
 Options: **Release (solo-local)** / **Open PR** / **Keep branch** / **Discard**
 
-### 5. Solo-local integrate
+### 5. Integrate
 
-Run `commit-message` for the squash subject, then land:
+Run `commit-message` first. Git solo-local uses `land-branch.sh`. Jujutsu team mode explicitly advances and pushes a bookmark; `-m` is mandatory for commit/describe operations:
 
 ```bash
-# Path A (preferred):
+# Git solo-local
 bash scripts/land-branch.sh <task-slug> "feat(scope): description"
-# Path B (fallback if land-branch.sh missing): see REFERENCE.md
+# Jujutsu team PR
+jj describe -m "feat(scope): description"
+jj bookmark set <task-slug> -r @
+jj git push -b <task-slug>
 ```
 
+Jujutsu solo-local landing is unsupported: run `bp_require_vcs_operation "$PWD" land-branch` and stop with its remediation instead of invoking the Git backend.
+
 ### 6. Create PR (team-pr only)
 
 Create the pull request with a **literal provenance marker** in the body so agent-generated PRs are identifiable and do not rot silently:
@@ -130,7 +136,7 @@ bash scripts/wait-for-ci.sh --timeout 600 --interval 30
 
 ### 8. Clean up & return
 
-Worktree prune, branch delete, `git checkout main`. Cycle-time: see [REFERENCE.md](REFERENCE.md#cycle-time).
+Git: prune worktree, delete branch, return to main. Jujutsu: `jj workspace forget <workspace>` only after integration; do not delete its bookmark implicitly. Cycle-time: see [REFERENCE.md](REFERENCE.md#cycle-time).
 
 Report: "Branch released."
 

package/.pi/prompts/survey-context.md

@@ -3,6 +3,8 @@ name: survey-context
 description: "Per-task context bootstrap — reads existing specs/ and tech-architecture docs to map the current lifecycle phase and suggest the next skill. Use at the start of any task, when returning after a break, or when unsure what to do next. For deriving a tech-stack doc from scratch, use map-codebase first."
 ---
 
+# story: e82s02
+
 # Survey Context
 
 Read the project's current state and give a phase map + next-skill recommendation. This is the "where am I?" skill — run it at the start of every task.
@@ -50,15 +52,18 @@ Legacy markdown (`specs/archive/STATE.md`, `RELEASE-PLAN.md`) is **not** SoT if
 
 If `CLAUDE.md` exists at the project root, read it for project context (stack, commands, architecture, conventions).
 
-### 4. Check git state
+### 4. Check VCS state
+
+Read `state.yaml` `vcs.kind` (or resolve `auto`). Use native identity:
 
 ```bash
-git status --short
-git log --oneline -5
-git branch --show-current
+# Git
+git status --short; git log --oneline -5; git branch --show-current
+# Jujutsu
+jj status; jj log -r 'mine() & ::@' -n 5
 ```
 
-Note: is there a feature branch active? Are there uncommitted changes? Do they match `specs/state.yaml` `git` block?
+For Jujutsu, compare stable change IDs and bookmarks with the `vcs` block; never interpret colocated Git's detached HEAD as branch state.
 
 ### 5. Map the lifecycle phase
 
@@ -123,7 +128,7 @@ Loop through all `specs/epics/*/epic.yaml` files and print a summary of story co
 
 ### check-gates (absorbed)
 
-Print the current `active_flow` from `specs/state.yaml`, run `bash scripts/validate-specs-yaml.sh` to verify YAML integrity, and show `git status` to report uncommitted changes and branch state. Use before handoffs or context transitions.
+Print `active_flow`, validate YAML, then show `git status` or `jj status` according to `vcs.kind`. Use before handoffs or context transitions.
 
 ## Handoff
 

package/.pi/skills/commit-message/SKILL.md

@@ -4,6 +4,8 @@ model: haiku
 description: "Reviews working-tree changes, then drafts a Conventional Commits title/body and states the semantic-release version bump a single such commit would imply. Also notes which defensive-code categories were touched. Use when the user wants to commit recent work, prepare a Conventional Commits message, or asks for semantic-release / semver-consistent messaging before git commit."
 ---
 
+# story: e82s02
+
 # Commit Message
 > **HARD GATE** — **HARD GATE** — Commits must follow Conventional Commits spec (type(scope): description). Do NOT use vague messages like 'fix' or 'updates.' The message must explain the 'why,' not the 'what.'
 
@@ -15,7 +17,7 @@ description: "Reviews working-tree changes, then drafts a Conventional Commits t
 
 ## What "last chat" means
 
-- **Primary source of truth:** `git status`, `git diff` (unstaged), and `git diff --cached` (staged). Run these in the repo root (or the paths the user changed).
+- **Primary source of truth:** Read `state.yaml` `vcs.kind`. Git uses `git status`, `git diff`, and `git diff --cached`; Jujutsu uses `jj status`, `jj diff`, and `jj log -r @`. Run in the repo root.
 - **Context:** use the current conversation to summarize *intent* and to spot **breaking** API/behavior changes that diff alone may not show.
 - If the user tracks a session baseline (e.g. branch, tag, or `git stash create` at start), you may `git diff <baseline>..HEAD` plus uncommitted diffs; otherwise use only the index and working tree.
 
@@ -30,7 +32,7 @@ description: "Reviews working-tree changes, then drafts a Conventional Commits t
 7. **Deliver** — Output:
    - Proposed **full commit message** (title + optional body + footers).
    - **Release bump** this commit would drive: `patch` | `minor` | `major` | `none`.
-   - Optional `git add …` and `git commit -m` instructions; do **not** run destructive git commands unless the user asked.
+   - Optional native command: Git `git commit -m`; Jujutsu `jj commit -m`. Never omit `-m` or run destructive commands unless asked.
 
 ## Checklist before finalizing