@joshuafolkken/kit 1.1050.0 → 1.1128.0

package/.claude/skills/workflow-commands/backlogrun-steps.md

@@ -54,7 +54,7 @@ inside the invocation" below):
 | `--max` | how many issues one invocation may merge — a run's own filing competes for that number rather than extending it | `run:carry --merged` |
 | `--idle`, and the 8-hour whole-run bound | how long one invocation may go on looking for more | the record's `started_at` |
 | **Ten filings per invocation** | how much one invocation may add to the pool at all, on **every** filing route (`SKILL.md` → §2d) | `run:carry --filed` |
-| The WIP cap of 30 open issues | how large the pool may become, across invocations | `prompts/collaboration-workflow/wip-cap.md` |
+| The WIP cap on open issues | how large the pool may become, across invocations | `prompts/collaboration-workflow/wip-cap.md` |
 
 One invocation may add at most ten issues to the pool and merge at most `--max` of them, after which
 the run ends and the next one waits for a person to type the keyword.
@@ -140,7 +140,7 @@ be answered and every standing record is refused rather than resumed. A live PID
 the sandbox cannot read is held as `busy`.
 
 **Ask it before the plan, in the same turn as the first `git switch main && git pull`.** The contract
-is `docs/josh-commands.md` → "`josh run:carry`"; what this loop does with each answer is here:
+is `docs/josh-commands-automation.md` → "`josh run:carry`"; what this loop does with each answer is here:
 
 | It answers   | What the run does                                                                                                                                                                                                          |
 | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
@@ -233,7 +233,7 @@ expired or cannot be read ends it the same way. `none` — the run having finish
 
 **A person keeps control of it.** `pnpm josh run:wake --list` names the running supervisor and
 `--stop` ends it; the full contract, what it launches and why that is a constant rather than a
-setting are `docs/josh-commands.md` → "`josh run:wake`".
+setting are `docs/josh-commands-automation.md` → "`josh run:wake`".
 
 **Every unattended role runs with the provider selected from the invoking CLI and its own profile.**
 Codex sessions use OpenAI; Claude Code sessions use Anthropic. Anthropic uses scheduler
@@ -244,7 +244,7 @@ and legacy `JOSH_LANE_*` values to the worker only. Invalid configuration, a mis
 session marker, or a missing, outdated or unauthenticated CLI refuses without fallback, promotion or
 worker retry. `run:wake --list`, `lane:list`, the review brief and each launch
 log expose the resolved provider, role, model and effort.
-`docs/josh-commands.md` → "`josh lane:dispatch`" and `backlogrun-child.md` → "Each child runs in a
+`docs/josh-commands-automation.md` → "`josh lane:dispatch`" and `backlogrun-child.md` → "Each child runs in a
 delegated unit" are the single sources.
 
 **It relays progress from the existing report record.** The driver keeps the same `run:merge` event
@@ -301,10 +301,10 @@ stop at a time.**
   never the body.
 - **Order and isolate the pool in the same pass** (joshuafolkken/kit#2776), from the same
   `issue:read`: an issue that must land first (it builds what another reuses, or both edit one code
-  path) becomes a native `blocked-by`; an issue the `wip-cap.md` → 「実行のしかた」 enumeration hits
-  gets `run:solo`, **every other one `run:lane`**. Comment the reason; the offer commands enforce all
+  path) becomes a native `blocked-by`; an issue meeting all three of the `wip-cap.md` → 「実行のしかた」
+  conditions gets `run:solo`, **every other one `run:lane`**. Comment the reason; the offer commands enforce all
   three, answering `triage` while an issue has neither.
