@joshuafolkken/kit 1.1514.0 → 1.2114.0

package/prompts/collaboration-workflow/operating-rules.md

@@ -2,7 +2,6 @@
 
 - 通知は CI チェック成功後に投稿する
 - 通知投稿に失敗しても、実装完了の事実をログで確認できるようにする
-- 自動投稿する Issue コメントは `JOSH_SESSION_LANG` の言語（未設定なら `ja`）で書く。Issue タイトルだけは英語
 
 ### CI チェック失敗時の対応
 
@@ -12,19 +11,28 @@
 - 修正できたら修正内容を、できなかったら失敗チェック名・原因・未解決である旨を `--notify-message` に書く。**完了コメントに失敗を隠してはならない**
 - ユーザーへの報告でも失敗を「成功」として扱わない
 
+### git-rules — コミット・共有状態・index・PR
+
+`CLAUDE.md` → "Git Rules" の本文。フックが拒否・書き換えする（`pnpm josh rule:list` の `josh-git-bare`・`direct-pr-create`・`pr-merge` 行と `.claude/settings.json` の deny）。
+
+- **コミットは指示されたときだけ。** マージ・ブランチ削除・force push などの共有状態の変更は、そのターンで指示されたときだけ。例外は `fullrun` / `backlogrun` の起動で、`pnpm josh followup` 経由のマージを認める（`prrun` は認めない）。deny は規則より狭い — ツールが通したことを許可と読まない
+- **git index は自分の判断で変えない** — 明示の指示か `pnpm josh git` 経由だけ（下記 "no-self-staging"）
+- **コミットは `pnpm josh git`、PR は `pnpm josh pr`** — `gh pr create` の直接実行は `direct-pr-create` 行が拒否する。GitHub 操作は `gh api`（REST） — [`gh-rest.md`](./gh-rest.md)
+- **作業ツリーの前提で動く前に `git status`（と `git stash list`）をその場で実行する**
+
 ### 指示されていない行動は取らない
 
-`CLAUDE.md` → "Git Rules" の細則。対象には共有ブランチへの push・外部通知の追加送信・リポジトリ設定の変更も含む。
+上記 "git-rules" の細則。対象には共有ブランチへの push・外部通知の追加送信・リポジトリ設定の変更も含む。
 
 - auto-merge の本文は [`followup.md`](../../.claude/skills/workflow-commands/followup.md)、`backlogrun` の子への継承は [`backlogrun-child.md`](../../.claude/skills/workflow-commands/backlogrun-child.md)
 - `kickoff` / `pnpm josh followup` 単独実行は文書化されたスコープで終了する。PR が OPEN のまま完了したら状態を報告して停止する
 - 「チェックが全部 green」は次へ進む承認ではない
-- **deny と配送ガードは実装であって規則ではない。** `gh pr merge`・force push・ブランチ削除は `.claude/settings.json` の `permissions.deny` と `pnpm josh rule:guard` が拒否する（一覧は [`rule-delivery.md`](./rule-delivery.md) →「配送されている規則」）が、規則より狭い。ツールが通したことを許可と読まない。`fullrun` の auto-merge は `pnpm josh followup` の内部から gh を起動するため影響を受けない
+- **deny と配送ガードは実装であって規則ではない。** `gh pr merge`・force push・ブランチ削除は `.claude/settings.json` の `permissions.deny` と `pnpm josh rule:list` の `git-force` 行が拒否する（一覧は [`rule-delivery.md`](./rule-delivery.md) →「配送されている規則」）が、規則より狭い。ツールが通したことを許可と読まない。`fullrun` の auto-merge は `pnpm josh followup` の内部から gh を起動するため影響を受けない
 - 共有状態に影響する操作（Tier C）は、迷ったら確認する。可逆な実装・設計判断（Tier A）は下記 "decision-autonomy" に従う
 
 ### no-self-staging — git index を勝手に変更しない（自律 staging の禁止）
 
-`CLAUDE.md` → "Git Rules" の細則。index には履歴がなく、上書きされたステージ状態は復元できない。
+上記 "git-rules" の細則。index には履歴がなく、上書きされたステージ状態は復元できない。
 
 - **調査目的の staging はしない。** 読み取り専用コマンドを使う: `git status --short`、`git diff` / `git diff --stat` / `git diff HEAD`、`git diff --staged`、未追跡ファイルは `git diff --no-index /dev/null <new-file>` か直接読む
 - staging してよいのは次の 2 ケースだけ。それ以外は実行せずに確認する:
@@ -38,22 +46,21 @@
   3. 「別パッケージ起因の問題は割り込み Issue で対応する」
   4. `backlogrun` が epic の子を始める前の preflight（`pnpm josh run:hold <N>` が `reclaim` と答えたときの回収 — joshuafolkken/kit#926, joshuafolkken/kit#1965）
 
-  1〜3 は直後に `pnpm josh stash:pop "<メッセージ>"` で復元する。stash は全 work tree が共有する 1 本のスタックなので、位置指定や引数なしの `git stash pop` は使わない（joshuafolkken/kit#2050）。4 は復元しない — 代わりに stash を子の Issue にコメントで記録する（`prerequisite.md` の stash と同じく、記録だけが後で pop させる手がかり）
+  1〜3 は直後に `pnpm josh stash:pop "<メッセージ>"` で復元する（位置指定の pop は `worktree-mutation` 行が拒否する）。4 は復元しない — 代わりに stash を子の Issue にコメントで記録する（`prerequisite.md` の stash と同じく、記録だけが後で pop させる手がかり）
 
 - **会話で作った実装をランへ渡す「引き渡し用の stash」も `pnpm josh stash:pop "<メッセージ>"` で復元する。当てたあと stash は消える**
   - 計画には復元手順としてこの 1 行だけを書く。`git stash apply` / `git stash pop` も「drop しない」という条件も書かない
   - 計画がガードの拒否する復元形を指していたら、実行側は `stash:pop` に読み替えて続行し、Issue コメントに残す（Tier A）。`needs-decision` では止まらない
   - stash を残すのは持ち主の判断だけ。持ち主が計画に理由を書き、ランはそこで止まって確認する
 - staging・index の書き換え・`git commit` の直接実行は deny されており、deny には「そのターンでユーザーが明示指示した」という例外がない。ケース 1 はユーザー自身の端末で実行してもらう。コミットを指示されたら `pnpm josh git` を通す
-- index を守る deny と `pnpm josh rule:guard`（`worktree-mutation`・`index-mutation`・`destructive-command`・`protected-file` 行）も実装である（→「deny と配送ガードは実装であって規則ではない」）
 
 ### decision-autonomy — 意思決定の自律ポリシー（確認停止を減らす）
 
 `CLAUDE.md` → "Decision autonomy" の境界の細則。
 
 - **A と B の判定**: 確認するのは「差が僅差 かつ 後戻りしにくい／アーキテクチャに長く影響する」ときだけ。明確に優位な選択肢は自動で選び、僅差でも安価に巻き戻せる選択は決めて記録して進む
