@joshuafolkken/kit 1.1471.0 → 1.1784.0

package/prompts/collaboration-workflow/principles.md

@@ -1,7 +1,5 @@
 # 原則
 
-経緯と適用例は [`docs/maintainers/principles-rationale.md`](../../docs/maintainers/principles-rationale.md) の各節にあり、実行中には読まない。
-
 ## no-clones — クローン禁止・単一ソース化
 
 既存の非自明なロジック（別ファイル・別モジュール・上流依存を含む別パッケージにあるもの）を、ソースを変えずに済ませるために**コピー・移植・再実装しない**。複製したくなったら、全消費者が import する共有モジュール／export／パッケージへ単一ソース化する。
@@ -11,14 +9,25 @@
 - 「X を触るな」という制約でクローンを黙って正当化しない。「クリーンな修正は kit の変更が必要、代替はクローン、どちらにする？」と先に提示する
 - 複製は、単一ソース化の代替案とコストを提示し、ユーザーの明示承認を得た後にのみ行う
 
-計測は `pnpm josh clone:scan`（`pnpm josh oracle:list` の決定オラクル）。リポジトリ内と `JOSH_REPO_PATHS` の他リポジトリを跨いだ複製の件数と各 `file:line`（`[same-file|cross-file|cross-repo]`、なしは `clean`）を印字する（`docs/maintainers/principles-rationale.md` → "Why clone:scan exists"）。
+計測は `pnpm josh clone:scan`（`pnpm josh oracle:list` の決定オラクル）。リポジトリ内と `JOSH_REPO_PATHS` の他リポジトリを跨いだ複製の件数と各 `file:line`（`[same-file|cross-file|cross-repo]`、なしは `clean`）を印字する。
 
 ## elegant-design — 設計はエレガント・シンプルを第一目標にする
 
-フック・ガード・ルール・抽象化を足す前に、**原因側を直せばその仕組みが要らなくならないか**を問う。要らなくなるなら足さず、原因を直す。検出・通知・叱責を強化する前に、その入力を生んでいる側を断つ。適用例は `docs/maintainers/principles-rationale.md` → "An application of simplicity-first"。
+フック・ガード・ルール・抽象化を足す前に、**原因側を直せばその仕組みが要らなくならないか**を問う。要らなくなるなら足さず、原因を直す。検出・通知・叱責を強化する前に、その入力を生んでいる側を断つ。
 
 書かれたコードの可読性は `prompts/coding-standards.md` の担当で、ここはどの仕組みをどこへ足すかの規則である。互いの本文を写さず、指すだけにする。
 
+## automate-first — 判断の要らない手順は AI に渡さず自動化する
+
+AI の判断が要らない手順は、AI に読ませて実行させない。規則を足すときは、次の順で最初に成り立つ形を選ぶ。
+
+1. コマンド — 手順そのものを `pnpm josh <command>` にする
+2. フックの自動実行 — フックがその場で実行する、または呼び出しを `updatedInput` で書き換える
+3. 差し戻しガード — 正しい形が呼び出しから決まらないときだけ拒否する
+4. 文書 — 上の 3 つのどれも成り立たないときだけ書く
+
+下の段を選ぶときは、上の段が成り立たない理由を示す。配置の問いは `residency.md` →「自動化の問い」、ガードの理由は `scripts/rules/guard-remedy.ts` の `why` に書く。
+
 ## quality-priority — 品質目標が衝突したときの優先順位
 
 上の段は、下の段のために犠牲にしない。
@@ -37,18 +46,21 @@
 2. **1 つを悪くするなら、同じ変更の中で別の場所を削って埋め合わせる** — 合計を悪化させない
 3. **それでも両立しないときは、数字を示して利用者に聞く**（Tier B）— 何をどれだけ悪くして、何を得るか
 
+不具合や複雑さへの対策を出すときは、次のようにする。
+
+- 機能や最適化の追加を止める・凍結する・後回しにする案を出さない。順序は優先度ラベルが決める
+- 進化を続けたまま不具合を防ぐ仕組み（単一ソース化、層の統合、不変条件のテスト）を提案する
+
 ## concise-prose — 文章は条件と動作だけを書く
 
 docs・prompts・skills・拒否文・Issue・PR の文章に適用する。
 
 - 本文には、いつ何をするか（条件と動作）だけを書く
