@joshuafolkken/kit 1.1035.0 → 1.1094.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.
@@ -131,7 +131,7 @@ single source.
 carried in a record rather than in the conversation:
 
 ```bash
-pnpm josh run:carry --begin "backlogrun --max 5 --idle 30" --owner "$PPID"   # alias: josh rc
+pnpm josh run:carry --begin "backlogrun --max 5 --idle 30" --owner "$PPID"
 pnpm josh run:carry --json                                                   # read it back in a resumed session
 ```
 
@@ -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                                                                                                                                                                                                          |
 | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
@@ -204,7 +204,7 @@ judgment starts an AI session, with the branch result and resume flags in its pr
 **Start it in the same turn as `--begin`, and stop it in the same turn as `--end`:**
 
 ```bash
-pnpm josh run:wake --start   # alias: josh rw ; right after `run:carry --begin`
+pnpm josh run:wake --start   # right after `run:carry --begin`
 pnpm josh run:wake --stop    # in the same turn as `run:carry --end`
 ```
 
@@ -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
@@ -267,7 +267,7 @@ run.
 **The plan is one command's output, not an assembly of several:**
 
 ```bash
-pnpm josh backlog:plan          # alias: josh blp
+pnpm josh backlog:plan
 ```
 
 **It renders the same classified pool `backlog:next` answers from**, so **the plan cannot promise an
@@ -282,9 +282,8 @@ order the run does not take**. Its four sections are:
   is distinguished from "not reached yet".
 
 **Report all four to the person, in the session language, before the first child starts.** Epic
-children are enumerated individually rather than summarized under their root. A `⚠` about a truncated
-listing is reported with them: the plan is then partial, and saying so is what keeps it from reading as
-complete.
+children are enumerated individually rather than summarized under their root. Report a truncated-listing
+`⚠` with them: the plan is then partial.
 
 ### Resolve what the plan can resolve, before starting
 
@@ -293,27 +292,28 @@ stop at a time.**
 
 - **Decide everything decidable from the issue itself.** Read the issue's body **and its comments**
   (`SKILL.md` → §2g), and where the answer is already there, record it as an Issue comment and
-  **remove the label** — `CLAUDE.md` → "Decision autonomy" already makes that Tier A. **Read every one
-  of them in one call** — `pnpm josh issue:read <N> <N> …`, the numbers the plan just listed under
-  "Waiting on a person" — rather than a `gh api` pair per issue.
+  **remove the label** — `CLAUDE.md` → "Decision autonomy" already makes that Tier A. **Read them all in
+  one `pnpm josh issue:read <N> <N> …` call**, not a `gh api` pair per issue.
 - **Never measure in order to decide.** A question needing a benchmark, a profile, or a run of the
   thing itself is not settled here: it stays labelled and the plan says so.
-- **Label what you find.** An issue that turns out to need a person's judgement has `needs-decision`
-  applied — the same label a parked child gets, applied the way `backlogrun-park.md` → "park and continue"
-  applies it. **The next plan then classifies it by reading the label alone**, never by reading the
-  body again.
+- **Label what you find.** An issue needing a person's judgement gets `needs-decision`, applied as
+  `backlogrun-park.md` → "park and continue" does. **The next plan classifies it by the label alone**,
+  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-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),
   `backlog:next` played forward wave by wave. Report it with the plan, never an order derived by hand.
 - **Then start the loop.** Whatever is still labelled is reported as parked and left standing; the
   run does not wait on it.
 
-**`needs-decision`, `run:solo` and `run:lane` are the workflow labels a run may apply, and none is
-`auto-ok` or `needs-human-review`.** Those two stay a person's alone (this file, `SKILL.md` → §2z); a
+**`needs-decision`, `run:solo`, `run:lane` and `priority:high` are the workflow labels a run may
+apply, and none is `auto-ok` or `needs-human-review`.** Those two stay a person's alone (this file, `SKILL.md` → §2z); a
 run parks with `needs-decision` and a person clears it.
 
 Rationale: `docs/maintainers/backlogrun-steps-rationale.md` → "Why the plan and the decision pass come first"