-- 起票した Issue の所属先は、候補が複数の epic に散っていても Tier B ではない（joshuafolkken/kit#1339）。1 つを選び、採用・却下・理由・決定日を Issue と epic の両方に記録する。止まるのは 2 つが本当に甲乙つけがたいときだけ
+- 起票した Issue の所属先は、候補が複数の epic に散っていても Tier A（`.claude/skills/epic-commands/epic-bundle.md`）
 - 自己修正（自分が公開した成果物の事実誤りの訂正、同じセッションで自分が特定した自分の作業の抜けの穴埋め）は Tier A。承認済みの作業の完了・修復に限り、目標の表明や問いで動いてよい意味ではない（→ `principles.md` → "consult-vs-execute"）
 - **Tier C との境界**: マージ・ブランチ削除・force push・スコープ外の変更は、自分が招いた問題でも Tier C。確認を外しても監査証跡は外さない
 - **major のバージョン bump は Tier C**: `pnpm josh bump major` は自分の判断で実行も提案もしない。既定は minor / patch で、major はユーザーがそのターンで明示したときだけ（0.x の major は 1.0.0 になり戻せない）。`josh bump` が版を変えたら、変わった挙動の `docs/` をコミット前に更新する
-- 自動判断の記録: Issue 駆動ワークフロー内では `pnpm josh issue:comment <N> --body-file <path>` で、採用案・不採用の代替案・採用案が優位な理由を書く
+- 自動判断を記録する Issue コメントは `pnpm josh issue:comment <N> --body-file <path>` で投稿する

package/prompts/collaboration-workflow/output-bounds.md

@@ -17,24 +17,23 @@
 - ファイルは範囲を指定する（`sed -n '120,180p' <file>`、または `Read` の `offset` / `limit`）
 - 一覧は件数を絞る（`--limit`、`| head -30`）、JSON は必要な項目だけ取り出す（`gh api … --jq '…'`）
 - 全量が要るときは、ファイルへ落として（`> <file>`）から範囲を読む
+- 退避された `tool-results/<id>.txt` → `grep -n` ／ `sed -n` で読む（`lane-spilled-read` 行、`pnpm josh rule:list`）
 
 ## 切り詰められた出力を、完全な出力として読まない
 
 **検証ゲートと差分は、切り詰められた結果で判断しない。**
 
-- `pnpm josh gate` は合否の 1 行を末尾に出す。失敗の内訳が切れたら、合否行の直前の `full output: <path>` のファイルを読む（joshuafolkken/kit#1227）
+- 検証コマンド（`gate` ／ `check:related` ／ `lint:related` ／ `test:related`）の末尾を読む → 失敗と次のコマンド、`full output: <path>`（`lint:related` には無い）、最終行の合否の順（`scripts/gate/verification-tail.ts`）。内訳が切れたら `full output:` のファイルを読む（joshuafolkken/kit#1227）
+- `pnpm josh test:related` ／ `test:unit` が失敗した → 最後の `failed tests:` 一覧と `full output: <path>` を読む。読むための再実行はしない。直したら、まず要約の `rerun failed:` 行で失敗したファイルだけを回し、関連集合の全体は最後の `check:related` で 1 回だけ回す（`scripts/test/vitest-failure-summary.ts`）
 - 差分には判定行が無い。差分はファイルへ落としてから範囲で読む（`git diff main...HEAD > /tmp/diff.patch && wc -l /tmp/diff.patch`）
 
 ## 検証コマンドをパイプに繋がない（joshuafolkken/kit#1556）
 
-**パイプラインの終了コードは最後のコマンドのものである。** `pnpm josh gate 2>&1 | tail -40` は赤いゲートを成功として返す。**これは `josh gate` の欠陥ではない。** 直すのは呼び出し方である。
+**パイプラインの終了コードは最後のコマンドのものである。** `pnpm josh gate 2>&1 | tail -40` は赤いゲートを成功として返す。**これは `josh gate` の欠陥ではない。** **既定はパイプなしで実行する。** 避けられないなら `set -o pipefail` を前置する。どの形でも、印字された判定行を読む。`piped-verification` 行（`rule-delivery.md`）が強制する。
 
-- **既定はパイプなしで実行する。** 判定行は末尾に出るので、省略されても残る
-- 絞るなら、ファイルへ落として範囲で読む（`pnpm josh gate > /tmp/gate.log 2>&1; tail -40 /tmp/gate.log`）
-- パイプが避けられないなら `set -o pipefail` を前置する
-- どの形でも、印字された判定行を読む。終了コードだけを答えにしない
+境界は判定が残るかどうか: 入力を最後まで読むフィルタ（`tail` ／ `grep` ／ `cut` ／ `sort` ／ `uniq` ／ `wc` ／ `tee`、`exit` も外部コマンドも `<`・`>`・`&`（比較を含む）も使わない `awk`、`p`・`d`・`s///` だけの `sed`）だけのパイプは `;` 鎖の中でも `pipefail` 付きに書き換えて通り、`head`・先頭一致で止まる `grep`・`2>/dev/null` などのリダイレクトを伴う形は拒否される（`scripts/rules/piped-verification.ts`）。
 
-対象は結果が合否を意味するコマンドだけ — `gate` ／ `check` ／ `lint*` ／ `cspell*` ／ `test*` ／ `eval`。**`git log | head` や `gh issue list | head` は対象外であり、意図的にそうしている。** `latest:scope` ／ `review:brief` も、判定ではなく答えを印字するので `$(...)` で受けてよい。`pnpm josh pretool:guard` は、後段が `tail` ／全行読みの `grep` だけの検証パイプラインを `(set -o pipefail; …)` で包み、他のパイプは拒否する（`rule-delivery.md`）。
+対象は結果が合否を意味するコマンドだけ — `gate` ／ `check*` ／ `lint*` ／ `cspell*` ／ `test*` ／ `eval`。**`git log | head` や `gh issue list | head` は対象外であり、意図的にそうしている。** `latest:scope` ／ `review:brief` も、判定ではなく答えを印字するので `$(...)` で受けてよい。
 
 ## 検査
 

package/prompts/collaboration-workflow/plan-comment.md

@@ -1,8 +1,9 @@
 ## Step 3: 計画コメントを記録して通知する
 
 1. 提案を人間が判断する
-2. 採用した計画を Issue に記録する。body が空なら計画をファイルに書き `gh api -X PATCH repos/{owner}/{repo}/issues/<N> --field body=@<path>` で書き込む（本文はパスで渡す — `shell-body.md`）。body があれば `pnpm josh issue:comment <N> --body-file <path>` でコメントする
+2. 採用した計画をファイルに書き、`pnpm josh issue:plan <N> --body-file <path>` で Issue に記録する。書き込み権限のある作成者の body が空なら本文に、それ以外はコメントになる（本文はパスで渡す — `shell-body.md`）
    - 計画が stash の復元を含むときの書き方: `operating-rules.md` → "no-self-staging"