-- 理由と経緯は rationale 文書に置き、本文からは見出しで指す
+- 理由と経緯は rationale 文書に置き、本文からは指さない — 根拠文書（`docs/maintainers/`）の側から手順を指す
 - 太字は 1 節に 1 つまで。箇条書き先頭の見出し語は数えない。`→ "…"` で引かれている太字は消さない
 - 同じ内容を言い換えて繰り返さない
 - ファイルや節が自分自身を説明する文（「このファイルは〜である」）を書かない
 
-導入時のベースラインは `docs/maintainers/principles-rationale.md` → "Why concise-prose exists"。
-
 ## consult-vs-execute — 相談と実行を区別する
 
 ユーザーが進め方・理由を尋ねたり目標を述べたりした（「どうすべき？」「how should we…」「なぜ」「〜したい」「〜の方が良い？」）ときは、**分析と推奨のみ**を返し、ファイル編集・Issue 作成などのアクションは取らない。目標の表明は計画の依頼であって、実行の承認ではない。
@@ -87,7 +99,6 @@ docs・prompts・skills・拒否文・Issue・PR の文章に適用する。
 **規則の本体は `CLAUDE.md` にしか無い。** `AGENTS.md`・`GEMINI.md`・`.cursorrules` は「規則は `CLAUDE.md` にある。作業前に全文を読むこと」と「規則を書き戻さない」だけを書いた導線である（`.cursorrules` は Svelte MCP の案内だけを足す）。
 
 - 規則の追加・変更・節の追加は `CLAUDE.md` に 1 回だけ書き、導線文書には書き戻さない
-- 経緯と機械的な検査は `docs/maintainers/principles-rationale.md` → "Why AGENTS and GEMINI are pointers"、`@CLAUDE.md` 行と他ツールでの未検証は `docs/maintainers/principles-rationale.md` → "The include line, and what has not been verified"
 
 ### Claude Code 以外のエージェントでの読み替え
 

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,37 +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
-**■ 完了報告**
+`pnpm josh report:template done <変更したファイル...>` が印字する。各欄に書くこと:
+
+- 概要の 3 行: なぜそうなっていたか / 何をしたか / 利用者から見て何が変わったか（版を添える）
+- 実行証跡: 実行可能な経路を触った変更では、実際に叩いたコマンドとその出力（UI ならスクリーンショット）。無いなら理由
+- 捕まえられた検証: 不具合修正のみ。その検証の種類を 1 行（2 回目は台帳で昇格, #2448）
+- 残課題: なければ「なし」
 
-- **原因**: <1文 — なぜそうなっていたか>
-- **対応**: <1文 — 何をしたか>
-- **結果**: <1文 — 利用者から見て何が変わったか>（v<version>）
+**実行証跡は「動くこと」の証拠であり、gate の緑ではない**（joshuafolkken/kit#2246）。同じ証跡を PR 本文の `## 実機証跡` 節（コマンド＋実出力のフェンス）にも置く。無い実行時の変更は `pnpm josh followup` がマージを拒否する（#2446）。
 
-**技術詳細**
+### PR 本文の受け入れ条件の対応表
 
-- 変更ファイル: <...>
-- テスト結果: <...>
-- 実行証跡: <実行可能な経路を触った変更では、実際に叩いたコマンドとその出力（UI ならスクリーンショット）。無いなら理由>
-- 捕まえられた検証: <不具合修正のみ。その検証の種類を 1 行（2 回目は台帳で昇格, #2448）>
-- 残課題: <なければ「なし」>
+`## 受け入れ条件の対応` 節の行の形（`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> <理由>
 ```
 
-**実行証跡は「動くこと」の証拠であり、gate の緑ではない**（joshuafolkken/kit#2246）。同じ証跡を PR 本文の `## 実機証跡` 節（コマンド＋実出力のフェンス）にも置く。無い実行時の変更は `pnpm josh followup` がマージを拒否する（#2446）。
+### 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` が検査する。平易にするために語彙と抽象度を制約する:
+平易にするために語彙と抽象度を制約する:
 
 - 専門用語は使わないか、`〜（＝…のこと）` の形でその場で言い換える
 - 変更点の羅列ではなく、原因 → 対応 → 効果の因果で書く
