@ikon85/agent-workflow-kit 0.34.0 → 0.34.3

package/.agents/skills/diagnose/SKILL.md

@@ -11,6 +11,41 @@ A discipline for hard bugs. Skip phases only when explicitly justified.
 
 When exploring the codebase, read `CONTEXT.md` (if it exists) to get a clear mental model of the relevant modules, and check ADRs in the area you're touching.
 
+## Phase 0 — Claim the tracked issue
+
+Applies only when the bug arrives as a tracked issue. A bug reported in chat has
+nothing to claim; go straight to Phase 1.
+
+<!-- issue-claim:start -->
+**Claim the issue before you build.** A worktree, branch, or PR check only sees
+this machine, and only once someone has pushed — the claim on the issue itself
+is the only signal a second session, a second machine, or a cloud agent can
+read.
+
+1. **Check first.** Read the issue's assignee and its claim comments. An
+   `<!-- agent-claim: ... -->` marker you did not plant, or an assignee that is
+   not you, is a **foreign claim**: **STOP**, report the claimed branch and
+   worktree, and ask the user how to proceed. Take the issue over only on their
+   word, and never delete a foreign claim. A claim whose branch and worktree no
+   longer exist is stale — say that and let the user decide; do not assume it is
+   dead.
+2. **Plant your claim, before the first edit.** Assign the issue to yourself
+   where the tracker supports it, and post the claim marker as a comment:
+   `<!-- agent-claim: branch=<branch>; worktree=<absolute-path>; date=<YYYY-MM-DD> -->`
+   Branch and worktree are the payload — without them a colliding session sees
+   the collision but cannot find the work in progress.
+3. **Release.** A PR that references the issue **supersedes** the claim, so
+   landing needs no extra step. If you abandon or hand back the work, remove
+   your own claim (unassign plus a one-line `claim released` comment) before you
+   stop.
+
+The concrete commands are your tracker's — `docs/agents/issue-tracker.md`,
+§Pickup claim. If that layer documents no claim convention, fall back to the two
+generic operations above: self-assign, plus the marker comment.
+<!-- issue-claim:end -->
+
+Building the Phase-1 loop is already work: claim before it, not after.
+
 ## Phase 1 — Build a feedback loop
 
 **This is the skill.** Everything else is mechanical. If you have a **tight** pass/fail signal for the bug — one that goes red on _this_ bug — you will find the cause; bisection, hypothesis-testing, and instrumentation all just consume it. If you don't have one, no amount of staring at code will save you.

package/.agents/skills/implement/SKILL.md

@@ -6,6 +6,39 @@ disable-model-invocation: true
 
 Implement the work described by the user in the PRD or issues.
 
+## Pickup — claim the issue first
+
+Applies whenever the work comes from a tracked issue. Work handed over as plain
+text or a local plan has nothing to claim; skip this section then.
+
+<!-- issue-claim:start -->
+**Claim the issue before you build.** A worktree, branch, or PR check only sees
+this machine, and only once someone has pushed — the claim on the issue itself
+is the only signal a second session, a second machine, or a cloud agent can
+read.
+
+1. **Check first.** Read the issue's assignee and its claim comments. An
+   `<!-- agent-claim: ... -->` marker you did not plant, or an assignee that is
+   not you, is a **foreign claim**: **STOP**, report the claimed branch and
+   worktree, and ask the user how to proceed. Take the issue over only on their
+   word, and never delete a foreign claim. A claim whose branch and worktree no
+   longer exist is stale — say that and let the user decide; do not assume it is
+   dead.
+2. **Plant your claim, before the first edit.** Assign the issue to yourself
+   where the tracker supports it, and post the claim marker as a comment:
+   `<!-- agent-claim: branch=<branch>; worktree=<absolute-path>; date=<YYYY-MM-DD> -->`
+   Branch and worktree are the payload — without them a colliding session sees
+   the collision but cannot find the work in progress.
+3. **Release.** A PR that references the issue **supersedes** the claim, so
+   landing needs no extra step. If you abandon or hand back the work, remove
+   your own claim (unassign plus a one-line `claim released` comment) before you
+   stop.
+
+The concrete commands are your tracker's — `docs/agents/issue-tracker.md`,
+§Pickup claim. If that layer documents no claim convention, fall back to the two
+generic operations above: self-assign, plus the marker comment.
+<!-- issue-claim:end -->
+
 Use /tdd where possible, at pre-agreed seams.
 
 Run typechecking regularly, single test files regularly, and the full test suite once at the end.