+   - 計画には `### 影響を受ける既存の利用者` が必須（`pnpm josh plan:consumers <識別子...>` が下書きを出す。書き方: `kickoff.md` の手順 4）
 3. Telegram で計画開始を通知する:
 
    ```bash
@@ -15,44 +16,4 @@
    - Issue URL を必ず含め、箇条書きの間に改行を入れる
    - `kickoff` はここで**停止**する（実装に進まない）
 
-4. 作業ツリーに変更（ステージ済みを含む）が既にあれば退避する:
-   ```bash
-   git stash push -u -m "plan: pre-existing changes"
-   ```
-5. メインブランチへ切り替えて最新を取得する:
-   ```bash
-   pnpm josh ms
-   ```
-6. `pnpm josh latest:scope` が `required` と答えたときだけ `pnpm josh latest` を実行し、`dependency-update` スキルに従う（`.claude/skills/workflow-commands/latest-gate.md`）。脆弱性への override は `pnpm-workspace.yaml` の `overrides` に書く（pnpm 11/12 は `package.json` の `pnpm.overrides` を無視する）。
-   ステップ 4 で stash したら、ここでメッセージ指定で復元する（位置指定や引数なしの `git stash pop` は使わない — joshuafolkken/kit#2050）:
-   ```bash
-   pnpm josh stash:pop "plan: pre-existing changes"
-   ```
-7. **作業サマリを提示してから**実装を開始する（`report-format.md` → "作業前サマリはいつ・どう出すか"）。Issue body が埋まっていても提示し、Issue コメントとしては投稿しない。
-8. 実装完了後、lint/test より前に `prompts/refactoring.md` に従い、高・中優先度項目が残らなくなるまでリファクタリングする
-9. 検証ゲート（`CLAUDE.md` の Completion gate）を実行する
-
-`pnpm josh git` を実行する（`-y` で確認プロンプトをスキップ）。**子はバージョンを上げない** — 版を決めるのは `pnpm josh release` だけ（joshuafolkken/kit#1486）。Issue タイトルは実行前に `issue-template.md` の Step 1 冒頭に沿って整える。
-
-```bash
-pnpm josh git -y "<issue-title> #<issue-number>"
-```
-
-### Recovery after failed push (pre-push hook blocked)
-
-If `pnpm josh git -y` fails at the push step, fix the blocking issue and recover with:
-
-```bash
-# 1. Push manually after fixing the issue
-git push --set-upstream origin <branch>
-
-# 2. Create the PR only — closes #N keyword is preserved
-pnpm josh pr
-# equivalent: pnpm josh git -y --skip-commit --skip-push
-```
-
-Do not run `gh pr create` directly — it bypasses `build_body`, which writes `closes #N`.
-
-### レビューからマージまで
-
-レビューは実装したセッションがコミットの前に `pnpm josh review:brief` で始め、`/code-review` は `Agent` ツールのサブエージェントが実行する。周回の上限、残った指摘の振り分けと `pnpm josh epic:bundle`、マージを打つターンは `.claude/skills/workflow-commands/chain-rule.md` → "Run the review-to-merge chain"、"The review runs in a subagent, never a main-line skill load"、方針は `prompts/review.md` → "Review round cap"。**`/code-review` の出力で停止しない。**
+実装からマージまでは [`fullrun-steps.md`](../../.claude/skills/workflow-commands/fullrun-steps.md) の手順に従う。

package/prompts/collaboration-workflow/principles.md

@@ -46,6 +46,11 @@ AI の判断が要らない手順は、AI に読ませて実行させない。
 2. **1 つを悪くするなら、同じ変更の中で別の場所を削って埋め合わせる** — 合計を悪化させない
 3. **それでも両立しないときは、数字を示して利用者に聞く**（Tier B）— 何をどれだけ悪くして、何を得るか
 
+不具合や複雑さへの対策を出すときは、次のようにする。
+
+- 機能や最適化の追加を止める・凍結する・後回しにする案を出さない。順序は優先度ラベルが決める
+- 進化を続けたまま不具合を防ぐ仕組み（単一ソース化、層の統合、不変条件のテスト）を提案する
+
 ## concise-prose — 文章は条件と動作だけを書く
 
 docs・prompts・skills・拒否文・Issue・PR の文章に適用する。
@@ -56,6 +61,15 @@ docs・prompts・skills・拒否文・Issue・PR の文章に適用する。
 - 同じ内容を言い換えて繰り返さない
 - ファイルや節が自分自身を説明する文（「このファイルは〜である」）を書かない
 
+## concise-reply — 対話の回答は結論・要点・次の一手
+
+ユーザーへの回答に適用する。
+
+- 順序: 結論（1〜2 文）→ 表か箇条書き 1 つ → 次の一手
+- 散文（コードブロック・表・箇条書きの外）の上限は `scripts/rules/concise-reply.ts` の `PROSE_LIMIT`。超えた回答は Stop フックの `pnpm josh stop:guard` が書き直させる
+- 仕組みの説明や同じ内容の言い換えを並べない。詳細はファイルや Issue に書く
+- 対象外: 直前の発話に「詳しく」「具体的に」「詳細」がある回答、`pnpm josh run:board --chat` のような固定出力をコードブロックで返す回答、ファイルや Issue に書く成果物
+
 ## consult-vs-execute — 相談と実行を区別する
 
 ユーザーが進め方・理由を尋ねたり目標を述べたりした（「どうすべき？」「how should we…」「なぜ」「〜したい」「〜の方が良い？」）ときは、**分析と推奨のみ**を返し、ファイル編集・Issue 作成などのアクションは取らない。目標の表明は計画の依頼であって、実行の承認ではない。

package/prompts/collaboration-workflow/report-format.md

@@ -6,24 +6,14 @@
 
 ラベルの有無、概要行の字数上限、コードフェンス囲み、概要へのファイルパス・CLI フラグの混入、ケース段と「壊れるとしたら」段の形は、サマリを標準入力で `pnpm josh report:lint` に渡して検査する（`ok` か違反行を印字する — joshuafolkken/kit#2123）。
 
-### 出力はコードフェンスで囲まない（必須）
+### 骨組みは `josh report:template` が印字する
 
-以下のテンプレートは**フェンスの中身だけ**をセッションに書く（空白での桁揃えと単独行の `---` も使わない）。
+作業前サマリと完了報告の骨組みは `pnpm josh report:template summary|done [<path>...]` で印字し、写さない。ラベルは `report:lint` と同じ 1 つのラベル表（`scripts/report/report-labels.ts`）から、`JOSH_SESSION_LANG` の言語で出る（`ja` 以外は英語）。渡したパスは「対象」「変更ファイル」と変更ごとの行を埋め、そのパスに `josh cases` が求める異常系を「壊れるとしたら」の先頭に置く。残る `<…>` だけを書く。
 