@@ -115,7 +95,7 @@
 - **何かが「古い」「壊れている」「変わらない」と書くときは、その対象を名指しする** — 対象パッケージ名・画面名・出力の種類のいずれかを含める
 - 主語のない「状況」「案内」「問題」「その処理」だけで済ませない
 - 書いてよい具体名: 利用者が画面で目にするもの — パッケージ名、表示されるコマンドの目的、画面名、メッセージの種類
-- 書いてはいけない具体名: 内部識別子 — ファイルパス、関数名・型名、CLI のオプションフラグ
+- 書いてはいけない具体名: 内部識別子（上記「作業前サマリはいつ・どう出すか」）
 
 悪い例は「古いままだと警告が出るのに、案内されたコマンドを実行しても状況が変わらない」（何の話か特定できない）。良い例:
 

package/prompts/collaboration-workflow/residency.md

@@ -1,6 +1,6 @@
 ## 常駐ドキュメントと skill の分担（何を常駐に残すか）
 
-規則を置く・移す・引退させるターンに読む（joshuafolkken/kit#2891）。規則のトリガは `CLAUDE.md` に 1 度だけ、手順と数値は導線の先に 1 度だけ書く。`CLAUDE.md` の上限は `scripts/document/resident-budget.ts` の `RESIDENT_CEILING_BYTES`（残りは `pnpm josh bytes CLAUDE.md`）。**置き場所は重要度ではなく、下の問いを順に当てて決める。** 経緯は `docs/maintainers/claude-md-history.md` と `docs/maintainers/residency-rationale.md`。
+規則を置く・移す・引退させるターンに読む（joshuafolkken/kit#2891）。規則のトリガは `CLAUDE.md` に 1 度だけ、手順と数値は導線の先に 1 度だけ書く。`CLAUDE.md` の上限は `scripts/document/resident-budget.ts` の `RESIDENT_CEILING_BYTES`（残りは `pnpm josh bytes CLAUDE.md`）。**置き場所は重要度ではなく、下の問いを順に当てて決める。**
 
 ### 第 0 問（先に問う）
 
@@ -14,11 +14,17 @@
 
 そうであれば、規則はドライバの状態遷移に書き、文書は導線 1 行だけにする。`pnpm josh run:step <N>` が次の 1 手を計算する（`scripts/run/run-step.ts`、joshuafolkken/kit#2248）。
 
+### 自動化の問い（順序の問いの次に問う）
+
+> **その手順は、AI の判断なしに実行できるか。**
+
+できるなら、コマンドかフックの自動実行にし、文書にも差し戻しガードにもしない（`principles.md` →「automate-first」）。文書やガードとして置くのは、自動化できない理由を示せるときだけである。ガードの理由は `scripts/rules/guard-remedy.ts` の `why` が必須項目として持ち、`pnpm josh rule:list` が `not automated` として印字する。理由のないガードは `guard-remedy.test.ts` が落とす。
+
 ### 第 1 問 — 引き金を名指しできるか
 
 > **その規則が効き始める瞬間を、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 以外のエージェントでの読み替え」）。根拠は `docs/maintainers/residency-rationale.md` → "Why a delivered rule leaves no resident line"。
+できるなら、規則本文を常駐から出し、配送ガードの行に説明（`about`）を持たせ、[`rule-delivery.md`](./rule-delivery.md) が指す `pnpm josh rule:list` の一覧に載せる（joshuafolkken/kit#1524）。**規則ごとのトリガ行は常駐に残さない** — `CLAUDE.md` には一覧への導線 1 行だけを置く。フックが走らないセッションは一覧を自己点検に使う（`principles.md` →「Claude Code 以外のエージェントでの読み替え」）。
 
 ### 第 2 問 — skill なしのターンでも効く必要があるか
 
@@ -29,9 +35,7 @@
 ### 残すときの書き方と予算
 
 - **常駐規則は、トリガと導線の 2 つで書く。** **判定は、導線を一度も開かないターンでも常駐の記述だけで正しく振る舞えるかである。**