-- **`priority:high` puts an issue first** (joshuafolkken/kit#2928; ranking: `docs/josh-commands.md` →
+- **`priority:high` puts an issue first** (joshuafolkken/kit#2928; ranking: `docs/josh-commands-automation.md` →
   `josh backlog:next`). Apply it only on a cited ground — a stated deadline or urgency, or a person's
   written policy — commenting the ground; **never remove it**.
 - **Report the order those labels produce — `pnpm josh backlog:plan --waves`** (joshuafolkken/kit#2778),
@@ -342,7 +342,7 @@ follow, one per line.** `backlog:offer` forwards `--exclude` and `--repo` to `ba
 in `--json`. **The verdict table is "The two budgets" below; the answer-to-word mapping it applies is
 this section's table.**
 
-**`backlog:next`'s output contract is `docs/josh-commands.md` → "`josh backlog:next`", and four parts
+**`backlog:next`'s output contract is `docs/josh-commands-automation.md` → "`josh backlog:next`", and four parts
 of it decide how the mapping is written:**
 
 1. **Standard output is one token per line, and everything else is standard error.**
@@ -365,7 +365,7 @@ subsection.
 | Answer | What to do | Budget answer |
 | --- | --- | --- |
 | One or more issue numbers | Start each one as a child, up to the free lanes — `backlogrun-lanes.md` → "Lanes" and "Each child runs in a delegated unit", unchanged. Then **ask the command again**, with the merged numbers added to `--exclude` | `candidates` |
-| `wait`, with something of this run's own still in flight | Everything opted in is blocked or already running, so waiting can still change the answer. **Ask the command again on the wake the progress watcher's exit delivers** — the parent starts no sleep of its own, and the interval is a floor on the re-ask rather than a clock (`backlogrun-progress.md` → "Waiting, and never waiting forever" and "The parent keeps no clock of its own") | `blocked` |
+| `wait`, with something of this run's own still in flight | Everything opted in is blocked or already running, so waiting can still change the answer. **Ask the command again on the in-flight wake — `pnpm josh lane:await` or the progress watcher's arrival exit, never a report** — the parent starts no sleep of its own, and the interval is a floor on the re-ask rather than a clock (`backlogrun-progress.md` → "Waiting, and never waiting forever" and "The parent keeps no clock of its own") | `blocked` |
 | `wait` this checkout can never resolve — the only candidates the command reported on standard error are in other repositories, and this run has nothing of its own in flight | Report those candidates with their checkouts. **Waiting cannot resolve them, but a person opting a new issue in here still can**, so the ending is the idle watch's rather than this row's | `exhausted` |
 | `stop` | Nothing can proceed without a person. Report the parked issues and finish | `parked` |
 | `triage` | A candidate lacks `run:solo` / `run:lane` (joshuafolkken/kit#2779). Judge each one stderr names as the pre-start pass does, then **ask again**; running children continue | `untriaged` |
@@ -398,7 +398,7 @@ records.
 blocker sits in another opted-in epic — or is an opted-in standalone issue — makes the child wait on
 time, so one `backlogrun` runs both epics in that order. A blocker outside the opted-in backlog, or one
 inside it that itself waits on a person, makes the child wait on a person instead, and a cycle across
-epics answers `error`. The table is `docs/josh-commands.md` → "`josh epic:next`".
+epics answers `error`. The table is `docs/josh-commands-automation.md` → "`josh epic:next`".
 
 **New work is picked up without restarting anything.** The command re-derives its pool from GitHub
 labels on every ask, so an issue filed and opted in while the run is going is offered on the next
@@ -451,7 +451,7 @@ tracks.
 | Verdict | What the loop does |
 | --- | --- |
 | `run` | Start what `backlog:next` offered, up to the free lanes. The reason names how many more the maximum still allows; start no more than that |
-| `watch` | Ask both commands again — at the 5-minute idle poll while the backlog is empty **and** nothing of this run's is in flight, and at the 60-second polling interval in every other case (a blocked backlog, a drain, or a watch that opened while children were still merging). *Whether the parent keeps that interval as a clock of its own* is the in-flight test: with nothing in flight the watcher declines for the whole watch and never exits, so the parent sleeps the interval itself; with something in flight the wake is the watcher's exit and the interval is only a floor on the re-ask (`backlogrun-progress.md` → "The wake exists only while something is in flight"). **Nothing is held while watching** — the working tree's hold and each drained lane were released at the last child's merge, so a watching run blocks no other run |
+| `watch` | Ask both commands again — at the 5-minute idle poll while the backlog is empty **and** nothing of this run's is in flight, and at the 60-second polling interval in every other case (a blocked backlog, a drain, or a watch that opened while children were still merging). *Whether the parent keeps that interval as a clock of its own* is the in-flight test: with nothing in flight the watcher declines for the whole watch and never exits, so the parent sleeps the interval itself; with something in flight the wake is `pnpm josh lane:await` or the watcher's arrival exit — never a report — and the interval is only a floor on the re-ask (`backlogrun-progress.md` → "The wake exists only while something is in flight"). **Nothing is held while watching** — the working tree's hold and each drained lane were released at the last child's merge, so a watching run blocks no other run |
 | `stop` | Report and finish. The reason it printed **is** the termination reason the completion report carries |
 
 **At the drain the retrospective fires before this watch, not after it** (joshuafolkken/kit#2335):
@@ -466,7 +466,7 @@ again at its full budget. Both are ISO-8601 timestamps (`date -u +%FT%TZ`), and
 `--active` is refused. `--merged` is what has merged and `--running` what is still in a lane; **both
 count against the maximum**. **No ending abandons a lane**: whatever would have ended the run answers
 `watch` while `--running` is above zero, so the lanes drain and their merges reach the report. The full
-contract is `docs/josh-commands.md` → "`josh backlog:budget`".
+contract is `docs/josh-commands-automation.md` → "`josh backlog:budget`".
 
 **The completion report names three things the budgets make meaningful**: how many issues this run
 took, how many of them were picked up during an idle watch, and the termination reason — quoted from

package/.claude/skills/workflow-commands/backlogrun.md

@@ -48,8 +48,8 @@ Each step is a terse trigger and a pointer; the procedure is read on demand from
    that bounds the amount. `auto-ok` is a person's alone.
 4. **Report the plan before the first child** — `pnpm josh backlog:plan`, then resolve every
    `needs-decision` issue decidable from its body in one pass. In the same pass, record `blocked-by`
-   between issues that must land in order, and apply `run:solo` where the verification-path
-   enumeration holds, `run:lane` elsewhere. `backlogrun-steps.md` → "The plan,
+   between issues that must land in order, and apply `run:solo` where all three of the
+   `wip-cap.md` → 「実行のしかた」 conditions hold, `run:lane` elsewhere. `backlogrun-steps.md` → "The plan,
    before the first child starts" and its "Resolve what the plan can resolve, before starting".
 5. **Named issues run first, in order** — `backlogrun-steps.md` → "Named issues run first, in order":
    the supervisor's driver dispatches each as a delegated `fullrun`, one at a time, then drains the

package/.claude/skills/workflow-commands/chain-rule.md

@@ -7,8 +7,10 @@ Review results and successful pushes are never turn boundaries.
 
 0. **A lane child** (#2428): `pnpm josh main:merge`, the scoped pair, `pnpm josh ship --detach --review
    "<title> #<N>"` (`--cite <N>`), then **end the turn** on `launched`/`busy`. A stop relaunches a child
-   whose `run:step` names `ship --log <N>`: fix, re-detach (`--review` only if no round is recorded,
-   else step 4). `failed` → step 1.
+   whose prompt names `pnpm josh ship --log <N>` and (Anthropic lane, #2964) the re-detach to run after
+   the fix — `pnpm josh ship --detach`, `--review` only if the stopped ship carried it and stopped before
+   round 2, which is final (`scripts/run/run-ship-next.ts`); the supervisor skips a recorded round 1.
+   `failed` → step 1.
 1. Run `pnpm josh main:merge`. **Then issue `pnpm josh run:cut <N>` alone, before the scoped pair and
    the gate** — the pre-gate cut (a no-op outside a lane, joshuafolkken/kit#2177). Then run the final scoped lint/test pair and `pnpm josh run:review`: it starts
    `pnpm josh gate` in the background and prints the `/code-review` brief in one call, so the two overlap

package/.claude/skills/workflow-commands/delegation.md

@@ -17,13 +17,13 @@ pnpm josh delegate --list   # the enumeration, and what was rejected and why
 **how a wrong result is caught** cheaply in the parent tier, not merely by being unlikely to fail.
 `pnpm josh delegate --list` names both delegatable and rejected steps; a rejected step either has no
 verifier or lets a wrong result propagate too far. The command distinguishes `kept deliberately`
-from `kept by default`. `docs/josh-commands.md` → "`josh delegate`" carries the full enumeration.
+from `kept by default`. `docs/josh-commands-automation.md` → "`josh delegate`" carries the full enumeration.
 
 **The mechanism is not the unit.** `pnpm josh delegate` covers a run step, a file-disjoint Step 0
 implementation unit (`pnpm josh fanout`), and `epic-child` — an epic's child and a named issue of a
 `backlogrun` alike. Do not add a second batch-child mechanism. Read `backlogrun-child.md` → "Each child
 runs in a delegated unit" at child dispatch; `backlogrun-steps.md` → "Named issues run first, in order"
-applies to named issues. `docs/josh-commands.md` → "`josh fanout`" carries file-disjoint dispatch.
+applies to named issues. `docs/josh-commands-automation.md` → "`josh fanout`" carries file-disjoint dispatch.
 
 **`followup-filing` delegates the late review-finding filing chain** with the parent's finding text;
 the parent verifies the new Issue using `pnpm josh issue:state <new>`. For `epic-child`, the parent
@@ -41,7 +41,7 @@ a temporary probe script and return its output.
 delegate the unread investigation. Brief the unit on what was already read; do not re-read it there.
 **A delegation resets the counter rather than spending it**; `pnpm josh investigation:guard` counts
 unedited files and refuses the threshold read. `pnpm josh delegate --list` prints the threshold.
-`docs/josh-commands.md` → "`josh investigation:guard`" carries the command's counting details.
+`docs/josh-commands-automation.md` → "`josh investigation:guard`" carries the command's counting details.
 
 **The main line does not idle while the unit reads:** read files this run will edit, then verify the
 unit's cited lines. Independent investigations launch together; a brief that needs another unit's

package/.claude/skills/workflow-commands/followup-reference.md

@@ -115,4 +115,4 @@ pnpm josh release:scope --json   # the same answer as one JSON object
 
 **`pnpm josh release --dry-run` was checked first and does not answer this.** It refuses off the default branch and on a dirty working tree, and it counts against `HEAD` rather than `origin/<default>` — and every position above is a feature branch or a lane, which is exactly where it throws. So `release:scope` adds **no counting of its own**: it reads `git_followup_pending.read_pending`, the same fetch-then-count `pnpm josh followup` already uses for the Telegram line, and the two therefore cannot disagree.
 
-**This section is the single source.** `fullrun.md`, `backlogrun.md` and `backlogrun.md` point here rather than restating it, and `docs/josh-commands.md` → "`josh release:scope`" documents the command itself.
+**This section is the single source.** `fullrun.md`, `backlogrun.md` and `backlogrun.md` point here rather than restating it, and `docs/josh-commands-automation.md` → "`josh release:scope`" documents the command itself.

package/.claude/skills/workflow-commands/followup.md

@@ -19,7 +19,10 @@ bullets. Use the file option whenever it contains a command or path.
 
 It waits for required CI, checks CodeRabbit and top-level AI review comments, sends the completion
 Telegram, merges by default, posts the Issue report, closes completed epics, removes `in-progress`,
-and releases the hold. Only `--no-merge` stops the merge; `--merge` is a deprecated no-op. Keep the
+and releases the hold. Only `--no-merge` stops the merge; `--merge` is a deprecated no-op. **A pull
+request already merged by hand** (a `prrun` stop, joshuafolkken/kit#3023) skips the CI wait, the AI
+review scan and the merge and runs only the post-merge tail; a completion report already on the Issue
+is not posted or notified twice, so re-running is safe. Keep the
 default Issue target. Ignore a finding only after verifying it is inapplicable; rate-limit text is not
 a finding.
 
@@ -174,8 +177,9 @@ pnpm josh ms
   Review findings before merging. If blockers are found, it sends a `confirmation` Telegram and exits
   non-zero — fix the findings and re-run. **Green CI is not authorization to merge while AI review
   findings are open.** (SonarCloud findings are not scanned by `followup`; the `sonar-qube.yml` CI
-  workflow runs the scan with `sonar.qualitygate.wait=true`, so a red Quality Gate fails the required
-  `SonarQube` check, which `followup` waits on.)
+  workflow runs the scan with `sonar.qualitygate.wait=true` and then `josh sonar:new-code`, so a red
+  Quality Gate or a single new Sonar issue or duplicated block fails the required `SonarQube` check,
+  which `followup` waits on.)
 - **CodeRabbit rate-limit is not a finding.** If the only CodeRabbit comment is a rate-limit warning
   (`rate limited by coderabbit.ai` or `Rate limit exceeded`) and there is no substantive review, treat
   it as "no findings" and proceed. Same if CodeRabbit produced no comment on the latest commit.

package/.claude/skills/workflow-commands/fullrun-steps.md

@@ -26,7 +26,7 @@ in outline: refactor → `pnpm josh main:merge` → **a dispatched lane child ha
 joshuafolkken/kit#2428) → otherwise `pnpm josh run:cut <N>` (the pre-gate cut, before the gate; a no-op
 outside a lane) → start `pnpm josh gate` and a subagent `/code-review`
 with the brief `pnpm josh review:brief` prints on `git diff main`, join the gate before the commit,
-iterate to no high/medium findings, at most two reviews → **the clean path folds the ship region into
+iterate to no high/medium findings, within the round cap (`prompts/review.md`) → **the clean path folds the ship region into
 one call**, `pnpm josh ship "<title> #<N>"` (gate → commit/push/PR → the CI-wait `followup` → the
 `run:tail` report bookkeeping, stopping at the first failed step; joshuafolkken/kit#2398), with any
 branch-2 filing (`pnpm josh issue:file`, which runs `epic:bundle` itself) run before it → **when a second round is due `ship` does not
@@ -44,7 +44,8 @@ implementation summary via `--notify-message` in the session language, leading w
 plain-language lines: `"Implemented <title>\nCause: ...\nFix: ...\nResult: ...\n\nDetails:\n-
 <change1>\n- <change2>"`. **`pnpm josh followup` waits for CI, verifies AI review findings, sends the
 completion notification, then merges; if blockers are found it exits non-zero — fix and re-run.**
-**マージ後に `pnpm josh ms` を実行する。** Codex レーンでは省略し、親の `run:merge` が主チェックアウトで同期する。Claude は従来どおり。
+**Run `pnpm josh ms` after the merge.** A Codex lane skips it — the parent's `run:merge` syncs the
+primary checkout; a Claude run keeps it.
 
 ## The `fullrun new` step list
 

package/.claude/skills/workflow-commands/fullrun.md

@@ -21,7 +21,7 @@ single sources). Step 2 — the `in-progress` label — stays its own call, appl
 call reports `hold`.
 
 1. **Claim the working tree — first, before anything else.** For `fullrun #N`, first run the folded
-   `pnpm josh run:entry <N>` above; it calls `run:hold` as its first step. For `fullrun new`, call
+   `pnpm josh run:entry <N>` above (no `--to` is `fullrun`, §2k); it calls `run:hold` as its first step. For `fullrun new`, call
    bare `pnpm josh run:hold`, ahead of the title and filing. `hold` continues; `busy` / `unknown` stop
    with a `confirmation` Telegram carrying stderr.
    `working-tree-hold.md` is the single source; a cross-repository target resolves its checkout from
@@ -32,8 +32,8 @@ call reports `hold`.
    `pnpm josh run:release`: `gh api -X DELETE repos/{owner}/{repo}/issues/<N>/labels/in-progress
    2>/dev/null || true`. A `needs-human-review` stop keeps both hold and label.
 3. **Ask the session boundary in the same turn as the hold** — `pnpm josh cost --cut`. `under`
-   continues; `over` (or unanswerable) stops before the title with a `confirmation` Telegram carrying
-   the figure and the resume command (`fullrun #<N>` / `fullrun new`), then `pnpm josh run:release`.
+   continues; `over` (or unanswerable) stops before the title — `run:entry` sends this and step 1's
+   `confirmation` Telegram and runs `run:release` (`stop notified: …`); by hand only for `new`.
    **Skip it when dispatched by `backlogrun`** (that batch owns the question). `backlogrun-progress.md`
    → "The hand-off" is the single source of the check and the shared 135,000 threshold.
 4. **Gather the mechanical reads — `pnpm josh run:prep <N>`**: `issue:read`'s body/comments
@@ -51,7 +51,7 @@ call reports `hold`.
 ## The progress step and the lane-child seam
 
 - **Start the progress watcher once the hold is claimed** — `pnpm josh run:progress --wait` in the
-  background, presented as-is when it exits, and `pnpm josh run:progress --mark` in the same turn as
+  background, started once and relayed never, and `pnpm josh run:progress --mark` in the same turn as
   every real report (`backlogrun-progress.md` → "Progress while the run is quiet"). A `fullrun`
   dispatched as a lane child starts none and never reads that document (`pnpm josh read:set
   lane-child`). **The watcher is a per-session heartbeat; the run's report surface is not it** — the
@@ -62,8 +62,10 @@ call reports `hold`.
   before the hold, joshuafolkken/kit#2760); on `resume` it skips the title, plan, hold and implementation and goes to the gate. At the pre-gate
   boundary — immediately after `pnpm josh main:merge`, before the gate — it takes the cut with
   `pnpm josh run:cut <N>` (the ordered step in `chain-rule.md`), and it records any park on the Issue before the stop notify.
-  `pre-gate-cut.md` is the single source of both.
-- **`resume: halfrun`** adopted a stopped `halfrun` (#2796): gate in full; `working-tree-hold.md`.
+  `pre-gate-cut.md` → "Resuming — the fresh process's entry check" and `pre-gate-cut.md` → "Taking
+  the cut" are the single sources of the two.
+- **`resume: halfrun`** adopted a stopped `halfrun` (#2796): gate in full; `resume: prrun-*` a stopped
+  `prrun` (#3023); `working-tree-hold.md`.
 
 ## The stop branches
 

package/.claude/skills/workflow-commands/halfrun.md

@@ -4,51 +4,49 @@ When this run files a new Issue, file it with `pnpm josh issue:file`, which lint
 
 `halfrun` sits between `kickoff` (plan only) and `fullrun` (full execution with auto-merge). It
 implements the change and runs the full verification gate, then **stops before commit** — nothing is
-committed, pushed, or opened as a PR — so the user manually verifies the change (typically by exercising
-the UI in a browser) against the working tree. Use `halfrun` when the change has UI/UX implications or
-anything else that requires human eyes before shipping.
+committed, pushed, or opened as a PR — so a person verifies the working tree by hand. Use it when a change needs human eyes before shipping.
 
-**This file is the manifest** (joshuafolkken/kit#2189): the ordered steps as terse triggers and
-pointers, the detail read on demand from the file each pointer names.
+**This file is the manifest** (joshuafolkken/kit#2189): terse ordered steps, each pointing at the file
+that holds its detail.
 
 ## The ordered entry sequence
 
-1. **Claim the working tree first** — `pnpm josh run:hold <N>` (bare for `halfrun new`), ahead of the
-   title and a `new` entry's filing; `busy` / `unknown` stop with a `confirmation` Telegram. **The stop
-   before commit keeps the hold** (the uncommitted work is what a second run would trample); a stop on a
+1. **Claim the working tree first** — `pnpm josh run:entry <N> --to halfrun` (bare `pnpm josh
+   run:hold` for `new`), ahead of the title and a `new` filing; it folds steps 3 and 5 and starts
+   at its stage line's `start:` (`SKILL.md` → §2k). `busy` / `unknown` stop with a `confirmation` Telegram (`run:entry` sends it). **The stop
+   before commit keeps the hold** (a second run would trample the uncommitted work); a stop on a
    split, prerequisite or third-party target releases it. `working-tree-hold.md` is the single source; a
    cross-repository target resolves its checkout from `pnpm josh doctor` first (`target-repository.md`).
 2. **Apply `in-progress` the moment `run:hold` answered `hold`** — the stop before commit keeps it on;
    a stop that leaves the tree clean removes it in the same turn as `pnpm josh run:release` (`gh api -X
    DELETE repos/{owner}/{repo}/issues/<N>/labels/in-progress 2>/dev/null || true`).
-3. **Ask the session boundary in the same turn as the hold** — `pnpm josh cost --cut`, exactly as
-   `fullrun`; `over` stops with a `confirmation` Telegram and the resume command (`halfrun #<N>` /
-   `halfrun new`). **Skip it when dispatched by a batch.** `backlogrun-progress.md` → "The hand-off" is
+3. **Ask the session boundary** — `pnpm josh cost --cut` (folded into `run:entry`); `over` stops — `run:entry` notifies and releases
+   (`halfrun new`: by hand). **Skip it when dispatched by a batch.** `backlogrun-progress.md` → "The hand-off" is
    the single source of the check and the shared 135,000 threshold.
 4. **Start the progress watcher once the hold is claimed** — `pnpm josh run:progress --wait` in the
-   background, `--mark` in the same turn as every real report; the stop before commit ends the watcher
+   background, started once — it reports to the event stream itself and nothing is relayed — and
+   `--mark` in the same turn as every real report; the stop before commit ends the watcher
    itself (`backlogrun-progress.md` → "Progress while the run is quiet").
-5. **Gather the mechanical reads — `pnpm josh run:prep <N>`** (`issue:read`'s body/comments — `SKILL.md`
-   → §2g → `issue-comments.md`; `issue:state`'s `human_review`; `latest:scope`), then `pnpm josh
-   run:next <N>`.
+5. **The mechanical reads** — `run:entry` folds `run:prep` (body/comments — `SKILL.md` → §2g;
+   `human_review`; `latest:scope`); a `new` entry runs `pnpm josh run:prep <N>` once filed.
 
 ## The step list
 
 `halfrun #<N>`: add `in-progress` → read Issue #N and its comments → **normalize the title** (same as
 `fullrun`) → post the agreed plan only if the body is blank → `git switch main && git pull`, then `pnpm
-josh latest:scope` and update dependencies only on `required` (`latest-gate.md`; load the
-`dependency-update` skill on `required`) → implement → run the **full verification gate** (refactor →
+josh latest:scope` and update dependencies only on `required` (`latest-gate.md`; the
+`dependency-update` skill) → implement → run the **full verification gate** (refactor →
 start `pnpm josh gate` beside a subagent `/code-review` with the brief `pnpm josh review:brief` prints,
-join the gate before the stop, iterate to no high/medium findings, at most two reviews → `pnpm josh
+join the gate before the stop, iterate to no high/medium findings, within the round cap (`prompts/review.md`) → `pnpm josh
 test:e2e`, run by **you**, because `halfrun` opens no pull request and there is no CI E2E job; a printed
 skip is the answer where the project has no suite) → **mark the stop: `pnpm josh run:hold <N>
 --halfrun-stop`** (the record `fullrun #<N>` adopts; `new` passes the filed number) → send a
 `confirmation` Telegram with the resume commands in the body → **stop**. Plan comments are in the session language. The `confirmation` Telegram
-body MUST include the exact resume commands — **`fullrun #<N>` first**, since that is how a verified
+body MUST include the exact resume commands — **the `Next:` line first**, since that is how a verified
 `halfrun` ships (joshuafolkken/kit#2796): its `run:entry` adopts this stop's marked hold and resumes at
 the gate. The direct commands follow for shipping without an agent:
 `pnpm josh notify --task-type confirmation --issue-url "<issue-url>" --body=$'halfrun ready for manual
-verification\nNext: fullrun #<N>\nWithout an agent: pnpm josh git -y "<title> #<N>" && pnpm josh
+verification\nNext: prrun #<N> | fullrun #<N>\nWithout an agent: pnpm josh git -y "<title> #<N>" && pnpm josh
 followup "<title> #<N>" --notify-message "Implemented <title>\\nCause: ...\\nFix: ...\\nResult:
 ...\\n\\nDetails:\\n- <change1>"'`. The stop report names the same two, in the same order.
 **Invoking `halfrun` is _not_ authorization to commit, push, or merge** — do not run `pnpm josh git -y` or `pnpm josh followup` yourself. If the user comes
@@ -72,7 +70,7 @@ Telegram and **stop**.
 - **A split** — the assessment (`split-assessment.md` → "The question") finds two or more
   separately-mergeable deliverables over one gate: file the children (each `route:split`) and the epic,
   then **STOP** with "Please run `backlogrun #<E> --only` to execute this epic." Typing `halfrun`
-  authorized implementing **one** Issue and stopping for manual verification, never a batch.
+  authorized **one** Issue, never a batch.
 - **A prerequisite** — file it (`route:tier-a`), stash, record the dependency, and **STOP**;
   `prerequisite.md` is the single source of the filing, the `-u` stash and the epic:bundle branch.
 - **An observation** — file it without asking and carry on; `SKILL.md` → §2i.

package/.claude/skills/workflow-commands/issue-comments.md

@@ -66,7 +66,7 @@ procedure and not two. **Parking it is not the place**: `needs-decision` means "
 nobody has given", and here the answer exists.
 
 **The exit is the `already-done` label.** It is `needs-decision`'s counterpart: `epic:next`,
-`backlog:next` and `auto-ok:next` all stop offering the Issue (`scripts/git/issue-labels.ts` →
+`backlog:next` and `auto-ok:next` all stop offering the Issue (`scripts/issue/issue-labels.ts` →
 `NOT_DIRECTLY_RUNNABLE_LABELS`, `epic-classify.ts` → `human`), and `epic:busy` stops counting it as
 holding a lane. **Only a person removes it, by closing the Issue.**
 

package/.claude/skills/workflow-commands/issue-fold-existing.md

@@ -1,20 +1,20 @@
-# 未着手 Issue への追加要件の統合
+# Folding added requirements into an unstarted Issue
 
-## 候補の読み取り
+## Reading the candidates
 
-起票予定の目的・要件・受け入れ条件を含む全文を `pnpm josh issue:scout "<title>" --body-file <draft.md>` に渡す。明示的に参照した `#N` は見出しが似ていなくても候補になる。`Duplicates: incomplete` は読み取りまたは探索の不足であり、候補なしという結論ではない。
+Pass the whole draft — purpose, requirements and acceptance criteria — to `pnpm josh issue:scout "<title>" --body-file <draft.md>`. An explicitly referenced `#N` is a candidate even when its title looks unrelated. `Duplicates: incomplete` means the read or the search fell short; it is not a conclusion that no candidate exists.
 
-候補の本文とコメントを `pnpm josh issue:read <N>` で全て読み、状態とラベルを `pnpm josh issue:state <N>` で読む。紐づく PR と依存・実行順も調べる。本文と後のコメントが矛盾した場合は後のコメントを採る。読み取り失敗や打ち切りがあれば統合可否は未確定とする。
+Read each candidate's body and every comment with `pnpm josh issue:read <N>`, and its state and labels with `pnpm josh issue:state <N>`. Check the linked PRs and the dependencies and run order too. When the body and a later comment disagree, the later comment wins. A failed or truncated read leaves the fold decision undetermined.
 
-## 判定
+## Deciding
 
-下書きの各受け入れ条件を既存 Issue と照合する。完全な重複は起票も編集もしない。別の成果物は従来の起票経路を使う。固有の追加要件を統合できるのは、既存 Issue が open かつ未着手で PR がなく、依存と実行順に衝突がなく、合計の規模が `split-assessment.md` → "The question" の一回の検証に収まる場合に限る。状態または判断材料が不明なら統合しない。
+Match each acceptance criterion of the draft against the existing Issue. A complete duplicate is neither filed nor edited. A separate deliverable takes the ordinary filing path. Added requirements of its own may be folded in only when the existing Issue is open and unstarted with no PR, its dependencies and run order do not conflict, and the combined size fits the one verification pass of `split-assessment.md` → "The question". When the state or any input to the decision is unknown, do not fold.
 
-判定記録の JSON を作り、`pnpm josh issue:fold-existing <assessment.json> --json` を実行する。`content` は `duplicate` / `compatible` / `separate` / `unknown`、`size_verdict` は `single` / `split` とする。ほかに `is_open`、`is_unstarted`、`has_pull_request`、`has_complete_read`、`has_dependency_conflict`、`is_separable`、`existing_body`、`draft_body`、`verification` を記録する。不明な事実は省略し、`inspect` を得る。判定記録は読んだ証跡であり、読み取りそのものの代わりにはならない。
+Write the assessment as JSON and run `pnpm josh issue:fold-existing <assessment.json> --json`. `content` is `duplicate` / `compatible` / `separate` / `unknown`, and `size_verdict` is `single` / `split`. Also record `is_open`, `is_unstarted`, `has_pull_request`, `has_complete_read`, `has_dependency_conflict`, `is_separable`, `existing_body`, `draft_body` and `verification`. Omit a fact you do not know, and the answer is `inspect`. The assessment is evidence of the reading, never a substitute for it.
 
-## 追記と再読
+## Appending and re-reading
 
-`fold` の場合、追記案の `body` は元の本文を保持し、固有の追加要件と検証方法を末尾に加える。書き込み直前に本文とコメントが判定時から変わっていないことを再確認する。変わっていれば再判定する。
+On `fold`, the proposed `body` keeps the original body and appends the added requirements and how to verify them. Immediately before writing, confirm the body and comments have not changed since the assessment; if they have, assess again.
 
 ```bash
 pnpm josh issue:fold-existing assessment.json --json > result.json
@@ -24,4 +24,4 @@ gh api -X PATCH repos/{owner}/{repo}/issues/<N> --input patch.json
 pnpm josh issue:read <N>
 ```
 
-再読して、元の要件・コメント中の判断記録・追加要件・検証方法が残ることを確認する。書き込みまたは再読が失敗した場合、統合は完了していない。統合時は新しい Issue を作らない。`separate` は従来の起票経路へ戻り、`inspect` は不足した情報を読み直す。
+Re-read it and confirm the original requirements, the decisions recorded in comments, the added requirements and the verification all remain. A failed write or re-read means the fold is not complete. A fold never creates a new Issue. `separate` returns to the ordinary filing path, and `inspect` re-reads the missing information.

package/.claude/skills/workflow-commands/issue-scout.md

@@ -41,4 +41,4 @@ pnpm josh issue:file "<title>" --body-file <complete-draft.md> --depth <n> --dis
 - **The split path files each child through the same command.** The epic is created with
   `pnpm josh epic` over children that were scanned.
 
-Full behavior: `docs/josh-commands.md` → "`josh issue:file`" and "`josh issue:scout`".
+Full behavior: `docs/josh-commands-automation.md` → "`josh issue:file`" and "`josh issue:scout`".

package/.claude/skills/workflow-commands/kickoff.md

@@ -1,13 +1,18 @@
 # `kickoff` — Planning phase only (plan → Issue → Telegram notify → stop)
 
-- `kickoff #<N>`: Read existing Issue #N **and every comment on it** — `pnpm josh issue:read <N>`; a
+- `kickoff #<N>`: **First `pnpm josh run:entry <N> --to kickoff`** (`SKILL.md` → §2k) — it claims
+  nothing and prints the stage line alone; `start: reached` means the Issue is already planned or further
+  up the ladder, so report the stage line and **stop**. Otherwise read existing Issue #N **and every comment on it** — `pnpm josh issue:read <N>`; a
   decision recorded after the body was written lives only in a comment, and the later text is the
   agreement in force (`SKILL.md` → §2g, which also carries the two answers that stop the run instead) →
   **normalize the title**: if the title is not in English or can be phrased more clearly, derive a
   better English title and run `gh api -X PATCH repos/{owner}/{repo}/issues/<N> -f title="<title>"` →
   analyze requirements → **scope assessment per `split-assessment.md`** → post the plan to the Issue (if
   body is blank, `gh api -X PATCH repos/{owner}/{repo}/issues/<N> -f body="<plan>"`; otherwise
-  `pnpm josh issue:comment <N> --body-file <path>`) → send Telegram notification → **stop**
+  `pnpm josh issue:comment <N> --body-file <path>`) → **apply the `run:planned` label** — the mark the next
+  command's `run:entry` reads to start at the implementation, provisioned by `josh sync` (`gh api
+  repos/{owner}/{repo}/issues/<N>/labels -f 'labels[]=run:planned' --silent`) → send Telegram
+  notification, its last line `Next: halfrun #<N> | prrun #<N> | fullrun #<N>` → **stop**
   (do not implement). **When the assessment finds two or more separately-mergeable deliverables**, take
   the split path instead of posting a plan: create the children as in `kickoff new`, then either
   **promote `#N`** with `pnpm josh epic --promote <N> <N1> <N2> ... [--ordered] [--rationale-file
@@ -37,7 +42,7 @@ than filing.
 **Read `split-assessment.md` → "The question" first.** It is the split decision every entry point
 applies, including this one — `kickoff #N` assesses scope exactly as `kickoff new` does. Its default is
 not to split: separability and a scope that clearly exceeds what one verification gate can confirm in
-one pass (the guide is about 10 changed files and about 400 changed lines) have to hold **together**.
+one pass (the size guide is stated there) have to hold **together**.
 The rest of `split-assessment.md` — what each entry does with the answer — is read on demand when a
 split is found.
 
@@ -80,4 +85,4 @@ split is found.
   creation call. (3) Send Telegram notification listing all created issues. (4) Present the command
   `backlogrun #<E> --only`. (5) **Stop** — do not implement.
 
-`pnpm josh issue:file` lints the body and applies the classification labels it declares, following `prompts/collaboration-workflow/issue-template.md` for classification (`docs/josh-commands.md` → `josh issue:file`).
+`pnpm josh issue:file` lints the body and applies the classification labels it declares, following `prompts/collaboration-workflow/issue-template.md` for classification (`docs/josh-commands-automation.md` → `josh issue:file`).

package/.claude/skills/workflow-commands/latest-gate.md

@@ -64,22 +64,14 @@ merge is CI**: the `Security Audit` job runs on every pull request and is one of
 whatever this gate answered locally. The local reading is a head start on a failure CI would catch
 anyway; it was never the only net.
 
-## Why an elapsed-time window rather than "once per batch"
-
-The batch entry points had already hoisted the update to the head of a batch, and that hoist is
-correct — but it says nothing about a standalone `fullrun`, which **is** the head of its own
-one-issue batch and therefore updated on every invocation. A session that runs six issues one at a
-time paid the full cost six times while a batch of the same six paid it once, for no difference
-anybody chose. An elapsed-time window is the one condition that reads the same at every entry point,
-so no entry needs a rule of its own — and the batch hoists survive it unchanged, because a batch's
-second child asks the same command and is told `skip`.
-
-**The lock file the update rewrites still lands with whichever issue ran it.** `josh latest` leaves
-`pnpm-lock.yaml` modified and that issue's `pnpm josh git -y` commits it, exactly as before. What the
-window removes is the other runs carrying the same bumps; it does not make that one diff clean.
-Should the issue then fail CI on a bump rather than on its own change, that is a dependency problem
-found once — fix it forward before parking the issue for it.
+## The lock file lands with the issue that ran the update
+
+**The lock file the update rewrites lands with whichever issue ran it.** `josh latest` leaves
+`pnpm-lock.yaml` modified and that issue's `pnpm josh git -y` commits it. Should the issue then fail
+CI on a bump rather than on its own change, fix it forward before parking the issue for it. Rationale
+for the elapsed-time window: `docs/maintainers/latest-gate-rationale.md` → "Why an elapsed-time
+window rather than once per batch".
 
 This file is the single source of the rule. `fullrun.md`, `halfrun.md`, `backlogrun.md` and `backlogrun.md`
 each name `pnpm josh latest:scope` at the point their procedure reaches it and route here for
-everything else; `docs/josh-commands.md` documents the command itself.
+everything else; `docs/josh-commands-automation.md` documents the command itself.

package/.claude/skills/workflow-commands/needs-human-review.md

@@ -57,7 +57,7 @@ run's *start*; this withholds its *end*. So a `needs-human-review` issue is stil
 the artifact a person is meant to look at would never be produced — and a child stopped by it **goes on
 holding its repository**, because the uncommitted work is still in the checkout; read as parked there,
 the next child would start `git switch main && git pull` on top of it. The code encodes both halves by
-leaving the label out of two sets: `scripts/git/issue-labels.ts` keeps it out of
+leaving the label out of two sets: `scripts/issue/issue-labels.ts` keeps it out of
 `NOT_DIRECTLY_RUNNABLE_LABELS` and `scripts/epic/epic-busy.ts` keeps it out of the parked set.
 
 Each entry point's own branch stays in its own file — `fullrun.md`, `halfrun.md`,

package/.claude/skills/workflow-commands/observation-filing.md

@@ -19,7 +19,7 @@ Tier C (`CLAUDE.md`). Name what was filed in the completion report. An observati
 on is dropped rather than filed.
 
 **The filing ceilings still apply.** Count this filing in the ten-Issue limit for the run. An
-observation is discretionary, so above 30 open Issues in the target repository, close one first or do
+observation is discretionary, so above the WIP cap in the target repository, close one first or do
 not file (`prompts/collaboration-workflow/wip-cap.md`). File it with `pnpm josh issue:file`
 (`issue-scout.md`), which lints the body against `prompts/collaboration-workflow/issue-template.md`,
 applies the classification labels it declares, runs the duplicate scan, and runs `epic:bundle` on the
@@ -42,7 +42,7 @@ The detail below is read at the filing decision, and the marker suite pins the r
 
 **The depth is recorded on the Issue as a label, and the label is applied when the Issue is filed**
 (joshuafolkken/kit#1729). `depth:0`, `depth:1` and `depth:2` are the three, defined once in
-`scripts/git/issue-labels.ts` and carrying no definition of their own — **the table above is the
+`scripts/issue/issue-labels.ts` and carrying no definition of their own — **the table above is the
 single source**, and a label description that paraphrased it would be a second copy of the rule.
 **Every filing route applies one**, this route and the other three of §2d's table alike: a `new`
 entry point, a `route:tier-a` prerequisite, a `route:interrupt`, a split child and a review round
@@ -56,7 +56,7 @@ gh api repos/{owner}/{repo}/issues/<N>/labels -f 'labels[]=depth:1'   # an Issue
 
 **Create the three once per repository**, before the first filing that applies one — REST auto-creates
 a missing label with a generated color and no description, and the three lines below are what give
-each a stable color a reader can scan a listing by. `DEPTH_LABELS` in `scripts/git/issue-labels.ts`
+each a stable color a reader can scan a listing by. `DEPTH_LABELS` in `scripts/issue/issue-labels.ts`
 is the single source of the colors and descriptions, and `scripts/rules/issue-depth-label.test.ts` keys
 these lines to it so the two cannot drift.
 

package/.claude/skills/workflow-commands/pre-gate-cut.md

@@ -69,9 +69,8 @@ pnpm josh run:cut <N>
 **`cut` is the only verdict that ends the turn.** Every other one — `under-threshold` included — leaves
 the current process to carry the run on itself.
 
-### The gate refuses until the cut has been taken (joshuafolkken/kit#1864)
+### The gate refuses until the cut has been taken
 
-**This step was carried as prose and fired exactly never.** In measured lane children the cut was taken **0 times**, so
 `pnpm josh rule:guard` **refuses `pnpm josh gate`** while this checkout is a lane and no cut record is
 carried, handing back the command above. Rationale:
 `docs/maintainers/pre-gate-cut-rationale.md` → "Why the rules are guards, not prose".
@@ -165,13 +164,10 @@ hand-off". The parent's seam and the child's `run_cut.IMPLEMENTATION_CONTEXT_THR
 **135_000** `CONTEXT_CUT_THRESHOLD` (aliased so the tests cannot drift). No separate measurement is
 built for the lane child.
 
-### It is a guard, fired at the edit that crosses the threshold (joshuafolkken/kit#2310)
+### It is a guard, fired at the edit that crosses the threshold
 
-**This step was carried as prose and fired exactly never** — the cut fired **0 times** while 33.9% of
-lane requests ran past 200,000 tokens. Rationale:
-`docs/maintainers/pre-gate-cut-rationale.md` → "Why the rules are guards, not prose".
-
-So `pnpm josh rule:guard` **refuses an `Edit` / `Write`** while this checkout is a dispatched lane child
+Rationale: `docs/maintainers/pre-gate-cut-rationale.md` → "Why the rules are guards, not prose".
+`pnpm josh rule:guard` **refuses an `Edit` / `Write`** while this checkout is a dispatched lane child
 whose recent-context cost is over threshold, handing back `pnpm josh run:cut --impl <N> --handoff <path>` — the
 refusal lands _before_ the edit. `cut` ends the turn, the rest leave this process implementing; a fresh
 process's `pnpm josh run:cut --resume <N>` then answers **`resume-impl`**, so it **skips the title, plan,

package/.claude/skills/workflow-commands/prerequisite.md

@@ -31,7 +31,7 @@ pnpm josh issue:file "<title>" --body-file <body-file> --depth <n> --route tier-
 
 The command lints the body against `prompts/collaboration-workflow/issue-template.md`, applies the
 classification labels it declares, and runs the duplicate scan and `epic:bundle` itself
-(`docs/josh-commands.md` → `josh issue:file`).
+(`docs/josh-commands-automation.md` → `josh issue:file`).
 
 Every "file the prerequisite" below means that labelled filing, and it always happens **first**: the
 steps after it name a number that does not exist until it is. **Its duplicate scan is read exactly as

package/.claude/skills/workflow-commands/prrun.md

@@ -0,0 +1,36 @@
+# `prrun` — the manifest (plan → implement → PR → green → stop, a person merges)
+
+`prrun` sits between `halfrun` (stop before commit) and `fullrun` (auto-merge). It runs `fullrun`
+up to a green, mergeable pull request and **stops before the merge**, so a person merges by hand
+(joshuafolkken/kit#3023). **Read `fullrun.md` for every step** — the entry sequence, the step lists,
+the gate, the review and the stop branches are `fullrun`'s, unchanged. This file names only the
+difference, never a second copy of the procedure.
+
+## The difference — the entry
+
+`prrun #<N>` opens with `pnpm josh run:entry <N> --to prrun` where `fullrun` passes no `--to`
+(`SKILL.md` → §2k): a planned Issue starts at the implementation, a `halfrun` stop is adopted and
+resumes at the gate, and an Issue already stopped by a `prrun` is reached — report the stage line and
+stop. A merged Issue is reached too, but the `entry #<N>` line after the stage line answers it (§2k).
+
+## The difference — the end of the run
+
+Where `fullrun` runs `pnpm josh followup` and merges, `prrun` does three things and stops:
+
+1. **Watch the pull request to mergeable** — `pnpm josh followup "<title> #<N>" --no-merge`
+   (`followup.md` → "Run `pnpm josh followup`", read in the same turn): required CI green and the AI
+   review findings resolved. A failure stops the run exactly as it stops a `fullrun`.
+2. **Mark the stop — `pnpm josh run:hold <N> --prrun-stop`.** It records the commit the pull request is
+   on in this run's own hold, the record `fullrun #<N>` adopts (its prrun resume, `working-tree-hold.md`). **The hold and `in-progress` stay**: the run is not finished until the merge's tail runs.
+3. **Send a `confirmation` Telegram with the resume commands, then stop.** **`fullrun #<N>` first** —
+   its `run:entry` reads where the pull request stands and resumes from there; the direct command
+   follows for finishing without an agent:
+   `pnpm josh notify --task-type confirmation --issue-url "<issue-url>" --body=$'prrun ready to
+   merge: <pr-url>\nNext: fullrun #<N>\nAfter a manual merge, without an agent: pnpm josh followup
+   "<title> #<N>"'`. The stop report names the same two, in the same order.
+
+**Invoking `prrun` is _not_ authorization to merge** — never run `pnpm josh followup` without
+`--no-merge` in a `prrun`. After a person merges by hand, the same `pnpm josh followup "<title> #<N>"`
+runs only the post-merge tail (`followup.md`).
+
+`prrun new`: `fullrun new` up to the pull request, then the three steps above with the filed number.

package/.claude/skills/workflow-commands/retrospective.md

@@ -65,7 +65,7 @@ Issue, as after any filing.
 input, so the next run picks the improvements up without waiting for a person. **`backlogrun-steps.md` →
 "What one invocation approves" is that carve-out's single source**; it is written there, beside the
 brakes that bound it, rather than restated here. Every brake still counts a retrospective's filings: the
-ten-per-invocation ceiling, the WIP cap of 30, `--max`, the 150,000-token session budget and the 8-hour
+ten-per-invocation ceiling, the WIP cap, `--max`, the 150,000-token session budget and the 8-hour
 whole-run bound.
 
 **Close with `pnpm josh run:carry --retrospective --summary "<result>" --owner "$PPID"`.** It marks the