-### ラベルはセッション言語に訳し、注釈は付けない（必須）
-
-**(1) ラベルはセッション言語に訳す。** 日本語セッションでの対応:
-
-- `■ Overview` → `■ 概要`
-- `Now` / `Change` / `Check` → `今こうなっている` / `こう直す` / `確かめ方`
-- `Details` → `技術詳細`、`Changes and tests` → `変更とテスト`
-- `Cause` / `Fix` / `Result`（完了報告）→ `原因` / `対応` / `結果`
-- `■ Hand-off`（区切り）→ `■ 区切り`
-- `Done` / `Remaining` / `Why it stopped` / `Next command` → `終わったこと` / `残っていること` / `止めた理由` / `次に打つコマンド`
-
-成果物の散文（Issue 本文、Issue／PR コメント、Telegram 本文）のラベルもこの表で訳す。英語のまま残るのは「出力の言語（`JOSH_SESSION_LANG`）」が挙げた 3 つだけ。
-
-**(2) ラベルに注釈を付けない。** `■ 概要（平易な説明）` は誤り。注意書きはラベルの下の説明文に置く。
+- 出力はコードフェンスで囲まない（空白での桁揃えと単独行の `---` も使わない）
+- ラベルに注釈を付けない。`■ 概要（平易な説明）` は誤り。注意書きはラベルの下の説明文に置く
+- 成果物の散文（Issue 本文、Issue／PR コメント、Telegram 本文）のラベルも、このコマンドが印字するラベルで書く。英語のまま残るのは「出力の言語（`JOSH_SESSION_LANG`）」が挙げた 3 つだけ
+- 区切り（hand-off）のラベルも同じ表にあり、`pnpm josh run:report --handoff` が印字する
 
 ### 作業前サマリはいつ・どう出すか
 
@@ -34,37 +24,18 @@
 
 ### 作業前サマリ（セッション向け・`JOSH_SESSION_LANG` の言語）
 
-```md
-**■ 概要**
-
-- **今こうなっている**: <1文 — 利用者から見て何が起きているか>
-- **こう直す**: <1文 — 手段ではなく、直った後どうなるか>
-- **確かめ方**: <1文 — どう確認するか>
-
-**技術詳細**
-
-- 対象: <触るファイル / モジュール>
-- 方針: <アプローチとその理由>
-- 副作用 / スコープ外: <意図的にスコープ外にした点。なければ省略>
+`pnpm josh report:template summary <触るファイル...>` が印字する。各欄に書くこと:
 
-**変更とテスト**
-
-1. <変更内容> — Test: <Unit|E2E> — `<file path>` — <検証する挙動>
-   - ケース: 正常 / 空・0件 / 1件 / 多数 / 境界 / 不正入力 / 重複 / 順序 / null
-     - 該当しないものは消し、消した理由を添える（例:「重複: 該当なし — 入力は集合なので重複しない」）
-   - 壊れるとしたら:
-     1. <この変更に固有の、壊れうる条件>
-     2. <...>
-     3. <...>
-2. ...
-```
+- 概要の 3 行: 利用者から見て何が起きているか / 手段ではなく直った後どうなるか / どう確認するか
+- 方針はアプローチとその理由、副作用 / スコープ外は意図的に外した点（なければ省略）
+- 変更ごとの行は `<変更内容> — Test: <Unit|E2E> — <テストのファイルパス> — <検証する挙動>`
 
 テスト宣言はケース単位の 2 段で書く（joshuafolkken/kit#2246）。
 
-- 第 1 段（ケース）は固定語彙を並べ、**該当しないものは `該当なし` に続けて理由を書いて消す**
+- 第 1 段（ケース）は固定語彙を並べ、**該当しないものは `該当なし` に続けて理由を書いて消す**（例:「重複: 該当なし — 入力は集合なので重複しない」）
 - 第 2 段（壊れるとしたら）は、この変更に固有の壊れうる条件を**最低 3 件**書く。書けないときは `どう呼ばれても壊れない` と明示する
 - 複数ケースは `it.each` 1 本に畳んでよい
-- 差分が HTTP・プロセス起動・ファイル IO・時間の境界を跨ぐときは、`pnpm josh cases <path...>` が印字する異常系を第 2 段に載せる
+- 差分が HTTP・プロセス起動・ファイル IO・時間の境界を跨ぐとき、または共有状態（`.josh/` 配下・lock）や環境（`process.env`・常駐プロセス）に依存するときは、`pnpm josh cases <path...>` が印字する異常系を第 2 段に載せる。共有状態には同じ状態を読み書きする他のソースが `file:line` で付く
 
 ### 行数予算は編集前に読む
 
@@ -72,46 +43,46 @@
 
 ### 変更対象はまとめて読んでから編集する（joshuafolkken/kit#2202）
 
-**「変更とテスト」が変更対象ファイルを列挙したら、1 回の `pnpm josh read:files <path> [<path> ...]` で読み、続く独立した編集は 1 回の `pnpm josh edit:files -` で送る**（個別の `Edit` は依存する編集・1 件だけの編集・`Write` のとき）。詳細は [`turn-batching.md`](turn-batching.md) →「実装中の独立編集に効く合成コマンド」。
+`pnpm josh read:files` / `edit:files` で畳む — [`turn-batching.md`](turn-batching.md) →「実装中の独立編集に効く合成コマンド」。
 
 ### 完了報告（セッション向け）
 
-```md
-**■ 完了報告**
-
-- **原因**: <1文 — なぜそうなっていたか>
-- **対応**: <1文 — 何をしたか>
-- **結果**: <1文 — 利用者から見て何が変わったか>（v<version>）
+`pnpm josh report:template done <変更したファイル...>` が印字する。各欄に書くこと:
 
-**技術詳細**
-
-- 変更ファイル: <...>
-- テスト結果: <...>
-- 実行証跡: <実行可能な経路を触った変更では、実際に叩いたコマンドとその出力（UI ならスクリーンショット）。無いなら理由>
-- 捕まえられた検証: <不具合修正のみ。その検証の種類を 1 行（2 回目は台帳で昇格, #2448）>
-- 残課題: <なければ「なし」>
-```
+- 概要の 3 行: なぜそうなっていたか / 何をしたか / 利用者から見て何が変わったか（版を添える）
+- 実行証跡: 実行可能な経路を触った変更では、実際に叩いたコマンドとその出力（UI ならスクリーンショット）。無いなら理由
+- 捕まえられた検証: 不具合修正のみ。その検証の種類を 1 行（2 回目は台帳で昇格, #2448）
+- 残課題: なければ「なし」
 
 **実行証跡は「動くこと」の証拠であり、gate の緑ではない**（joshuafolkken/kit#2246）。同じ証跡を PR 本文の `## 実機証跡` 節（コマンド＋実出力のフェンス）にも置く。無い実行時の変更は `pnpm josh followup` がマージを拒否する（#2446）。
 
 ### PR 本文の受け入れ条件の対応表
 