-- **削ることは移すことであり、削除は理由を示して初めて許される例外である。** 先に導線の先へ移し、マーカーテストも付け替える。引退の 3 条件は `docs/maintainers/residency-rationale.md` → "Trigger and pointer, and the narrow retirement route"
-- 経緯（Issue 番号・なぜ・計測・却下案）は `docs/maintainers/<topic>-rationale.md` に置く。Issue 番号引用の件数は `scripts/document/issue-citation-budget.ts` のラチェットに従う — 減らしたら記録も下げる（`docs/maintainers/residency-rationale.md` → "The issue-citation ratchet"）
-- 引用は本文があるファイルを直接指す（`docs/maintainers/residency-rationale.md` → "A pointer-only topic file is never cited"）
-- 予算が詰まったら回収で解く。**引き上げは Tier C として扱う** — `RESIDENT_CEILING_BYTES`・`RESIDENT_HEADROOM_BYTES`・`RE_INLINE_GUARD_HEADROOM_BYTES` の緩和は、`docs/maintainers/residency-rationale.md` → "When the ceiling may be raised" の 3 条件を示し、ユーザーの明示指示を得てから行う
-
-常駐に残る規則と配送へ移した規則の一覧は `docs/maintainers/residency-rationale.md` → "The resident-rule list"。そのほかの経緯: `docs/maintainers/residency-rationale.md` → "The reduction freeze and its retraction"、`docs/maintainers/residency-rationale.md` → "Measurement decides what leaves"、`docs/maintainers/residency-rationale.md` → "The `rule:value` readings"、`docs/maintainers/residency-rationale.md` → "Why the delivered list carries no count"、`docs/maintainers/residency-rationale.md` → "Why the workflow index is split by topic"、`docs/maintainers/residency-rationale.md` → "One list, not two"、`docs/maintainers/residency-rationale.md` → "The resident budget"。
+- **削ることは移すことであり、削除は理由を示して初めて許される例外である。** 先に導線の先へ移し、マーカーテストも付け替える。移さず引退させてよいのは 3 条件がすべて揃うときだけ — 同じ文書に単一ソースが宣言された文の写しである・単一ソースと突き合わせてほかにない文を含まない・マーカーテストが固定していない。揃わなければ候補と証拠を記録して規則は残す
+- 経緯（Issue 番号・なぜ・計測・却下案）は `docs/maintainers/<topic>-rationale.md` に置き、その冒頭で説明する手順文書を名指しする。**参照の向きは根拠 → 手順だけ** — AI が読む文書から根拠文書は指さない（`scripts/document/rationale-documents.test.ts` が検出する）。Issue 番号引用の件数は `tools/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

@@ -2,30 +2,22 @@
 
 規則の届け方は**常駐**（`CLAUDE.md` に書き毎ターン読み込ませる）と**引き金つき配送**（効く瞬間にフックが本文を突きつける）の 2 つ。
 
-## なぜ配送が要るのか
-
-`docs/maintainers/rule-delivery-rationale.md` → "Why delivery is needed"。
-
 ## 判定基準 — 引き金を特定できるか
 
 どの規則を配送へ移すかは [`residency.md`](./residency.md) →「第 1 問」に従う。
 
 ## 機構 — 1 本だけ、新規に作らない
 
-入口は `PreToolUse` の `pnpm josh pretool:guard`（バッチング ／ 調査 ／ 規則の 3 ガード）と Stop フックの `pnpm josh stop:guard` の 2 つ。**2 本目の配送経路を作るのは `CLAUDE.md` →「No clones」が禁じるクローン**である。配送は呼び出しの書き換え（`updatedInput`）でもよい — 規則の結果そのものを機械的に作れる形に限る。書き換えは `pnpm josh rule:value` が `rewritten` として数える。配線・停止スイッチ・拒否の優先順位: `docs/maintainers/rule-delivery-rationale.md` → "The mechanism"。
+入口は `PreToolUse` の `pnpm josh pretool:guard`（バッチング ／ 調査 ／ 規則の 3 ガード）と Stop フックの `pnpm josh stop:guard` の 2 つ。**2 本目の配送経路を作るのは `CLAUDE.md` →「No clones」が禁じるクローン**である。配送は呼び出しの書き換え（`updatedInput`）でもよい — 規則の結果そのものを機械的に作れる形に限る。書き換えは `pnpm josh rule:value` が `rewritten` として数える。どのガードが書き換えるかは `scripts/rules/guard-remedy.ts` の分類表が単一ソース。
 
 ## 配送されている規則
 
 一覧は `pnpm josh rule:list` が `scripts/rules/delivered-rules.ts` から生成する（joshuafolkken/kit#3399）。各項目は規則の単一ソース・発火点・発火しないときを持ち、フックが走らないエージェントはその出力を自己適用のチェックリストにする（`principles.md`）。
 
-**引き金はシェルのコマンド文字列しか見えない**（node 内の REST や `gh api --input <file>` は掛からない）ので、常駐側にトリガ 1 行を残す（`docs/maintainers/rule-delivery-rationale.md` → "Shell evaluation of a body is one more row of the same mechanism"）。
+**引き金はシェルのコマンド文字列しか見えない**（node 内の REST や `gh api --input <file>` は掛からない）ので、常駐側にトリガ 1 行を残す。
 
 引き金が発火しないターンでは何も起きないのが仕様で、各項目の発火しない状態は「規則が守られている状態」と一致させる。一致が取れない規則は常駐に残す。
 
 ## 配送は 1 ラン 1 回
 
-配送文はラン 1 回につき 1 度しか出ないので、**「同じ呼び出しをもう一度出せ」と明記する**。例外: 繰り返す行為を止める項目は毎回発火し（joshuafolkken/kit#1570）、前提の行為を求める項目は前提が末尾に現れるまで毎回拒否する（joshuafolkken/kit#2807）— その配送文にはそれぞれ「これは毎回発火する」「前提が末尾に現れるまで拒否する」と明記する。バッチングと調査の 2 ガードは違反が間隔分続けば再び発火する（joshuafolkken/kit#2164）。前提の証拠を読めないときは拒否する。経緯: `docs/maintainers/rule-delivery-rationale.md` → "One delivery per run"。配送文の長さの上限と経緯の置き場所: `docs/maintainers/rule-delivery-rationale.md` → "Why a refusal is the action and the next command"。
-
-## マーカーテスト
-
-`docs/maintainers/rule-delivery-rationale.md` → "Marker tests"。
+配送文はラン 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 "…"` も同じく壊れる。経緯は `docs/maintainers/shell-body-rationale.md` → "The incidents — two kinds of damage, one cause"。
-
-発火するのは `` ` `` と `$` で、`!` ではない（`docs/maintainers/shell-body-rationale.md` → "Why `!` is not a trigger"）。
+防ぐのは本文の**テキストが実行されること**である。二重引用符の中の `` ` `` と `$` は実行前に評価される（`!` は評価されない）。
 
 ### 安全な書き方
 