@@ -331,7 +331,7 @@ returns the verdict with the issues to start. It stays both halves' contract sou
 *means* changes here.
 
 ```bash
-offer=$(pnpm josh backlog:offer --started "$started" --active "$active")   # alias: josh blo
+offer=$(pnpm josh backlog:offer --started "$started" --active "$active")
 offer=$(pnpm josh backlog:offer --started "$started" --active "$active" --exclude 1630,1631)   # after #1630, #1631 merged
 ```
 
@@ -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.**
@@ -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
@@ -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
@@ -35,8 +37,8 @@ Review results and successful pushes are never turn boundaries.
    **`pnpm josh followup` refuses the merge until the round is recorded**
    (`pnpm josh review:record --check --issue <N>`, joshuafolkken/kit#2343).
 5. **The clean path ships in one call** — with no second round due, background
-   `pnpm josh ship "<title> #<N>" --body-file <evidence.md>`: gate → `git -y` → foreground `followup` → `run:tail`, stopping at the
-   first failure (joshuafolkken/kit#2398). `--review` runs both rounds (#2489). **Else a due round 2
+   `pnpm josh ship "<title> #<N>" --body-file <evidence.md>`: PR preflight (#2946) → gate → `git -y` →
+   `followup` → `run:tail`, stopping at the first failure (#2398). `--review` runs both rounds (#2489). **Else a due round 2
    does not fit `ship`**: the PR opens between the rounds — background `pnpm josh git -y "<title> #<N>"`, round 2 beside CI, then
    `pnpm josh followup`.
 

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

@@ -84,7 +84,7 @@ pnpm josh notify --task-type failure --issue-url "<issue-url>" --body "<the reas
 **The matching itself is unchanged, and so is the reason it is mechanical.** The instruction the mechanical read replaced was skipped in two runs out of three on the day it was measured, and one of those two could not have succeeded by eye at all: `AI_COPY_DIRECTORIES` holds directories, so a distributed path such as `.claude/skills/workflow-commands/backlogrun.md` appears in no list textually.
 
 ```bash
-pnpm josh sync:scope    # managed | clean, naming which list claimed each path; alias: josh sys
+pnpm josh sync:scope    # managed | clean, naming which list claimed each path
 ```
 
 - **There is no flag to pass and nothing to approve.** `--managed-config-ignore-reason` is gone with the stop it existed to get past.
@@ -99,7 +99,7 @@ pnpm josh sync:scope    # managed | clean, naming which list claimed each path;
 **The answer: `pnpm josh release:scope`.**
 
 ```bash
-pnpm josh release:scope          # → required | skip | unknown ; alias: josh res
+pnpm josh release:scope          # → required | skip | unknown
 pnpm josh release:scope --json   # the same answer as one JSON object
 ```
 
@@ -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
@@ -63,7 +63,8 @@ call reports `hold`.
   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`.
+- **`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,48 @@ 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. **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>` /
+3. **Ask the session boundary** — `pnpm josh cost --cut` (folded into `run:entry`); `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
    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
    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 +69,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

@@ -12,7 +12,7 @@ delegated unit executing `fullrun`'s procedure, and the hook keys its once-per-r
 same turn as whatever else the run already needs:
 
 ```bash
-pnpm josh issue:read <N> [<N> ...]     # body and comments, one call per batch; alias: josh ird
+pnpm josh issue:read <N> [<N> ...]     # body and comments, one call per batch
 gh api repos/{owner}/{repo}/issues/<N>/comments --jq '.[] | {user: .user.login, created_at, body}'
 ```
 
@@ -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

@@ -82,4 +82,4 @@ found once — fix it forward before parking the issue for it.
 
 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`,