-`## 受け入れ条件の対応` 節の行の形（`pnpm josh pr` が識別子つきの `未記入` 行を付け、`pnpm josh followup` が照合する — `scripts/review/acceptance-map.ts`）:
+`## 受け入れ条件の対応` 節の行の形（`pnpm josh pr` が識別子つきの `未記入` 行を付け、`pnpm josh followup` が照合する — `scripts/review/acceptance-map.ts`）。`pnpm josh ship` の経路では、同じ識別子つきの `未記入` 行を `pnpm josh run:prep` / `pnpm josh run:step` の ship 事前要求が出し、同じ行と `## 実機証跡` 見出しを ship 本文の下書き（作業ツリーの git ディレクトリの `josh-ship-body-<N>.md`）にも書く。`--body-file` を省いた ship はこの下書きを本文として読む（`scripts/run/ship/run-ship-body-draft.ts`）:
 
 ```md
 - `ac-1a2b3c4d` <条件> — 満たした: <テスト名・`file:line`・実行出力のいずれか>
 - `ac-5e6f7a8b` <条件> — 見送り: #<切り出した Issue> <理由>
 ```
 
+### PR 本文の消えたテストの処置
+
+`## 消えたテストの処置` 節の行の形（`pnpm josh review:brief` が `Removed tests` として一覧化し、`pnpm josh ship` と `pnpm josh followup` が照合する — `scripts/review/removed-tests.ts`。緑の `pnpm josh test:related` が、テスト名入りの `未記入` 行を ship 本文の下書きに足す — `scripts/run/ship/run-ship-removed-rows.ts`）:
+
+```md
+- `<describe> > <テスト名>` — 置き換え: <いまその振る舞いを守るテスト名>
+- `<describe> > <テスト名>` — 廃止: #<振る舞いの廃止を決めた Issue> <理由>
+```
+
 **`run:carry` の実行証跡は `JOSH_TEMP_ROOT` を新しい一時ディレクトリに向けて取る（必須）。** 状態レコードは本物の run と共有なので、`JOSH_TEMP_ROOT="$(mktemp -d)" pnpm josh run:carry --begin …` のように各コマンドの頭に付ける（`docs/environment-variables.md` → "Runs"）。`run:merge` は main の同期・lane の close・GitHub への書き込みを行うため、これでは切り離せない。
 
 ### 区切りの報告（完了報告と区別する・必須）
 
-`backlogrun` の区切り（hand-off）は完了報告ではない — **`原因` / `対応` / `結果` を使わない**。書式は [`.claude/skills/workflow-commands/backlogrun-handoff-report.md`](../../.claude/skills/workflow-commands/backlogrun-handoff-report.md)。
+`backlogrun` の区切り（hand-off）は完了報告ではない — **`原因` / `対応` / `結果` を使わない**。報告は `pnpm josh run:report --handoff` が印字し、手で書かない（[`.claude/skills/workflow-commands/backlogrun-handoff-report.md`](../../.claude/skills/workflow-commands/backlogrun-handoff-report.md)）。
 
 ### 概要 3 行の書き方（ここが本体）
 
-字数と内部識別子の混入は `report:lint` が検査する。平易にするために語彙と抽象度を制約する:
+平易にするために語彙と抽象度を制約する:
 
 - 専門用語は使わないか、`〜（＝…のこと）` の形でその場で言い換える
 - 変更点の羅列ではなく、原因 → 対応 → 効果の因果で書く
@@ -124,7 +95,7 @@
 - **何かが「古い」「壊れている」「変わらない」と書くときは、その対象を名指しする** — 対象パッケージ名・画面名・出力の種類のいずれかを含める
 - 主語のない「状況」「案内」「問題」「その処理」だけで済ませない
 - 書いてよい具体名: 利用者が画面で目にするもの — パッケージ名、表示されるコマンドの目的、画面名、メッセージの種類
-- 書いてはいけない具体名: 内部識別子 — ファイルパス、関数名・型名、CLI のオプションフラグ
+- 書いてはいけない具体名: 内部識別子（上記「作業前サマリはいつ・どう出すか」）
 
 悪い例は「古いままだと警告が出るのに、案内されたコマンドを実行しても状況が変わらない」（何の話か特定できない）。良い例:
 

package/prompts/collaboration-workflow/residency.md

@@ -24,7 +24,7 @@
 
 > **その規則が効き始める瞬間を、1 件のツール呼び出しとして名指しできるか。**
 
-できるなら、規則本文を常駐から出し、配送ガードの行に `scripts/rules/rule-registry.ts` の項目を添え、[`rule-delivery.md`](./rule-delivery.md) が指す `pnpm josh rule:list` の一覧に載せる（joshuafolkken/kit#1524）。**規則ごとのトリガ行は常駐に残さない** — `CLAUDE.md` には一覧への導線 1 行だけを置く。フックが走らないセッションは一覧を自己点検に使う（`principles.md` →「Claude Code 以外のエージェントでの読み替え」）。
+できるなら、規則本文を常駐から出し、配送ガードの行に説明（`about`）を持たせ、[`rule-delivery.md`](./rule-delivery.md) が指す `pnpm josh rule:list` の一覧に載せる（joshuafolkken/kit#1524）。**規則ごとのトリガ行は常駐に残さない** — `CLAUDE.md` には一覧への導線 1 行だけを置く。フックが走らないセッションは一覧を自己点検に使う（`principles.md` →「Claude Code 以外のエージェントでの読み替え」）。
 
 ### 第 2 問 — skill なしのターンでも効く必要があるか
 
@@ -35,7 +35,8 @@
 ### 残すときの書き方と予算
 
 - **常駐規則は、トリガと導線の 2 つで書く。** **判定は、導線を一度も開かないターンでも常駐の記述だけで正しく振る舞えるかである。**
-- **削ることは移すことであり、削除は理由を示して初めて許される例外である。** 先に導線の先へ移し、マーカーテストも付け替える。移さず引退させてよいのは 3 条件がすべて揃うときだけ — 同じ文書に単一ソースが宣言された文の写しである・単一ソースと突き合わせてほかにない文を含まない・マーカーテストが固定していない。揃わなければ候補と証拠を記録して規則は残す
+- **削ることは移すことであり、削除は理由を示して初めて許される例外である。** 先に導線の先へ移し、マーカーテストも付け替える。写しを移さず引退させてよいのは 3 条件がすべて揃うときだけ — 同じ文書に単一ソースが宣言された文の写しである・単一ソースと突き合わせてほかにない文を含まない・マーカーテストが固定していない。揃わなければ候補と証拠を記録して規則は残す
+- 写しのほかに、`pnpm josh rule:value --fresh` の `candidates:` 節も引退（`retire`）・導線 1 行への縮約（`condense`）の根拠になる。判定は `scripts/rules/rule-value-candidates.ts`。候補ごとに Issue を分け、残すなら理由を記録する
 - 経緯（Issue 番号・なぜ・計測・却下案）は `docs/maintainers/<topic>-rationale.md` に置き、その冒頭で説明する手順文書を名指しする。**参照の向きは根拠 → 手順だけ** — AI が読む文書から根拠文書は指さない（`scripts/document/rationale-documents.test.ts` が検出する）。Issue 番号引用の件数は `scripts/document/issue-citation-budget.ts` のラチェットに従う — 減らしたら記録も下げる
 - 引用は本文があるファイルを直接指す
 - 予算が詰まったら回収で解く。**引き上げは Tier C として扱う** — `RESIDENT_CEILING_BYTES`・`RESIDENT_HEADROOM_BYTES`・`RE_INLINE_GUARD_HEADROOM_BYTES` の緩和は、3 条件（回収の余地が尽きたことを計測で示す・需要が 1 規則ではなく常駐すべき規則数の増加から来る・増やす量は需要と回収可能量の差だけで丸めない）を示し、ユーザーの明示指示を得てから行う。条件が揃うこと自体は指示ではない