-**本文をファイルに書いて、パスで渡す。**
+**本文をファイルに書いて、パスで渡す。** `--body-file` の本文や計画メモは `.josh/tmp/` に置く（ignore 済みなのでコミットに混ざらない）。
 
 ```bash
 pnpm josh issue:comment <N> --body-file <path>
@@ -25,16 +13,18 @@ pnpm josh followup "<title> #<N>" --notify-message-file <path>
 pnpm josh notify --task-type confirmation --issue-url "<url>" --body-file <path> --recommended "<choice>"
 ```
 
-PR コメントも `pnpm josh issue:comment <N> --body-file <path>` で投稿する（REST では PR コメントは issue コメント）。`gh issue comment` / `gh pr comment` は使わない（`docs/maintainers/shell-body-rationale.md` → "Why no `gh` subcommand is written in an executable block"）。
+PR コメントも `pnpm josh issue:comment <N> --body-file <path>` で投稿する（REST では PR コメントは issue コメント）。`gh issue comment` / `gh pr comment` は使わない。
 
 ### コメント投稿は `pnpm josh issue:comment` の 1 綴りだけ（joshuafolkken/kit#2304）
 
-`gh api` の `-f body=@<path>` ／ `--raw-field body=@<path>` は `@<path>` というリテラルを黙って投稿する（`docs/maintainers/shell-body-rationale.md` → "The comments lost to `-f body=@`"）。**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` の同時指定は拒否される（`docs/maintainers/shell-body-rationale.md` → "Why `--body` and `--body-file` together are refused"）。
+`--body-file` / `--notify-message-file` は `-` で標準入力を読む（実装は `scripts/josh/cli-body.ts`）。`--body` と `--body-file` の同時指定は拒否される。
 
 **`$'…'` も安全である。** ANSI-C クォートの中では置換も展開も起きないので、`CLAUDE.md` の `--body=$'…'` はそのまま使う。長い本文はファイルにする。
 
 ### 引き金つき配送
 
-`pnpm josh rule:guard` は、二重引用符の本文値にバッククォートか `$` を含む `Bash` 呼び出しを拒否する。拒否されたら本文をファイルに移して出し直す。**引き金が見えない綴り（`-b`・`-f title=` など）でも、フックが走らないエージェントでも規則は同じく拘束する。** 見えない綴りの一覧は `docs/maintainers/shell-body-rationale.md` → "Why it is a triggered delivery"、引き金の設計は `docs/maintainers/shell-body-rationale.md` → "Why the trigger reads the body, not the flag"、固定するテストは `docs/maintainers/shell-body-rationale.md` → "Marker tests"。
+`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` が効く瞬間に配送する（`docs/maintainers/turn-batching-rationale.md` → "Why it left residency (joshuafolkken/kit#1524)"）。
-
 ## 何を求めているか
 
 > **この呼び出しの入力は、いま出していない別の呼び出しの結果に依存しているか。**
@@ -9,7 +7,7 @@
 - no → その呼び出しは、依存していない他の呼び出しと同じターンに載せる
 - yes → 結果を待つ。別のターンになるのが正しい
 
-ファイル 3 つを 3 ターンで読む、`git status` と `pnpm josh issue:state` を別ターンに分ける — いずれも禁止。**費用は仕事の量ではなく往復の回数にある。**（`docs/maintainers/turn-batching-rationale.md` → "Why the number of turns is the cost"）
+ファイル 3 つを 3 ターンで読む、`git status` と `pnpm josh issue:state` を別ターンに分ける — いずれも禁止。**費用は仕事の量ではなく往復の回数にある。**
 
 ## 判断基準は「依存の有無」であって、呼び出しの種類ではない
 
@@ -21,12 +19,12 @@
 
 ## ガードが見えないところ — ここでは自分で規則を当てる
 
-中断中のターン・`Write`・書き込む `josh` サブコマンドや連鎖した行・ツールを呼ばないターン・ガードが `off` のレーン子でも、規則は同じく拘束する。一覧は `docs/maintainers/turn-batching-rationale.md` → "Where the guard cannot see"、却下した案は `docs/maintainers/turn-batching-rationale.md` → "Rejected mechanisms" と `docs/maintainers/turn-batching-rationale.md` → "How the guard's scope grew"。
+中断中のターン・`Write`・書き込む `josh` サブコマンドや連鎖した行・ツールを呼ばないターン・ガードが `off` のレーン子でも、規則は同じく拘束する。
 
 ## 事後の計測 — 実行タイミングレポートの `Round trips:`
 
-round trip は 1 ターンがまとめて出した呼び出しのかたまり 1 つで、1.50 呼び出し/往復を下回ると 1 行の指摘が出る。`tool-less turns`（発話だけのターン）は自分で減らす。実装は `scripts/time-runtime/time-round-trips.ts`、読み方は `docs/maintainers/turn-batching-rationale.md` → "Reading the round-trip measurement"。
+round trip は 1 ターンがまとめて出した呼び出しのかたまり 1 つで、1.50 呼び出し/往復を下回ると 1 行の指摘が出る。`tool-less turns`（発話だけのターン）は自分で減らす。実装は `scripts/time-runtime/time-round-trips.ts`。
 
 ## 実装中の独立編集に効く合成コマンド（joshuafolkken/kit#2202）
 
-**Step 0 が対象ファイルを列挙したら、`pnpm josh read:files <path> …` で読み取りを 1 回に畳み、続く独立した編集は `pnpm josh edit:files` の 1 呼び出しで送る**（`old` が 1 箇所に一致しなければ拒否される）。ガードが `read:files` / `edit:files` を手渡したら、その 1 呼び出しで出し直す。形式は `docs/josh-commands-run.md` →「`josh read:files`」と「`josh edit:files`」、経緯は `docs/maintainers/turn-batching-rationale.md` → "The composite commands"。固定するテストは `docs/maintainers/turn-batching-rationale.md` → "What the marker test pins"。
+**Step 0 が対象ファイルを列挙したら、`pnpm josh read:files <path> …` で読み取りを 1 回に畳み、続く独立した編集は `pnpm josh edit:files` の 1 呼び出しで送る**（`old` が 1 箇所に一致しなければ拒否される）。ガードが `read:files` / `edit:files` を手渡したら、その 1 呼び出しで出し直す。形式は `docs/josh-commands-run.md` →「`josh read:files`」と「`josh edit:files`」。

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

@@ -4,7 +4,7 @@
 
 ### 無条件ルール: 起票は確認なし、停止は必ず
 
-**「今の作業をブロックするか」は判定しない。** 上流の欠陥は、発見した時点で例外なく同じ手順を通る（`docs/maintainers/upstream-interrupt-rationale.md` → "Why there is no blocking test"）。
+**「今の作業をブロックするか」は判定しない。** 上流の欠陥は、発見した時点で例外なく同じ手順を通る。
 
 - 起票は Tier A — 起票するか・どこへ起票するかをユーザーに確認しない。対象は first-party に限る（→「第三者リポジトリへの書き込みは Tier C（明示指示が必要）」）
 - **停止は無条件**。Issue を作ってから停止し、待つか先送りするかはユーザーが決める
@@ -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`。上限は効かない（`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,18 +22,28 @@
 
 手順:
 
-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` 形式で書く
+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 と何が止まっているかを書く（→ `CLAUDE.md` → "Mid-workflow stop notification (`confirmation`)"）
 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 のユーザーの明示指示なしに行わない。正しい診断も許可ではない（`docs/maintainers/upstream-interrupt-rationale.md` → "Why third-party writes are Tier C"、`docs/maintainers/upstream-interrupt-rationale.md` → "Why a correct diagnosis is not authorization"）