package/.agents/skills/kit-release/SKILL.md

@@ -1,13 +1,14 @@
 ---
 name: kit-release
-description: "Prepare a verified release PR for agent-workflow-kit, delegate landing to wrapup, then monitor the trusted post-merge publishing flow through npm/GitHub parity."
+description: "Prepare and integrate a verified agent-workflow-kit release, then record separately confirmed publication intent with an annotated version tag and monitor npm/GitHub parity."
 ---
 
 # Kit Release
 
 Prepare a release deterministically. This skill owns the shipped-delta decision,
-metadata preparation, and verification. It does not implement commit, push, PR,
-merge, registry publishing, tags, or release creation.
+metadata preparation, verification, and the separate post-merge publication
+gate. It delegates commit, branch push, PR, merge, and cleanup to wrapup. It
+never publishes to a registry or creates a GitHub release directly.
 
 ## Workflow
 
@@ -22,11 +23,20 @@ merge, registry publishing, tags, or release creation.
    recommend Major, additions recommend Minor, and changed content recommends
    Patch.
 
-2. Ask the user to confirm exactly one target Semver. Do not change release
-   metadata before confirmation. A recommendation is advice; the confirmed
-   target is authority.
+2. Resolve authority for exactly one target Semver:
 
-3. Prepare that exact version:
+   - Normally, ask the user to confirm the target before changing release
+     metadata. A recommendation is advice; the confirmed target is authority.
+   - When the caller carries an **explicit AFK end-to-end mandate** whose scope
+     includes release preparation, accept the deterministic recommendation as
+     the target for **reversible metadata preparation** and record that choice.
+     Do not turn a narrower build-only or single-action request into this
+     authority.
+
+   Both routes authorize one prepared target only. Neither authorizes
+   publication.
+
+3. Prepare that authorized exact version:
 
    ```sh
    npm run release:prepare -- --version <confirmed-version>
@@ -42,7 +52,21 @@ merge, registry publishing, tags, or release creation.
    `scripts/wrapup-land.py` exclusively own commit, push, PR creation, merge,
    and cleanup. Do not reproduce those operations here.
 
-5. After merge, monitor the `release.yml` workflow and inspect its externally
+5. After merge, report the exact integrated version and commit as
+   `awaiting-tag`. Merging integrates the prepared release; it cannot start
+   publication. Creating and pushing the annotated `v<version>` tag requires a
+   **separate explicit confirmation** to publish that exact version. The
+   earlier Semver confirmation or AFK preparation mandate authorized metadata
+   preparation, not publication.
+
+6. After that confirmation, verify that the package version on current
+   `origin/main` is exactly `<version>`. Create a matching annotated
+   `v<version>` tag on that commit and push only that tag. A lightweight tag,
+   mismatching version, or commit outside canonical `main` is invalid release
+   intent. Never infer a tag target, move an existing tag, or tag an unmerged
+   commit.
+
+7. Monitor the tag-triggered `release.yml` workflow and inspect its externally
    reconstructable state:
 
    ```sh
@@ -56,6 +80,17 @@ merge, registry publishing, tags, or release creation.
    release asset have identical version, manifest hash, and tarball integrity.
    The release is complete only at `released`.
 
+   Manual dispatch is recovery only. It requires the explicit existing
+   annotated tag and runs the same idempotent reconciler:
+
+   ```sh
+   gh workflow run release.yml -f tag=v<version>
+   ```
+
+   Use it only after reconstructing the release state for that tag. Never use
+   dispatch as the normal publication route or substitute a new version for a
+   partial release.
+
    The registry identity is **`@ikon85/agent-workflow-kit`**. The unscoped
    `agent-workflow-kit` package is owned by another publisher and must never be
    queried, published, or treated as this repository's release.

package/.agents/skills/orchestrate-wave/SKILL.md

@@ -62,6 +62,16 @@ node scripts/readiness.mjs check --skill orchestrate-wave --json
   change — current gate, last green milestone, next step, visible blocker/risk. A
   still-running tool session is stated as such; never wait silently for the final
   result.