package/prompts/collaboration-workflow/rule-delivery.md

@@ -14,10 +14,22 @@
 
 一覧は `pnpm josh rule:list` が `scripts/rules/delivered-rules.ts` から生成する（joshuafolkken/kit#3399）。各項目は規則の単一ソース・発火点・発火しないときを持ち、フックが走らないエージェントはその出力を自己適用のチェックリストにする（`principles.md`）。
 
-**引き金はシェルのコマンド文字列しか見えない**（node 内の REST や `gh api --input <file>` は掛からない）ので、常駐側にトリガ 1 行を残す。
+**引き金はシェルのコマンド文字列しか見えない**（node 内の REST は掛からず、`gh api --input <file>` のファイルの中身を読むのは `credential-body` だけ）ので、常駐側にトリガ 1 行を残す。
 
 引き金が発火しないターンでは何も起きないのが仕様で、各項目の発火しない状態は「規則が守られている状態」と一致させる。一致が取れない規則は常駐に残す。
 
+## stop-notify — 途中停止の通知（`confirmation`）
+
+`CLAUDE.md` → "Mid-workflow stop notification" の本文（`pnpm josh rule:list` の `stop-notify` 行）。保持中のランが判断待ちで止まるとき、Stop フックの `pnpm josh stop:guard` が `confirmation` を送る — 理由を先頭に、末尾は `Recommended: <choice>`。フックが停止を拒否したときだけ自分で送る:
+
+```bash
+pnpm josh notify --task-type confirmation --issue-url "<url>" --body=$'<reason>' --recommended "<choice>" --alternative "<other>"
+```
+
+## concise-reply — 回答の長さ
+
+`principles.md` → "concise-reply"（`pnpm josh rule:list` の `concise-reply` 行）。散文が上限を超えた回答の Stop で、`pnpm josh stop:guard` が節の本文付きで 1 度だけ書き直させる。
+
 ## 配送は 1 ラン 1 回
 
 配送文はラン 1 回につき 1 度しか出ないので、**「同じ呼び出しをもう一度出せ」と明記する**。例外: 繰り返す行為を止める項目は毎回発火し（joshuafolkken/kit#1570）、前提の行為を求める項目は前提が末尾に現れるまで毎回拒否する（joshuafolkken/kit#2807）— その配送文にはそれぞれ「これは毎回発火する」「前提が末尾に現れるまで拒否する」と明記する。バッチングと調査の 2 ガードは違反が間隔分続けば再び発火する（joshuafolkken/kit#2164）。前提の証拠を読めないときは拒否する。

package/prompts/collaboration-workflow/shell-body.md

@@ -1,22 +1,10 @@
 ## 本文をシェルの二重引用符に載せない（joshuafolkken/kit#1198）
 
-`CLAUDE.md` からは [`rule-delivery.md`](./rule-delivery.md) →「配送されている規則」を経て届く。[`file-edits.md`](./file-edits.md) が防ぐのはコストの二重払い、こちらが防ぐのは**テキストが実行されること**である。
-
-### 何が起きるのか
-
-二重引用符の中のバッククォートと `$` は実行前に評価される。次の呼び出しは `pnpm josh ms` を実行し、その出力を本文に埋め込む。
-
-```bash
-gh api repos/{owner}/{repo}/issues/1535/comments -f body="… `pnpm josh ms` は …"
-```
-
-`pnpm josh followup --notify-message "…"` も同じく壊れる。
-
-発火するのは `` ` `` と `$` で、`!` ではない。
+防ぐのは本文の**テキストが実行されること**である。二重引用符の中の `` ` `` と `$` は実行前に評価される（`!` は評価されない）。
 
 ### 安全な書き方
 
-**本文をファイルに書いて、パスで渡す。**
+**本文をファイルに書いて、パスで渡す。** `--body-file` の本文や計画メモは `.josh/tmp/` に置く（ignore 済みなのでコミットに混ざらない）。
 
 ```bash
 pnpm josh issue:comment <N> --body-file <path>
@@ -29,7 +17,9 @@ PR コメントも `pnpm josh issue:comment <N> --body-file <path>` で投稿す
 
 ### コメント投稿は `pnpm josh issue:comment` の 1 綴りだけ（joshuafolkken/kit#2304）
 
-`gh api` の `-f body=@<path>` ／ `--raw-field body=@<path>` は `@<path>` というリテラルを黙って投稿する。**Issue／PR コメントの投稿は `pnpm josh issue:comment <N> --body-file <path>` ただ 1 綴りに寄せる。** `-f body=@…` は `pnpm josh rule:guard` が実行前に拒否する（`raw-field-body` 行、`scripts/rules/raw-field-body.ts`）。Issue body 書き換えの `-X PATCH ... --field body=@<path>` は `-F` 側で安全なのでそのまま使う。
+自リポジトリへの `gh issue comment` / `gh api` コメント投稿 → `direct-issue-comment` 行が拒否する（`scripts/rules/direct-issue-comment.ts`）。
+
+`-f body=@<path>` は `@<path>` というリテラルを投稿するので、`raw-field-body` 行が拒否する。Issue body 書き換えの `--field body=@<path>` は安全なのでそのまま使う。
 
 `--body-file` / `--notify-message-file` は `-` で標準入力を読む（実装は `scripts/josh/cli-body.ts`）。`--body` と `--body-file` の同時指定は拒否される。
 
@@ -37,4 +27,4 @@ PR コメントも `pnpm josh issue:comment <N> --body-file <path>` で投稿す
 
 ### 引き金つき配送
 
-`pnpm josh rule:guard` は、二重引用符の本文値にバッククォートか `$` を含む `Bash` 呼び出しを拒否する。拒否されたら本文をファイルに移して出し直す。**引き金が見えない綴り（`-b`・`-f title=` など）でも、フックが走らないエージェントでも規則は同じく拘束する。**
+`shell-body` 行が強制する。引き金が見えない綴り（`-b`・`-f title=` など）でも規則は同じく拘束する。

package/prompts/collaboration-workflow/turn-batching.md

@@ -1,7 +1,5 @@
 # 独立した呼び出しは同じターンに載せる（joshuafolkken/kit#1304）
 
-常駐側には [`rule-delivery.md`](./rule-delivery.md) →「配送されている規則」への導線だけが残り、規則本文は `pnpm josh batch:guard` が効く瞬間に配送する。
-
 ## 何を求めているか
 
 > **この呼び出しの入力は、いま出していない別の呼び出しの結果に依存しているか。**

package/prompts/collaboration-workflow/upstream-interrupt.md

@@ -14,7 +14,7 @@
 
 **実行中のリポジトリ自身はこの手順の対象外である。** kit の中で kit のラン機構（`backlog:drive`、`run:wake`、`run:carry`、レーン、分類、カウンタ、ガードなど）の不具合を見つけたら、上流 Issue で停止する代わりに、このリポジトリの割り込みとして次を行う。
 
-1. **起票する** — `pnpm josh issue:file "<title>" --body-file <path> --depth <n> --route interrupt --label priority:high`。上限は効かない（`wip-cap.md` →「割り込み起票 — 上限が効かない側」の条件 2）
+1. **起票する** — `pnpm josh issue:file "<title>" --body-file <path> --route interrupt --label priority:high --blocks-finder`。上限は効かない（`wip-cap.md` →「割り込み起票 — 上限が効かない側」の条件 2）
 2. **止まらずに直す** — 壊れた機構を迂回せず、検証ゲートも緩めない。`backlogrun` の中では割り込みを次の子にし、着地後に塞がれていた子へ戻る（プールでは `priority:high` が先頭、epic の下では `wip-cap.md` の手順 3 で挿入、名前指定のランでは `pnpm josh lane:launch <N>` で自分で dispatch）。バッチの外では `wip-cap.md` の手順 4 どおり、打つべき `fullrun #<N>` を報告して止まる
 3. **再開できるなら自分で再開し、動くことを確かめる** — 修正のマージ後、手渡し済み・所有者が死んだ記録・監督プロセスの停止（`warning` Telegram）には `pnpm josh run:wake --start`、`run:carry` の `standing` には `pnpm josh run:carry --resume "<invocation>" --owner "$PPID"` を打つ。`pnpm josh run:wake --list` が監督プロセスを示し、ログに次の子の dispatch が現れることを確かめて報告する
 4. **人に打ち直しを求めるのは再開の手段が無いときだけ** — `mismatch`（別の起動の記録）、別の生きた所有者の `busy`。新しい承認を宣言するのは人だけ