+- **third-party への書き込みは種別を問わず Tier C**: Issue・コメント・PR・Discussion・レビュー、既存 Issue のクローズ・編集も、その turn のユーザーの明示指示なしに行わない。正しい診断も許可ではない
 - third-party と判明したら: (1) 自分たちの側の Issue に証拠込みで所見を `## Upstream candidate` 見出しで記録する（`## Upstream issues` は使わない）。(2) 報告本文の下書きをその Issue 内に用意する。(3) 対象プロジェクト名と報告内容を書いた `confirmation` Telegram を送って停止する
 - 下書きの前に揃える証拠: 自プロジェクトの外で成立する最小再現（無ければ「プロジェクト組み込みの再現しかない」と明記）、全主張の検証、既存 Issue の検索
 

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

@@ -1,6 +1,6 @@
 # オープン Issue の WIP 上限
 
-常駐も配送もされず（joshuafolkken/kit#1524）、起票コマンドが守らせる（直接起票は `direct-filing` が拒否する）。保留文は `scripts/issue/issue-wip.ts` の `HELD_MESSAGE`（`docs/maintainers/wip-cap-rationale.md` → "Tests that pin the wording"）、背景は `docs/maintainers/wip-cap-rationale.md` → "Why a cap is needed — the measurement"。
+常駐も配送もされず（joshuafolkken/kit#1524）、起票コマンドが守らせる（直接起票は `direct-filing` が拒否する）。保留文は `scripts/issue/issue-wip.ts` の `HELD_MESSAGE`。
 
 ## 規則
 