+- **Authorization scope is sticky and gates are local.** A single-Wave mandate
+  authorizes only that Wave. A later explicit whole-Program mandate authorizes all
+  planned Waves in that Program and overrides a default per-Wave authorization
+  sentence in the Program-PRD; record that scope once and **Do not re-ask at each
+  Wave boundary**. A manual or irreversible gate pauses only the gated action:
+  continue every dependency-safe reversible or read-only step inside the
+  authorized scope, including preparation for later Waves. A persistent goal
+  must not be marked `blocked` while meaningful authorized safe work remains
+  anywhere in that scope. None of this carries authorization into the gated
+  irreversible action itself.
 - **Degrade by subtraction, never by improvisation.** The defined failure paths:
   - **Slice stays red after escalation** (2-strikes rule, see Routing): pull the
     slice — do not merge it (or revert its merge), pull every dependent that
@@ -180,6 +190,14 @@ Before each slice, bind **(a) inline vs delegate** and **(b) tier + effort** und
 Standing rules. Tiny mechanical work may stay inline.
 For Path A/B, create one worktree per agent from wave HEAD, using `§Setup` or
 `git worktree add <path> -b feat/<anchor>-<slug>`.
+- **Claim each slice issue at builder launch — the wave claim is not a slice
+  claim.** It guards the anchor on this machine only; the slice issue is the
+  grabbable unit a second machine or cloud agent sees. Before dispatch, skip and
+  report any slice already carrying a foreign claim (assignee or
+  `<!-- agent-claim: ... -->` comment this run did not plant) — never overwrite
+  one. Otherwise assign it to yourself and post
+  `<!-- agent-claim: branch=<slice-branch>; worktree=<builder-worktree>; date=<YYYY-MM-DD> -->`
+  so the claim names the WIP. Commands: `docs/agents/issue-tracker.md`, §Pickup claim.
 - **Build the prompt from [`references/builder-contract.md`](references/builder-contract.md)**
   — fill the slots with the slice's VERBATIM What+AC, plan decision, recon
   file:line map and consume-only lines; never paraphrase (paraphrase drift has
@@ -190,7 +208,8 @@ For Path A/B, create one worktree per agent from wave HEAD, using `§Setup` or
 
 **Done when:** every dispatched slice reported back with commit SHA + green
 package tests + green fast gate (`§Builder Commands`) — or a STOP item you resolved
-(answered / re-dispatched) before integration.
+(answered / re-dispatched) before integration · every dispatched slice issue
+carries this run's claim, every foreign-claimed slice skipped and reported.
 
 ## Phase 3 — Serial integration
 
@@ -302,6 +321,9 @@ written · merge order documented.
   `wave-active/<anchor>`, call `releaseWaveClaim` with this run's owner after
   success or abort; its owner check, not a broad `wave-active/*` pattern,
   authorizes cleanup, and a foreign marker is left untouched.
+- **Release this run's slice claims.** A landed slice's PR supersedes its claim;
+  for a pulled or abandoned slice remove the claim this run planted (unassign +
+  `claim released` comment) so it stays grabbable. Foreign ones stay untouched.
 - **Before removing any slice worktree, read its `ANNAHMEN.md`** (an assumptions
   log, gitignored at worktree-root) and propagate each build-time assumption marker
   to the sibling issue it carries. A hand-driven multi-PR / migration landing does
@@ -331,7 +353,8 @@ written · merge order documented.
 - Leave slice worktrees for the user to inspect, or note they're
   post-merge-removable.
 
-**Done when:** no orphan process · this run's claim removed · ANNAHMEN propagated ·
+**Done when:** no orphan process · this run's wave claim removed · this run's
+unlanded slice claims released · ANNAHMEN propagated ·
 anchor reconciled + leaf closes verified · anchor closure decided and documented ·
 Program-PRD propagation completed or explicitly skipped · final report lists
 landed/pulled slices as **X of Y**.

package/.agents/skills/setup-workflow/issue-tracker-github.md

@@ -23,6 +23,17 @@ Create a GitHub issue.
 
 Run `gh issue view <number> --comments`.
 
+## Pickup claim
+
+Used by `/implement`, `/diagnose`, and `/orchestrate-wave`: the visible claim
+that keeps a second session, machine, or cloud agent off an issue already being
+built. The marker carries the WIP location, the assignee makes the claim visible
+in list views.
+
+- **Check** (before any edit): `gh issue view <n> --json assignees,comments --jq '{assignees: [.assignees[].login], claims: [.comments[].body | select(contains("<!-- agent-claim:"))]}'` — a foreign assignee or a marker this session did not plant is a foreign claim: stop and report it, never overwrite or delete it.
+- **Claim**: `gh issue edit <n> --add-assignee @me`, then post the marker as a comment — `gh issue comment <n> --body '<!-- agent-claim: branch=<branch>; worktree=<absolute-path>; date=<YYYY-MM-DD> -->'`.
+- **Release**: a PR referencing the issue supersedes the claim — no extra step when the work lands. On abandon: `gh issue edit <n> --remove-assignee @me` plus `gh issue comment <n> --body "claim released"`.
+
 ## Wayfinding operations
 
 Used by `/wayfinder`. The **map** is a single issue with **child** issues as tickets.

package/.agents/skills/setup-workflow/issue-tracker-gitlab.md

@@ -22,6 +22,17 @@ Create a GitLab issue.
 
 Run `glab issue view <number> --comments`.
 
+## Pickup claim
+
+Used by `/implement`, `/diagnose`, and `/orchestrate-wave`: the visible claim
+that keeps a second session, machine, or cloud agent off an issue already being
+built. The marker carries the WIP location, the assignee makes the claim visible
+in list views.
+
+- **Check** (before any edit): `glab issue view <n> --comments` (or `-F json`) — a foreign assignee, or an `<!-- agent-claim: ... -->` note this session did not plant, is a foreign claim: stop and report it, never overwrite or delete it.
+- **Claim**: `glab issue update <n> --assignee @me`, then post the marker as a note — `glab issue note <n> --message '<!-- agent-claim: branch=<branch>; worktree=<absolute-path>; date=<YYYY-MM-DD> -->'`.
+- **Release**: a merge request referencing the issue supersedes the claim — no extra step when the work lands. On abandon, drop yourself with the `/unassign @<your-user>` quick action (`glab issue note <n> --message "/unassign @<your-user>"`) and post a `claim released` note.
+
 ## Wayfinding operations
 
 Used by `/wayfinder`. The **map** is a single issue with **child** issues as tickets.

package/.agents/skills/setup-workflow/issue-tracker-local.md

@@ -18,6 +18,17 @@ Create a new file under `.scratch/<feature-slug>/` (creating the directory if ne
 
 Read the file at the referenced path. The user will normally pass the path or the issue number directly.
 
+## Pickup claim
+
+Used by `/implement`, `/diagnose`, and `/orchestrate-wave`: the visible claim
+that keeps a second session, machine, or cloud agent off an issue already being
+built. There is no assignee field here, so the marker line carries the whole
+claim — commit it, otherwise no other checkout can see it.
+
+- **Check** (before any edit): read the issue file and grep it for `<!-- agent-claim:`. A marker this session did not plant is a foreign claim: stop and report it, never overwrite or delete it.
+- **Claim**: set `Status: claimed` and add one marker line directly under it — `<!-- agent-claim: branch=<branch>; worktree=<absolute-path>; date=<YYYY-MM-DD> -->` — then commit and push the issue file so other checkouts see the claim.
+- **Release**: a PR referencing the issue supersedes the claim. On abandon, delete your own marker line, reset `Status:` to its pre-pickup role, and commit.
+
 ## Wayfinding operations
 
 Used by `/wayfinder`. The **map** is a file with one **child** file per ticket.

package/.claude/skills/diagnose/SKILL.md

@@ -11,6 +11,41 @@ A discipline for hard bugs. Skip phases only when explicitly justified.
 
 When exploring the codebase, read `CONTEXT.md` (if it exists) to get a clear mental model of the relevant modules, and check ADRs in the area you're touching.
 
+## Phase 0 — Claim the tracked issue
+
+Applies only when the bug arrives as a tracked issue. A bug reported in chat has
+nothing to claim; go straight to Phase 1.
+
+<!-- issue-claim:start -->
+**Claim the issue before you build.** A worktree, branch, or PR check only sees
+this machine, and only once someone has pushed — the claim on the issue itself
+is the only signal a second session, a second machine, or a cloud agent can
+read.
+
+1. **Check first.** Read the issue's assignee and its claim comments. An
+   `<!-- agent-claim: ... -->` marker you did not plant, or an assignee that is
+   not you, is a **foreign claim**: **STOP**, report the claimed branch and
+   worktree, and ask the user how to proceed. Take the issue over only on their
+   word, and never delete a foreign claim. A claim whose branch and worktree no
+   longer exist is stale — say that and let the user decide; do not assume it is
+   dead.
+2. **Plant your claim, before the first edit.** Assign the issue to yourself
+   where the tracker supports it, and post the claim marker as a comment:
+   `<!-- agent-claim: branch=<branch>; worktree=<absolute-path>; date=<YYYY-MM-DD> -->`
+   Branch and worktree are the payload — without them a colliding session sees
+   the collision but cannot find the work in progress.
+3. **Release.** A PR that references the issue **supersedes** the claim, so
+   landing needs no extra step. If you abandon or hand back the work, remove
+   your own claim (unassign plus a one-line `claim released` comment) before you
+   stop.
+
+The concrete commands are your tracker's — `docs/agents/issue-tracker.md`,
+§Pickup claim. If that layer documents no claim convention, fall back to the two
+generic operations above: self-assign, plus the marker comment.
+<!-- issue-claim:end -->
+
+Building the Phase-1 loop is already work: claim before it, not after.
+
 ## Phase 1 — Build a feedback loop
 
 **This is the skill.** Everything else is mechanical. If you have a **tight** pass/fail signal for the bug — one that goes red on _this_ bug — you will find the cause; bisection, hypothesis-testing, and instrumentation all just consume it. If you don't have one, no amount of staring at code will save you.

package/.claude/skills/implement/SKILL.md

@@ -6,6 +6,39 @@ disable-model-invocation: true
 
 Implement the work described by the user in the PRD or issues.
 
+## Pickup — claim the issue first
+
+Applies whenever the work comes from a tracked issue. Work handed over as plain
+text or a local plan has nothing to claim; skip this section then.
+
+<!-- issue-claim:start -->
+**Claim the issue before you build.** A worktree, branch, or PR check only sees
+this machine, and only once someone has pushed — the claim on the issue itself
+is the only signal a second session, a second machine, or a cloud agent can
+read.
+
+1. **Check first.** Read the issue's assignee and its claim comments. An
+   `<!-- agent-claim: ... -->` marker you did not plant, or an assignee that is
+   not you, is a **foreign claim**: **STOP**, report the claimed branch and
+   worktree, and ask the user how to proceed. Take the issue over only on their
+   word, and never delete a foreign claim. A claim whose branch and worktree no
+   longer exist is stale — say that and let the user decide; do not assume it is
+   dead.
+2. **Plant your claim, before the first edit.** Assign the issue to yourself
+   where the tracker supports it, and post the claim marker as a comment:
+   `<!-- agent-claim: branch=<branch>; worktree=<absolute-path>; date=<YYYY-MM-DD> -->`
+   Branch and worktree are the payload — without them a colliding session sees
+   the collision but cannot find the work in progress.
+3. **Release.** A PR that references the issue **supersedes** the claim, so
+   landing needs no extra step. If you abandon or hand back the work, remove
+   your own claim (unassign plus a one-line `claim released` comment) before you
+   stop.
+
+The concrete commands are your tracker's — `docs/agents/issue-tracker.md`,
+§Pickup claim. If that layer documents no claim convention, fall back to the two
+generic operations above: self-assign, plus the marker comment.
+<!-- issue-claim:end -->
+
 Use /tdd where possible, at pre-agreed seams.
 
 Run typechecking regularly, single test files regularly, and the full test suite once at the end.

package/.claude/skills/kit-release/SKILL.md

@@ -1,13 +1,14 @@
 ---
 name: kit-release
-description: "Prepare a verified release PR for agent-workflow-kit, delegate landing to wrapup, then monitor the trusted post-merge publishing flow through npm/GitHub parity."
+description: "Prepare and integrate a verified agent-workflow-kit release, then record separately confirmed publication intent with an annotated version tag and monitor npm/GitHub parity."
 ---
 
 # Kit Release
 
 Prepare a release deterministically. This skill owns the shipped-delta decision,
-metadata preparation, and verification. It does not implement commit, push, PR,
-merge, registry publishing, tags, or release creation.
+metadata preparation, verification, and the separate post-merge publication
+gate. It delegates commit, branch push, PR, merge, and cleanup to wrapup. It
+never publishes to a registry or creates a GitHub release directly.
 
 ## Workflow
 
@@ -22,11 +23,20 @@ merge, registry publishing, tags, or release creation.
    recommend Major, additions recommend Minor, and changed content recommends
    Patch.
 
-2. Ask the user to confirm exactly one target Semver. Do not change release
-   metadata before confirmation. A recommendation is advice; the confirmed
-   target is authority.
+2. Resolve authority for exactly one target Semver:
 
-3. Prepare that exact version:
+   - Normally, ask the user to confirm the target before changing release
+     metadata. A recommendation is advice; the confirmed target is authority.
+   - When the caller carries an **explicit AFK end-to-end mandate** whose scope
+     includes release preparation, accept the deterministic recommendation as
+     the target for **reversible metadata preparation** and record that choice.
+     Do not turn a narrower build-only or single-action request into this
+     authority.
+
+   Both routes authorize one prepared target only. Neither authorizes
+   publication.
+
+3. Prepare that authorized exact version:
 
    ```sh
    npm run release:prepare -- --version <confirmed-version>
@@ -42,7 +52,21 @@ merge, registry publishing, tags, or release creation.
    `scripts/wrapup-land.py` exclusively own commit, push, PR creation, merge,
    and cleanup. Do not reproduce those operations here.
 
-5. After merge, monitor the `release.yml` workflow and inspect its externally
+5. After merge, report the exact integrated version and commit as
+   `awaiting-tag`. Merging integrates the prepared release; it cannot start
+   publication. Creating and pushing the annotated `v<version>` tag requires a
+   **separate explicit confirmation** to publish that exact version. The
+   earlier Semver confirmation or AFK preparation mandate authorized metadata
+   preparation, not publication.
+
+6. After that confirmation, verify that the package version on current
+   `origin/main` is exactly `<version>`. Create a matching annotated
+   `v<version>` tag on that commit and push only that tag. A lightweight tag,
+   mismatching version, or commit outside canonical `main` is invalid release
+   intent. Never infer a tag target, move an existing tag, or tag an unmerged
+   commit.
+
+7. Monitor the tag-triggered `release.yml` workflow and inspect its externally
    reconstructable state:
 
    ```sh
@@ -56,6 +80,17 @@ merge, registry publishing, tags, or release creation.
    release asset have identical version, manifest hash, and tarball integrity.
    The release is complete only at `released`.
 
+   Manual dispatch is recovery only. It requires the explicit existing
+   annotated tag and runs the same idempotent reconciler:
+
+   ```sh
+   gh workflow run release.yml -f tag=v<version>
+   ```
+
+   Use it only after reconstructing the release state for that tag. Never use
+   dispatch as the normal publication route or substitute a new version for a
+   partial release.
+
    The registry identity is **`@ikon85/agent-workflow-kit`**. The unscoped
    `agent-workflow-kit` package is owned by another publisher and must never be
    queried, published, or treated as this repository's release.

package/.claude/skills/orchestrate-wave/SKILL.md

@@ -70,6 +70,16 @@ node scripts/readiness.mjs check --skill orchestrate-wave --json
   change — current gate, last green milestone, next step, visible blocker/risk. A
   still-running tool session is stated as such; never wait silently for the final
   result.
+- **Authorization scope is sticky and gates are local.** A single-Wave mandate
+  authorizes only that Wave. A later explicit whole-Program mandate authorizes all
+  planned Waves in that Program and overrides a default per-Wave authorization
+  sentence in the Program-PRD; record that scope once and **Do not re-ask at each
+  Wave boundary**. A manual or irreversible gate pauses only the gated action:
+  continue every dependency-safe reversible or read-only step inside the
+  authorized scope, including preparation for later Waves. A persistent goal
+  must not be marked `blocked` while meaningful authorized safe work remains
+  anywhere in that scope. None of this carries authorization into the gated
+  irreversible action itself.
 - **Degrade by subtraction, never by improvisation.** The defined failure paths:
   - **Slice stays red after escalation** (2-strikes rule, see Routing): pull the
     slice — do not merge it (or revert its merge), pull every dependent that
@@ -188,6 +198,14 @@ Before each slice, bind **(a) inline vs delegate** and **(b) tier + effort** und
 Standing rules. Tiny mechanical work may stay inline.
 For Path A/B, create one worktree per agent from wave HEAD, using `§Setup` or
 `git worktree add <path> -b feat/<anchor>-<slug>`.
+- **Claim each slice issue at builder launch — the wave claim is not a slice
+  claim.** It guards the anchor on this machine only; the slice issue is the
+  grabbable unit a second machine or cloud agent sees. Before dispatch, skip and
+  report any slice already carrying a foreign claim (assignee or
+  `<!-- agent-claim: ... -->` comment this run did not plant) — never overwrite
+  one. Otherwise assign it to yourself and post
+  `<!-- agent-claim: branch=<slice-branch>; worktree=<builder-worktree>; date=<YYYY-MM-DD> -->`
+  so the claim names the WIP. Commands: `docs/agents/issue-tracker.md`, §Pickup claim.
 - **Build the prompt from [`references/builder-contract.md`](references/builder-contract.md)**
   — fill the slots with the slice's VERBATIM What+AC, plan decision, recon
   file:line map and consume-only lines; never paraphrase (paraphrase drift has
@@ -198,7 +216,8 @@ For Path A/B, create one worktree per agent from wave HEAD, using `§Setup` or
 
 **Done when:** every dispatched slice reported back with commit SHA + green
 package tests + green fast gate (`§Builder Commands`) — or a STOP item you resolved
-(answered / re-dispatched) before integration.
+(answered / re-dispatched) before integration · every dispatched slice issue
+carries this run's claim, every foreign-claimed slice skipped and reported.
 
 ## Phase 3 — Serial integration
 
@@ -310,6 +329,9 @@ written · merge order documented.
   `wave-active/<anchor>`, call `releaseWaveClaim` with this run's owner after
   success or abort; its owner check, not a broad `wave-active/*` pattern,
   authorizes cleanup, and a foreign marker is left untouched.
+- **Release this run's slice claims.** A landed slice's PR supersedes its claim;
+  for a pulled or abandoned slice remove the claim this run planted (unassign +
+  `claim released` comment) so it stays grabbable. Foreign ones stay untouched.
 - **Before removing any slice worktree, read its `ANNAHMEN.md`** (an assumptions
   log, gitignored at worktree-root) and propagate each build-time assumption marker
   to the sibling issue it carries. A hand-driven multi-PR / migration landing does
@@ -339,7 +361,8 @@ written · merge order documented.
 - Leave slice worktrees for the user to inspect, or note they're
   post-merge-removable.
 
-**Done when:** no orphan process · this run's claim removed · ANNAHMEN propagated ·
+**Done when:** no orphan process · this run's wave claim removed · this run's
+unlanded slice claims released · ANNAHMEN propagated ·
 anchor reconciled + leaf closes verified · anchor closure decided and documented ·
 Program-PRD propagation completed or explicitly skipped · final report lists
 landed/pulled slices as **X of Y**.

package/.claude/skills/setup-workflow/issue-tracker-github.md

@@ -23,6 +23,17 @@ Create a GitHub issue.
 
 Run `gh issue view <number> --comments`.
 
+## Pickup claim
+
+Used by `/implement`, `/diagnose`, and `/orchestrate-wave`: the visible claim
+that keeps a second session, machine, or cloud agent off an issue already being
+built. The marker carries the WIP location, the assignee makes the claim visible
+in list views.
+
+- **Check** (before any edit): `gh issue view <n> --json assignees,comments --jq '{assignees: [.assignees[].login], claims: [.comments[].body | select(contains("<!-- agent-claim:"))]}'` — a foreign assignee or a marker this session did not plant is a foreign claim: stop and report it, never overwrite or delete it.
+- **Claim**: `gh issue edit <n> --add-assignee @me`, then post the marker as a comment — `gh issue comment <n> --body '<!-- agent-claim: branch=<branch>; worktree=<absolute-path>; date=<YYYY-MM-DD> -->'`.
+- **Release**: a PR referencing the issue supersedes the claim — no extra step when the work lands. On abandon: `gh issue edit <n> --remove-assignee @me` plus `gh issue comment <n> --body "claim released"`.
+
 ## Wayfinding operations
 
 Used by `/wayfinder`. The **map** is a single issue with **child** issues as tickets.

package/.claude/skills/setup-workflow/issue-tracker-gitlab.md

@@ -22,6 +22,17 @@ Create a GitLab issue.
 
 Run `glab issue view <number> --comments`.
 
+## Pickup claim
+
+Used by `/implement`, `/diagnose`, and `/orchestrate-wave`: the visible claim
+that keeps a second session, machine, or cloud agent off an issue already being
+built. The marker carries the WIP location, the assignee makes the claim visible
+in list views.
+
+- **Check** (before any edit): `glab issue view <n> --comments` (or `-F json`) — a foreign assignee, or an `<!-- agent-claim: ... -->` note this session did not plant, is a foreign claim: stop and report it, never overwrite or delete it.
+- **Claim**: `glab issue update <n> --assignee @me`, then post the marker as a note — `glab issue note <n> --message '<!-- agent-claim: branch=<branch>; worktree=<absolute-path>; date=<YYYY-MM-DD> -->'`.
+- **Release**: a merge request referencing the issue supersedes the claim — no extra step when the work lands. On abandon, drop yourself with the `/unassign @<your-user>` quick action (`glab issue note <n> --message "/unassign @<your-user>"`) and post a `claim released` note.
+
 ## Wayfinding operations
 
 Used by `/wayfinder`. The **map** is a single issue with **child** issues as tickets.

package/.claude/skills/setup-workflow/issue-tracker-local.md

@@ -18,6 +18,17 @@ Create a new file under `.scratch/<feature-slug>/` (creating the directory if ne
 
 Read the file at the referenced path. The user will normally pass the path or the issue number directly.
 
+## Pickup claim
+
+Used by `/implement`, `/diagnose`, and `/orchestrate-wave`: the visible claim
+that keeps a second session, machine, or cloud agent off an issue already being
+built. There is no assignee field here, so the marker line carries the whole
+claim — commit it, otherwise no other checkout can see it.
+
+- **Check** (before any edit): read the issue file and grep it for `<!-- agent-claim:`. A marker this session did not plant is a foreign claim: stop and report it, never overwrite or delete it.
+- **Claim**: set `Status: claimed` and add one marker line directly under it — `<!-- agent-claim: branch=<branch>; worktree=<absolute-path>; date=<YYYY-MM-DD> -->` — then commit and push the issue file so other checkouts see the claim.
+- **Release**: a PR referencing the issue supersedes the claim. On abandon, delete your own marker line, reset `Status:` to its pre-pickup role, and commit.
+
 ## Wayfinding operations
 
 Used by `/wayfinder`. The **map** is a file with one **child** file per ticket.

package/README.md

@@ -24,8 +24,10 @@ changes.
 Maintainers prepare releases with `/kit-release`. It derives the shipped delta
 from a fresh manifest, recommends Semver, applies only the confirmed target,
 regenerates the checked-in manifest, and runs the full test and pack gates.
-Landing remains owned by `/wrapup`; publishing the matching npm package and
-GitHub release happens only through the configured post-merge release flow.
+Landing remains owned by `/wrapup` and only integrates the prepared version.
+After a separate publication confirmation, a matching annotated `v<version>`
+tag on canonical `main` starts the trusted publish flow. Manual dispatch
+requires an explicit existing tag and only reconciles an incomplete release.
 
 These are the skills, helper scripts, and conventions one team actually uses to
 take work from a vague idea to a merged, verified PR with [Claude Code] and
@@ -385,6 +387,34 @@ the old way. Decision record:
 
 ## Release notes
 
+### 0.34.3
+
+- changed: `.agents/skills/diagnose/SKILL.md`
+- changed: `.agents/skills/implement/SKILL.md`
+- changed: `.agents/skills/orchestrate-wave/SKILL.md`
+- changed: `.agents/skills/setup-workflow/issue-tracker-github.md`
+- changed: `.agents/skills/setup-workflow/issue-tracker-gitlab.md`
+- changed: `.agents/skills/setup-workflow/issue-tracker-local.md`
+- changed: `.claude/skills/diagnose/SKILL.md`
+- changed: `.claude/skills/implement/SKILL.md`
+- changed: `.claude/skills/orchestrate-wave/SKILL.md`
+- changed: `.claude/skills/setup-workflow/issue-tracker-github.md`
+- changed: `.claude/skills/setup-workflow/issue-tracker-gitlab.md`
+- changed: `.claude/skills/setup-workflow/issue-tracker-local.md`
+
+### 0.34.2
+
+- changed: `.agents/skills/kit-release/SKILL.md`
+- changed: `.agents/skills/orchestrate-wave/SKILL.md`
+- changed: `.claude/skills/kit-release/SKILL.md`
+- changed: `.claude/skills/orchestrate-wave/SKILL.md`
+
+### 0.34.1
+
+- changed: `.agents/skills/kit-release/SKILL.md`
+- changed: `.claude/skills/kit-release/SKILL.md`
+- changed: `scripts/release-state.mjs`
+
 ### 0.34.0
 
 - added: `src/commands/routing-policy-update.mjs`