@@ -22,15 +22,25 @@
 
 手順:
 
-1. **現在の作業を退避する**: `git stash push -u -m "upstream-interrupt: paused #<N>"`（WIP コミットでも可）
+1. **現在の作業を退避する**: `pnpm josh stash:push "upstream-interrupt: paused #<N>"`（WIP コミットでも可）
 2. **進行中の Issue に状況を書く**: `pnpm josh issue:comment <N> --body-file <path>` で、stash したこと、中断理由（どの別パッケージのどんな問題か）、新 Issue へのリンク（`## Upstream issues` 見出しの下に `owner/repo#N` 形式、→「起票元へのバックリンク」）
-3. **対象パッケージのリポジトリに Issue を作成する（確認なし）**: `pnpm josh issue:file "<root-cause title>" --body-file <body-file> --depth <n> --route tier-a --repo <owner>/<repo>`（joshuafolkken/kit#1083）。検査・分類ラベル・重複探し・`epic:bundle` はコマンドが行う（`docs/josh-commands-backlog.md` → `josh issue:file`）。根本原因・再現・期待結果を `prompts/collaboration-workflow/issue-template.md` の Step 1 のテンプレで書き、`## Origin` 節に起票元 Issue を `owner/repo#N` 形式で書く
-4. **`confirmation` Telegram を送って停止する**: 上流 Issue の URL と何が止まっているかを書く（→ `CLAUDE.md` → "Mid-workflow stop notification (`confirmation`)"）
+3. **対象パッケージのリポジトリに Issue を作成する（確認なし）**: `pnpm josh issue:file "<root-cause title>" --body-file <body-file> --route tier-a --repo <owner>/<repo>`（joshuafolkken/kit#1083）。検査・分類ラベル・重複探し・`epic:bundle` はコマンドが行う（`docs/josh-commands-backlog.md` → `josh issue:file`）。根本原因・再現・期待結果を `prompts/collaboration-workflow/issue-template.md` の Step 1 のテンプレで書き、`## Origin` 節に起票元 Issue を `owner/repo#N` 形式で書く
+4. **`confirmation` Telegram を送って停止する**: 上流 Issue の URL と何が止まっているかを書く（→ `rule-delivery.md` → "stop-notify"）
 5. **元の作業を再開する**: 上流の修正がマージされた、またはユーザーが先送りを明示判断した後に `pnpm josh stash:pop "upstream-interrupt: paused #<N>"` で復元する（`operating-rules.md` → "no-self-staging"）。上流 Issue を割り込みで実装するかもユーザーが決める
 
+### first-party の Issue・PR への書き込みは確認不要
+
+`pnpm josh repo:party` が `first-party` と答えたリポジトリの Issue・PR への書き込みは Tier A で、ユーザーに確認しない。起票、コメント、ラベル、本文の編集、`@dependabot rebase` などの Dependabot へのコマンドコメントを含む。
+
+- 頼まれていない観察の起票はこの節で許可しない: この節が外すのは書き込み先の確認だけ。起票するかは `.claude/skills/workflow-commands/observation-filing.md` に従う
+- `unknown` はこの節の対象外: first-party と判定できないので、書き込む前にユーザーに確認する
+
+- **「外部への書き込み」は third-party への書き込みだけを指す**。first-party への書き込みをそう呼ばない
+- マージ・ブランチ削除などの共有状態の操作は書き込みに含まれず、Tier C のまま（`CLAUDE.md` → "Git Rules"）
+
 ### 第三者リポジトリへの書き込みは Tier C（明示指示が必要）
 
-「起票は確認なし」は first-party だけに成り立つ。
+「起票は確認なし」も「書き込みは確認不要」も first-party だけに成り立つ。
 
 - **判定は `pnpm josh repo:party [<owner/repo>]` が答える**: `first-party` / `third-party` / `unknown`（unknown は third-party 扱いしない）。fork や contribute しているだけの org リポジトリも third-party
 - **third-party への書き込みは種別を問わず Tier C**: Issue・コメント・PR・Discussion・レビュー、既存 Issue のクローズ・編集も、その turn のユーザーの明示指示なしに行わない。正しい診断も許可ではない

package/prompts/collaboration-workflow/wip-cap.md

@@ -55,11 +55,13 @@
 1. **上限に関係なく起票する。** 1 件閉じることを条件にしない。本文の検査、分類ラベルの付与、重複探し、`epic:bundle` はコマンドが行う（`docs/josh-commands-backlog.md` → `josh issue:file`）。
 
    ```bash
-   pnpm josh issue:file "<title>" --body-file <body-file> --depth <n> --route interrupt
+   pnpm josh issue:file "<title>" --body-file <body-file> --route interrupt
    ```
 
+   `--blocks-finder` は付けない。発見したランを塞がない割り込みに起票元の `blocked-by` を書くと、偽の依存関係になる。
+
 2. 超過している事実と当たった条件の番号を、両方とも本文に 1 行書く（例:「オープン 37 件で起票。3 条件のうち 2（文書化された手順が完了できない）に該当」）。