@@ -30,13 +30,13 @@
 
 前提 Issue（`prerequisite.md`）、別パッケージ起因の割り込み Issue、ユーザーが `new` と打った入口、`issue:scout` が重複無しと答えた新規作業、そして分割判定が作る子 Issue と epic。
 
-- **上限を理由に止めない。** 理由は `docs/maintainers/wip-cap-rationale.md` → "Why a filing a run is blocked by is not stopped"。
+- **上限を理由に止めない。**
 - **分割の子がここに入る理由**: 分割を検出した `fullrun` / `halfrun` は「子と epic を起票して STOP」と定められており（`fullrun.md` / `halfrun.md`）、分割するかは分割判定の側が決める。
 - 超過した事実は完了報告に 1 行書く（例: 「オープン 34 件で起票した」）。
 
 ### 割り込み起票 — 上限が効かない側（3 条件で機械的に決める）
 
-重大な欠陥の発見は、ランを止めていなくても捨てない（`docs/maintainers/wip-cap-rationale.md` → "Where the interrupt category comes from"）。対象はこのリポジトリの欠陥で、発見したランをブロックしていないもの（別パッケージ起因は `upstream-interrupt.md`、実行が詰まる側）。
+重大な欠陥の発見は、ランを止めていなくても捨てない。対象はこのリポジトリの欠陥で、発見したランをブロックしていないもの（別パッケージ起因は `upstream-interrupt.md`、実行が詰まる側）。
 
 #### 3 条件 — 該当するかは判断ではない
 