-3. 次に実行されるものとして挿入する。epic の下なら `pnpm josh epic --add <E> <N>` で**位置を指定せずに**追加する（`<E>` が epic、`<N>` が割り込み）。**`--before` / `--after` を使ってはならない。** それらは `blocked-by` を書き込み、**偽の依存関係**になる。**順序は実行側が持つ** — 先に提示させたいときは行だけを動かす `--order-before <M>` を使う。**epic の下に無いなら挿入先そのものが無い**ので、4 だけを行う。
+3. 次に実行されるものとして挿入する。epic の下なら `pnpm josh epic --add <E> <N>` で**位置を指定せずに**追加する（`<E>` が epic、`<N>` が割り込み）。**`--before` / `--after` を使ってはならない。** それらは `blocked-by` を書き込み、**偽の依存関係**になる。**順序は実行側が持つ** — 先に提示させたいときは行だけを動かす `--order-before <M>` を使う。**epic の下に無いなら挿入先そのものが無い**ので、4 だけを行う。`--blocks-finder` の割り込みを追加したら → `pnpm josh epic --reconcile <E>`（`docs/josh-commands-backlog.md` → `josh issue:file` の `--blocks-finder`）。
 4. 着手は既にある承認の内側でのみ、指示を待たずに行う。`backlogrun` の中なら次の子として着手してよい。バッチの外では `CLAUDE.md` →「Explicit invocation required」が効き、起票と挿入まで済ませて打つべきコマンド（`fullrun #<N>`）を報告して止まる。**割り込みは上限の例外であって、明示起動規則の例外ではない。**
 
 起票と、実行されるようにするところまでが 1 つのまとまりである — epic の下で追加しなければ `epic:next` は候補に出さない。**epic の外にある割り込みでは、まとまりの後半は 4 の報告そのもの**である。

package/prompts/collaboration-workflow.md

@@ -1,13 +1,8 @@
 # Issue-Driven Collaboration Workflow
 
-複数の AI ツール（Claude / Cursor / Gemini）で共通に使う Issue 駆動ワークフローの**索引**。
+複数の AI ツール（Claude / Cursor / Gemini）で共通に使う Issue 駆動ワークフローの**索引**。人間が読むための索引であり、規則を定める場所ではない。必要な 1 本だけを開く。
 
-## この索引の使い方
-
-人間が読むための索引であり、規則を定める場所ではない。常駐の引き金は `CLAUDE.md`、実行中の手順は `.claude/skills/workflow-commands/`、各話題の規則は下表のファイルが一次情報である。
-
-- 下表から必要な 1 本だけを開く。
-- 他の文書から話題を指すときは、索引でなく**本文があるファイルを直接指す**（[`residency.md`](./collaboration-workflow/residency.md)）。
+他の文書から話題を指すときは、索引でなく**本文があるファイルを直接指す**（[`residency.md`](./collaboration-workflow/residency.md)）。
 
 | 話題                                                       | ファイル                                                                  |
 | ---------------------------------------------------------- | ------------------------------------------------------------------------- |
@@ -27,6 +22,7 @@
 | 常駐ドキュメントと skill の分担                            | [`residency.md`](./collaboration-workflow/residency.md)                   |
 | 引き金つき配送 — 規則を効く瞬間に届ける                    | [`rule-delivery.md`](./collaboration-workflow/rule-delivery.md)           |
 | コマンド出力が文脈へ持ち込む量の上限                       | [`output-bounds.md`](./collaboration-workflow/output-bounds.md)           |
+| 所要時間は記録から測る                                     | [`measurement.md`](./collaboration-workflow/measurement.md)               |
 | 運用ルール                                                 | [`operating-rules.md`](./collaboration-workflow/operating-rules.md)       |
 | 用語集 — lane・cut・hold・park など                        | [`glossary.md`](./collaboration-workflow/glossary.md)                     |
 | headless のレーン子・レビューの起動時の規則セット          | [`lane-instructions.md`](./collaboration-workflow/lane-instructions.md)   |

package/prompts/refactoring.md

@@ -90,4 +90,4 @@ lint が一部の面しか見ない項目だけを挙げる。コーディング
 
 ## 実装後の品質保証（絶対遵守）
 
-実装後は `read_lints` → `pnpm run lint` の順で全関与ファイルを確認し、エラー0件になるまで修正する。エラーが残ったまま完了報告しない。
+実装後は `pnpm josh lint:related` → `pnpm josh gate` の順で全関与ファイルを確認し、エラー0件になるまで修正する。エラーが残ったまま完了報告しない。レーン子の gate は `josh ship` が回す（`.claude/skills/workflow-commands/chain-rule.md` → "Run the review-to-merge chain" step 0）。

package/prompts/review-rubric.md

@@ -88,6 +88,8 @@ For each finding:
 - Cite `file_path:line_number`
 - State severity (`high` / `medium` / `low`) by the two tests in "Severity"
 - Explain the concrete problem and the minimal fix
+- On a `high` or `medium`, cite every other site of the same pattern in the change's files and their
+  callers as `file_path:line_number`, so one fix pass closes them all
 - On a test-1 finding rated `low`, write `no failure scenario — <what you tried>`
 
 A category with no findings needs a proof statement, e.g. `No issues — checked null returns on X,
@@ -139,6 +141,9 @@ Actively try to break the changed code.
 - Impact outside the diff: open the callers of every changed export or signature and verify they still
   hold; flag duplication the change introduces
 - Regressions in existing behavior covered elsewhere
+- Commands the changed prose tells a reader to run, run from a cwd other than the root with absolute,
+  relative and empty inputs, in a scratch copy when they write: `prompts/review.md` → "Before round 1
+  — the implementer's self-check", question 10
 
 **`No issues` requires at least one explicit trace statement.**
 
@@ -171,7 +176,7 @@ switching `no-restricted-syntax` off.
 ### 6. Tests
 
 - Every code change has a corresponding test (unit or E2E) per `CLAUDE.md` Code Change Rules Step 0
-- Test titles are English only and describe behavior, not implementation
+- Test titles describe behavior, not implementation
 - **Mutation check**: for the most critical test added or changed — if the key assertion/condition in
   the implementation were inverted or removed, would it fail? If no or uncertain, rewrite it.
 - **Requirement check**: does the test verify the behavior the issue/task describes, or only that code
@@ -179,7 +184,6 @@ switching `no-restricted-syntax` off.
 
 ### 7. Comments & content
 
-- Comments are English only
 - No narration comments (`// Added for issue #123`, `// TODO: refactor later`) — only non-obvious _why_
 - No duplicated logic that should be extracted
 
@@ -205,6 +209,9 @@ concerns"; if nothing is uncertain, trace the logic path that gives that confide
   not describe.
 - High findings → must fix before committing
 - Medium findings → must fix before opening the PR
+- A finding wholly covered by an open follow-up this Issue filed (a `先送り: #M <title>` comment on
+  it, which `issue:file --found-during <N>` posts) → record it as `low` citing `#M`, never `medium`
+  or `high`, so it does not stop the ship
 - Low findings → document in the PR body if skipped
 
 If the diff is empty or trivial (e.g. whitespace only), state that and skip the review.