@@ -48,20 +48,20 @@
 
 **3 つのいずれにも当たらない発見は、従来どおり裁量側の出口を取る。** 改善案、設計上の好み、未検証の疑い、「あとで直したい」がこれに当たる。
 
-**深刻さの自己申告は条件ではない。** 理由は `docs/maintainers/wip-cap-rationale.md` → "Why self-reported severity is not a condition"。
+**深刻さの自己申告は条件ではない。**
 
 #### 該当したときの手順
 
 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
    ```
 
 2. 超過している事実と当たった条件の番号を、両方とも本文に 1 行書く（例:「オープン 37 件で起票。3 条件のうち 2（文書化された手順が完了できない）に該当」）。
-3. 次に実行されるものとして挿入する。epic の下なら `pnpm josh epic --add <E> <N>` で**位置を指定せずに**追加する（`<E>` が epic、`<N>` が割り込み）。**`--before` / `--after` を使ってはならない。** それらは `blocked-by` を書き込み、**偽の依存関係**になる。**順序は実行側が持つ** — 先に提示させたいときは行だけを動かす `--order-before <M>` を使う（`docs/maintainers/wip-cap-rationale.md` → "Why an addition names no position"）。**epic の下に無いなら挿入先そのものが無い**ので、4 だけを行う。
+3. 次に実行されるものとして挿入する。epic の下なら `pnpm josh epic --add <E> <N>` で**位置を指定せずに**追加する（`<E>` が epic、`<N>` が割り込み）。**`--before` / `--after` を使ってはならない。** それらは `blocked-by` を書き込み、**偽の依存関係**になる。**順序は実行側が持つ** — 先に提示させたいときは行だけを動かす `--order-before <M>` を使う。**epic の下に無いなら挿入先そのものが無い**ので、4 だけを行う。
 4. 着手は既にある承認の内側でのみ、指示を待たずに行う。`backlogrun` の中なら次の子として着手してよい。バッチの外では `CLAUDE.md` →「Explicit invocation required」が効き、起票と挿入まで済ませて打つべきコマンド（`fullrun #<N>`）を報告して止まる。**割り込みは上限の例外であって、明示起動規則の例外ではない。**
 
 起票と、実行されるようにするところまでが 1 つのまとまりである — epic の下で追加しなければ `epic:next` は候補に出さない。**epic の外にある割り込みでは、まとまりの後半は 4 の報告そのもの**である。
 
-割り込みを単独で走らせるか並列レーンで走らせるかは `.claude/skills/workflow-commands/backlogrun-lanes.md` → "A solo run" に従う（`docs/maintainers/wip-cap-rationale.md` → "Why a solo run"）。上限の数字の変え方は `docs/maintainers/wip-cap-rationale.md` → "Changing the cap itself"、分割判定・レビュー上限と一緒に動く理由は `docs/maintainers/wip-cap-rationale.md` → "The three move together" と `docs/maintainers/wip-cap-rationale.md` → "Why the three landed in one commit"。
+割り込みを単独で走らせるか並列レーンで走らせるかは `.claude/skills/workflow-commands/backlogrun-lanes.md` → "A solo run" に従う。

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,5 +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

@@ -171,7 +171,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 +179,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