@joshuafolkken/kit 1.1455.0 → 1.1471.0

package/prompts/collaboration-workflow/principles.md

@@ -1,38 +1,35 @@
 # 原則
 
-**このファイルは、`CLAUDE.md` の Communication 節が指す原則の単一ソースである。** 各節は `CLAUDE.md` から `prompts/collaboration-workflow/principles.md` → "見出し" の形で引かれ、`pnpm josh doc:section` で解決する。経緯と適用例は各節が指す [`docs/maintainers/principles-rationale.md`](../../docs/maintainers/principles-rationale.md) の節にあり、実行中には読まない。
+経緯と適用例は [`docs/maintainers/principles-rationale.md`](../../docs/maintainers/principles-rationale.md) の各節にあり、実行中には読まない。
 
 ## no-clones — クローン禁止・単一ソース化
 
-既存の非自明なロジックを「ソースを変えずに済ませる」ために**コピー・移植・再実装することは既定で禁止**する。すでにどこか（別ファイル・別モジュール・別**パッケージ＝上流依存を含む**）に存在するロジックを複製しようとした瞬間が、**単一ソース化**（全消費者が import する共有モジュール／export／パッケージ）のシグナルである。コピーではなく単一ソース化する。
+既存の非自明なロジック（別ファイル・別モジュール・上流依存を含む別パッケージにあるもの）を、ソースを変えずに済ませるために**コピー・移植・再実装しない**。複製したくなったら、全消費者が import する共有モジュール／export／パッケージへ単一ソース化する。
 
-- **既存の重複は再重複の免罪符にならない**: すでに一度クローンされている（例: josh-game が kit をコピー）なら、共有抽象化はとっくに必要だったということ。3 つ目のコピーを足さず、重複の存在を surface する
-- **「上流を参照する」は「再利用する」の意**であって、「そのコードを貼り付ける」ではない
-- **「X を触るな」という制約はクローンを黙って正当化しない**: クリーンな修正には上流（kit）の変更が要る／代替はクローン、というトレードオフを先にユーザーへ提示する（「クリーンな修正は kit の変更が必要、代替はクローン、どちらにする？」）
-- 複製は、単一ソース化の代替案とそのコストを提示し、**ユーザーの明示承認を得た後にのみ**行う
+- 既存の重複は再重複の理由にならない（例: josh-game が kit をコピー）。3 つ目のコピーを足さず、重複を surface する
+- 「上流を参照する」は再利用することで、コードを貼り付けることではない
+- 「X を触るな」という制約でクローンを黙って正当化しない。「クリーンな修正は kit の変更が必要、代替はクローン、どちらにする？」と先に提示する
+- 複製は、単一ソース化の代替案とコストを提示し、ユーザーの明示承認を得た後にのみ行う
 
-**計測は `pnpm josh clone:scan`。** 同一リポジトリ内および `JOSH_REPO_PATHS` の他リポジトリを跨いだ複製を検出し、**件数**と各複製の `file:line`（`[same-file|cross-file|cross-repo]` 分類つき、複製なしは `clean`）を印字する。`pnpm josh oracle:list` に載る決定オラクルでもある（導入の経緯は `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`）を印字する（`docs/maintainers/principles-rationale.md` → "Why clone:scan exists"）。
 
 ## elegant-design — 設計はエレガント・シンプルを第一目標にする
 
-新しい仕組み（フック・ガード・ルール・抽象化）を足す前に、**原因側を直せばその仕組みが要らなくならないか**を先に問う。要らなくなるなら、足さない。症状を叱る仕組みを重ねるのではなく、症状を生んでいる材料を断つ。
+フック・ガード・ルール・抽象化を足す前に、**原因側を直せばその仕組みが要らなくならないか**を問う。要らなくなるなら足さず、原因を直す。検出・通知・叱責を強化する前に、その入力を生んでいる側を断つ。適用例は `docs/maintainers/principles-rationale.md` → "An application of simplicity-first"。
 
-- **問いは 1 つ**: 「この仕組みは、どこかの原因を直せば不要にならないか」。答えが「不要になる」なら、仕組みではなく原因を直す。
-- **足す前に断つ**: 検出・通知・叱責を強化する前に、その入力を生んでいる側を探す。入力が消えれば、それを捌く仕組みそのものが消える。適用例は `docs/maintainers/principles-rationale.md` → "An application of simplicity-first"。
-
-**書かれたコードの可読性**（意図が伝わる命名、過度な抽象化を避ける、など）は `prompts/coding-standards.md` の担当で、こちらは**設計時にどの仕組みを足すか・どこへ置くかを決める**規則。両者は別レイヤーなので、片方の本文をもう片方へ写さず、互いを指すだけにする。
+書かれたコードの可読性は `prompts/coding-standards.md` の担当で、ここはどの仕組みをどこへ足すかの規則である。互いの本文を写さず、指すだけにする。
 
 ## quality-priority — 品質目標が衝突したときの優先順位
 
-品質目標は 3 段に分かれる。上の段は、下の段のために犠牲にしない。
+上の段は、下の段のために犠牲にしない。
 
-1. **正しさ** — 仕様どおりに動き、検証ゲートが緑であること。ほかのどの目標のためにも犠牲にしない
+1. **正しさ** — 仕様どおりに動き、検証ゲートが緑であること
 2. **同列で、どれも悪化させない** — 次の 4 つに上下はない
-   - **複雑さ**（読みやすさを含む）— 初見の読み手が、前提知識なしに意図を追えること。部品や間接層を足すのは、それで読む量が減るときだけにする
-   - **冗長さ**（重複を含む）— 同じ知識を 1 か所に置く（no-clones）。既存の非自明なロジックを複製するときは、no-clones どおり代替案を提示して明示承認を得てから行う
+   - **複雑さ**（読みやすさを含む）— 初見の読み手が前提知識なしに意図を追えること。部品や間接層は読む量が減るときだけ足す
+   - **冗長さ**（重複を含む）— 同じ知識を 1 か所に置く（no-clones）
    - **パフォーマンス** — gate・CI・josh 起動・テストの所要時間
    - **AI コスト** — エージェントが読み込み・出力するトークン量
-3. **コメント最小** — コメントを書きたくなったら、まず命名・分割・型で表現できないかを試す。残すのは「なぜ」だけにする
+3. **コメント最小** — まず命名・分割・型で表現する。残すのは「なぜ」だけ
 
 2 段目の目標同士が衝突したら、次の順で決める。
 
@@ -40,63 +37,63 @@
 2. **1 つを悪くするなら、同じ変更の中で別の場所を削って埋め合わせる** — 合計を悪化させない
 3. **それでも両立しないときは、数字を示して利用者に聞く**（Tier B）— 何をどれだけ悪くして、何を得るか
 
-## consult-vs-execute — 相談と実行を区別する
+## concise-prose — 文章は条件と動作だけを書く
 
-ユーザーが「どう進めるべきか」「何をすべきか」「なぜそうなったか」を尋ねたり、目標・願望を述べたりした（「どうすべき？」「how should we…」「なぜ」「理由を知りたい」「〜したい」「〜の方が良い？」）ときは、**分析と推奨のみ**で応答する。ファイル編集・Issue 作成・その他の具体的アクションは取らない。
+docs・prompts・skills・拒否文・Issue・PR の文章に適用する。
 
-- 具体的アクションを取ってよいのは、明示的な命令（「do it」「書き換えて」「作成して」「implement」）またはワークフローキーワード（`kickoff` / `halfrun` / `prrun` / `fullrun` / `backlogrun`）があるときだけ
-- 発言が相談か実行の指示か判別できないときは、相談として扱う — 分析と推奨を返し、実行の指示を待つ。実行が指示されたあとの判断点で確認するかどうかは、この規則ではなく `CLAUDE.md` → "Decision autonomy" の Tier で決まる
-- **目標の表明は「計画の依頼」であって「実行の承認」ではない**
+- 本文には、いつ何をするか（条件と動作）だけを書く
+- 理由と経緯は rationale 文書に置き、本文からは見出しで指す
+- 太字は 1 節に 1 つまで。箇条書き先頭の見出し語は数えない。`→ "…"` で引かれている太字は消さない
+- 同じ内容を言い換えて繰り返さない
+- ファイルや節が自分自身を説明する文（「このファイルは〜である」）を書かない
 
-## latest-first — 最新優先・fix-forward（pin-back は最終手段）
+導入時のベースラインは `docs/maintainers/principles-rationale.md` → "Why concise-prose exists"。
 
-依存パッケージ・ツールチェーンは**既定で最新版を採用する**。バンプが lint クラッシュ・新規有効化ルール・型エラーなどの破壊を引き起こしても、古いバージョンへ留まる／戻すことを既定の「安全策」にしてはならない。破壊は**前向きに（fix-forward）速やかに**解消する。
+## consult-vs-execute — 相談と実行を区別する
 
-この節が単一ソースで、`dependency-update` skill → "4. When the bump breaks something — fix forward" はここを指す。
+ユーザーが進め方・理由を尋ねたり目標を述べたりした（「どうすべき？」「how should we…」「なぜ」「〜したい」「〜の方が良い？」）ときは、**分析と推奨のみ**を返し、ファイル編集・Issue 作成などのアクションは取らない。目標の表明は計画の依頼であって、実行の承認ではない。
 
-1. **最新優先（latest-first）**: 依存・ツールチェーンは新しいバージョンを既定で採用する。適応の手間を避けるためだけに古いバージョンに留まったり戻したりしない
-2. **破壊は fix-forward**: バンプで lint クラッシュ・新規ルール・型エラー等が出たら、前向きに解消する:
-   - 新ルール／エラーが正当なら **消費者コードを直す**
-   - ルール上書きが要るなら **正しいレイヤー**（kit / app-kit の共有設定）でスコープする。消費者リポジトリでの場当たり的な一回限りの disable にしない
-   - 破壊が first-party パッケージ（kit / app-kit）起因なら、**そこに Issue を立てて適切な altitude で直す**。消費者側の回避だけで済ませない（→ `upstream-interrupt.md`）
-3. **pin-back は最終手段**: fix-forward が本当に不可能／ブロックされている（例: 未リリースの上流修正待ち）ときだけ、古いバージョンへ固定する。固定するときは **理由を記録し、最新へ戻すためのトラッキング Issue を立てる**。pin-back を既定の推奨として提示してはならない
-4. **既存の保護を尊重する**: fix-forward は保護された pin を黙って書き換える許可ではない。overrides と `devEngines` の承認ゲートの単一ソースは `CLAUDE.md` → "Decision autonomy" と `dependency-update` skill である
-5. **タイムリーに**: バンプ起因の破壊は、可能な限り同じ作業セッション内で速やかに対処し、pin の裏に先送りしない
+- アクションを取るのは、明示的な命令（「do it」「書き換えて」「作成して」「implement」）かワークフローキーワード（`kickoff` / `halfrun` / `prrun` / `fullrun` / `backlogrun`）があるときだけ
+- 判別できないときは相談として扱う。実行が指示された後の判断点は `CLAUDE.md` → "Decision autonomy" の Tier で決まる
 
-## durable-rules — 恒久ルールは MEMORY ではなくプロンプト／ドキュメントに書く
+## latest-first — 最新優先・fix-forward（pin-back は最終手段）
+
+依存・ツールチェーンは**既定で最新版を採用する**。`dependency-update` skill → "4. When the bump breaks something — fix forward" はこの節を指す。
 
-今後のセッションでも守るべき恒久的な振る舞いのルールに気付いたときは、**kit が配布するプロンプト／ドキュメント**（`CLAUDE.md` / `prompts/*`）への変更として記述する。プロジェクト単位の自動 MEMORY（例: `~/.claude/projects/<repo-slug>/memory/`）への保存で済ませてはならない。
+1. 適応の手間を避けるために古いバージョンに留まったり戻したりしない
+2. バンプで lint クラッシュ・新規ルール・型エラー等が出たら fix-forward で解消する:
+   - 新ルール／エラーが正当なら消費者コードを直す
+   - ルール上書きが要るなら kit / app-kit の共有設定でスコープする。消費者リポジトリで一回限りの disable にしない
+   - first-party パッケージ（kit / app-kit）起因なら、そこに Issue を立てて直す（→ `upstream-interrupt.md`）
+3. **pin-back は最終手段**: fix-forward が不可能／ブロックされている（例: 未リリースの上流修正待ち）ときだけ固定し、理由を記録して最新へ戻すトラッキング Issue を立てる。pin-back を既定の推奨にしない
+4. fix-forward は保護された pin を黙って書き換える許可ではない。overrides と `devEngines` の承認ゲートは `CLAUDE.md` → "Decision autonomy" と `dependency-update` skill に従う
+5. バンプ起因の破壊は同じセッション内で対処し、pin の裏に先送りしない
 
-- **プロンプト／ドキュメントが正である理由**: バージョン管理下でレビューでき、`josh sync` で全消費者リポジトリ・別の PC・別の AI ツールに届き、`git log` で経緯を追える
-- **MEMORY は 1 台のマシン × 1 つのリポジトリ**にスコープされたローカルストアで、コミットされない。保存は最小限に留め、用途は本質的にローカルな文脈（マシン固有のパス、個人の環境の癖など）だけ。どこでも適用されるべきルールの唯一の置き場所にしてはならない
+## durable-rules — 恒久ルールは MEMORY ではなくプロンプト／ドキュメントに書く
 
-運用:
+共有価値のある恒久ルールに気付いたら、**kit が配布するプロンプト／ドキュメント**（`CLAUDE.md` / `prompts/*`）の変更として書き、自動 MEMORY（`~/.claude/projects/<repo-slug>/memory/`）で済ませない。MEMORY はマシン固有のパスなど本質的にローカルな文脈だけに使う。
 
-1. 恒久ルールに気付いたら、まず「これは kit のドキュメント／プロンプトに書くべきか？」を判定する。共有価値があるなら答えは常に yes
-2. 現在のターンがドキュメント変更を承認していない（相談中など）場合は、**MEMORY に黙って保存せず、プロンプト／ドキュメント変更を提案する**（→「相談と実行を区別する」「配布ドキュメント・設定の変更は kit に上流化する」）
-3. 消費者リポジトリで気付いた場合は、ローカル編集ではなく kit 側へ Issue／PR として上流化する
-4. 既に MEMORY にあるルールが実は共有すべきものだと分かったときは、プロンプト／ドキュメントへ移し、MEMORY 側の重複エントリは削除する
+- ターンがドキュメント変更を承認していない（相談中など）なら、MEMORY に黙って保存せず変更を提案する
+- 消費者リポジトリで気付いたら、kit 側へ Issue／PR として上流化する
+- MEMORY にあるルールが共有すべきものなら、プロンプト／ドキュメントへ移し、MEMORY 側を削除する
 
 ## upstream-to-kit — 配布ドキュメント・設定の変更は kit に上流化する
 
-`CLAUDE.md` および kit が配布する他のドキュメント／設定は、kit から単一ソースで配布される。
-
-- **消費者リポジトリ（app-kit / game-kit）ではこれらをローカル編集しない**: `josh sync` が編集を上書きするうえ、変更は本来上流（kit）に属する。ドキュメント／設定を編集する前に、それが配布物かどうかを確認し、配布物なら kit 側に変更を提案（Issue／PR）する
-- **kit リポジトリ自身ではあなたが配布元**なので、ここでは編集してよい。編集先は `CLAUDE.md` 1 本である（次節）
+- 消費者リポジトリ（app-kit / game-kit）では、kit が配布する `CLAUDE.md` や他のドキュメント／設定をローカル編集しない（`josh sync` が上書きする）。編集前に配布物か確認し、配布物なら kit 側に Issue／PR で提案する
+- kit リポジトリ自身では編集してよい。編集先は `CLAUDE.md` 1 本である（次節）
 
 ## エージェント規則の単一ソースは `CLAUDE.md`（`AGENTS.md` / `GEMINI.md` / `.cursorrules` は導線）
 
-**規則の本体は `CLAUDE.md` にしか無い。** `AGENTS.md`・`GEMINI.md`・`.cursorrules` は「規則は `CLAUDE.md` にある。作業前に全文を読むこと」と「規則を書き戻さない」だけを書いた短い導線文書であり、規則を 1 行も持たない（`.cursorrules` は Svelte MCP の使い方の案内だけを足す）。
+**規則の本体は `CLAUDE.md` にしか無い。** `AGENTS.md`・`GEMINI.md`・`.cursorrules` は「規則は `CLAUDE.md` にある。作業前に全文を読むこと」と「規則を書き戻さない」だけを書いた導線である（`.cursorrules` は Svelte MCP の案内だけを足す）。
 
-- **規則の追加・仕様変更・文言修正・節の追加は `CLAUDE.md` に 1 回だけ書く。** 導線文書には触れない
-- **導線文書に規則を書き戻さない。** そこに書かれた規則は、次の改訂で更新し忘れる 4 つ目の置き場になる
+- 規則の追加・変更・節の追加は `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 以外のエージェントでの読み替え
 
-`CLAUDE.md` は Claude Code 向けに書かれており、その機能を名指しする。Codex・Gemini CLI など別のエージェントは次のように読み替える（joshuafolkken/kit#3079）。
+Codex・Gemini CLI など別のエージェントは `CLAUDE.md` を次のように読み替える（joshuafolkken/kit#3079）。
 
-- **フック**: フックが走らない、または出力が見えないツールでは、フックが届ける規則を自分で適用する。その一覧は手書きせず、[`rule-delivery.md`](./rule-delivery.md) →「配送されている規則」の一覧を正とする — 一覧の各項目が、そのツールでは自分で守る規則である。一覧の外でフックが担う 3 つも同じく自分で行う — 最初の実行時コード編集の前に Step 0 の作業サマリを提示する、編集ごとの整形フックに頼らず編集後に `pnpm josh lint:related` と `pnpm josh cspell:dot` を走らせる、`JOSH_SESSION_LANG` は注入を待たずに `.env` から解決する。フックの全体は `.claude/settings.json` の `hooks` が正である
-- **Skill・`/verify-ui`・`/code-review`**: `CLAUDE.md` が skill のロードやサブエージェントでの実行を指示する箇所では、その skill の `SKILL.md` を読み、自分のセッションで従う
-- **`.claude/settings.json` の deny list** は効かない。それが裏付ける `CLAUDE.md` → "Git Rules" はそのまま拘束する
+- **フック**: フックが走らない・出力が見えないツールでは、[`rule-delivery.md`](./rule-delivery.md) →「配送されている規則」の各項目を自分で守る。加えて、最初の実行時コード編集の前に Step 0 の作業サマリを提示し、編集後に `pnpm josh lint:related` と `pnpm josh cspell:dot` を走らせ、`JOSH_SESSION_LANG` を `.env` から解決する。フックの全体は `.claude/settings.json` の `hooks`
+- **Skill・`/verify-ui`・`/code-review`**: その skill の `SKILL.md` を読んで自分のセッションで従う
+- **`.claude/settings.json` の deny list** は効かないが、`CLAUDE.md` → "Git Rules" はそのまま拘束する
 - **`AskUserQuestion`** は、ユーザーに平文で尋ねることを指す

package/prompts/collaboration-workflow/proposal-request.md

@@ -1,14 +1,6 @@
 ## Step 2: 提案依頼（AI 共通）
 
-Issue URL を渡して、次の観点で提案を依頼する。
-
-- 要件の分解
-- 実装候補（複数案がある場合は比較）
-- 影響ファイル
-- テスト方針（unit/e2e）
-- リスクと回避策
-
-最小プロンプト:
+Issue URL を渡して、次の最小プロンプトで提案を依頼する。
 
 ```md
 Issue: <issue-url>

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

@@ -1,37 +1,32 @@
 ## 報告フォーマット（平易な概要 ＋ 技術詳細）
 
-作業前サマリ（Step 7）と完了報告（Step 5）は、**平易な概要を先頭に置き、技術詳細をその下に降格する 2 層構造**で書く。ここが横断ドキュメント（`CLAUDE.md`）のカノニカル参照。
+作業前サマリ（Step 7）と完了報告（Step 5）は、**平易な概要を先頭に置き、技術詳細をその下に置く 2 層構造**で書く。
 
 ### 機械的な半分は `josh report:lint` が検査する
 
-ラベルの有無、概要行の字数上限、コードフェンス囲みでないこと、概要へのファイルパス・CLI フラグの混入、ケース段と「壊れるとしたら」段の形は、サマリを標準入力で `pnpm josh report:lint` に渡して検査する（`ok` か違反行を印字する。判定の一次ソースはコマンド側の定数 — joshuafolkken/kit#2123）。この文書に残るのは、テンプレートと、機械には答えられない判断（下記「具体的な主語を必ず書く」）である。
+ラベルの有無、概要行の字数上限、コードフェンス囲み、概要へのファイルパス・CLI フラグの混入、ケース段と「壊れるとしたら」段の形は、サマリを標準入力で `pnpm josh report:lint` に渡して検査する（`ok` か違反行を印字する — joshuafolkken/kit#2123）。
 
 ### 出力はコードフェンスで囲まない（必須）
 
-以下のテンプレートは **フェンスの中身だけ**をセッションに書く（空白での桁揃えと単独行の `---` も使わない）。
+以下のテンプレートは**フェンスの中身だけ**をセッションに書く（空白での桁揃えと単独行の `---` も使わない）。
 
 ### ラベルはセッション言語に訳し、注釈は付けない（必須）
 
-**(1) ラベルはセッション言語に訳す。** 英語のまま残すのは誤り。日本語セッションでの対応:
+**(1) ラベルはセッション言語に訳す。** 日本語セッションでの対応:
 
-| 英語ドキュメントのラベル                                 | 日本語セッションでの表記                                              |
-| -------------------------------------------------------- | --------------------------------------------------------------------- |
-| `■ Overview`                                             | `■ 概要`                                                              |
-| `Now` / `Change` / `Check`                               | `今こうなっている` / `こう直す` / `確かめ方`                          |
-| `Details`                                                | `技術詳細`                                                            |
-| `Changes and tests`                                      | `変更とテスト`                                                        |
-| `Cause` / `Fix` / `Result`（完了報告）                   | `原因` / `対応` / `結果`                                              |
-| `■ Hand-off`（区切り）                                   | `■ 区切り`                                                            |
-| `Done` / `Remaining` / `Why it stopped` / `Next command` | `終わったこと` / `残っていること` / `止めた理由` / `次に打つコマンド` |
+- `■ 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 つだけである。
+成果物の散文（Issue 本文、Issue／PR コメント、Telegram 本文）のラベルもこの表で訳す。英語のまま残るのは「出力の言語（`JOSH_SESSION_LANG`）」が挙げた 3 つだけ。
 
-**(2) ラベルに注釈を付けない。** `■ 概要（平易な説明）` は誤り。注意書きはラベルではなく、ラベルの下の説明文に置く。
+**(2) ラベルに注釈を付けない。** `■ 概要（平易な説明）` は誤り。注意書きはラベルの下の説明文に置く。
 
 ### 作業前サマリはいつ・どう出すか
 
-`CLAUDE.md` → "Code Change Rules" の Step 0 が指す細目の単一ソース。
-
 - **いつ**: 実装コードを書く前に、Issue ごとに 1 回出す。`fullrun` / `halfrun` / `prrun` / `backlogrun` で必須、`kickoff` は対象外。確認のための停止ではない — 出したらそのまま実装に進む
 - **概要**: `Now` / `Change` / `Check` を各 1 文、セッション言語で、プログラマでない人にも追える文で書く。各行に具体的な主語を書き、主語のない文は不可（下記「具体的な主語を必ず書く」）。ファイルパス・関数名や型名・CLI のオプションフラグは書かない — 禁じるのは内部識別子だけである
 - **技術詳細**: すべての変更をそのテストとともに `<変更内容> — Test: <Unit|E2E> — <file path> — <検証する挙動>` の形で並べる
@@ -64,20 +59,20 @@
 2. ...
 ```
 
-**テスト宣言はケース単位の 2 段で書く（joshuafolkken/kit#2246）。**
+テスト宣言はケース単位の 2 段で書く（joshuafolkken/kit#2246）。
 
-- **第 1 段（ケース）** は固定語彙を並べ、**該当しないものは `該当なし` に続けて理由を書いて消す**。効くのは消した行で、漏れが「考えなかった」から「考えて外した」に変わる
-- **第 2 段（壊れるとしたら）** は、この変更に固有の壊れうる条件を**最低 3 件**書く。書けないときは `どう呼ばれても壊れない` と明示する
-- 1 ケース＝1 テスト関数ではない。複数ケースは `it.each` 1 本に畳んでよい
-- **境界の必須異常系はコマンドが答える。** 差分が HTTP・プロセス起動・ファイル IO・時間の境界を跨ぐとき、`pnpm josh cases <path...>` が印字する異常系を第 2 段に載せる（ユニットスイートはネットワークを遮断しているため、宣言の側で突きつけるしかない）
+- 第 1 段（ケース）は固定語彙を並べ、**該当しないものは `該当なし` に続けて理由を書いて消す**
+- 第 2 段（壊れるとしたら）は、この変更に固有の壊れうる条件を**最低 3 件**書く。書けないときは `どう呼ばれても壊れない` と明示する
+- 複数ケースは `it.each` 1 本に畳んでよい
+- 差分が HTTP・プロセス起動・ファイル IO・時間の境界を跨ぐときは、`pnpm josh cases <path...>` が印字する異常系を第 2 段に載せる
 
 ### 行数予算は編集前に読む
 
-**「対象」に書くファイルは、書き始める前に `pnpm josh lines <path> [<path>...]` に渡し、上限に近いと言われたファイルには、その場で分割方針を「対象」に書く**（事後の `max-lines` 対応は run 時間の約 2 割を食っていた — joshuafolkken/kit#1425）。近いかどうかと行数はコマンドの答えであり、`wc -l` では数えない。関数単位の上限は `pnpm josh lint` が報告する。
+**「対象」に書くファイルは、書き始める前に `pnpm josh lines <path> [<path>...]` に渡し、上限に近いと言われたファイルには分割方針を「対象」に書く**（joshuafolkken/kit#1425）。行数は `wc -l` で数えない。関数単位の上限は `pnpm josh lint` が報告する。
 
 ### 変更対象はまとめて読んでから編集する（joshuafolkken/kit#2202）
 
-**「変更とテスト」が変更対象ファイルを列挙した直後、それらを 1 回の `pnpm josh read:files <path> [<path> ...]` で読み、続く独立した編集は 1 回の `pnpm josh edit:files -` で送る**（個別の `Edit` に戻すのは依存する編集・1 件だけの編集・`Write` のとき）。単一ソースは [`turn-batching.md`](turn-batching.md) →「実装中の独立編集に効く合成コマンド」。
+**「変更とテスト」が変更対象ファイルを列挙したら、1 回の `pnpm josh read:files <path> [<path> ...]` で読み、続く独立した編集は 1 回の `pnpm josh edit:files -` で送る**（個別の `Edit` は依存する編集・1 件だけの編集・`Write` のとき）。詳細は [`turn-batching.md`](turn-batching.md) →「実装中の独立編集に効く合成コマンド」。
 
 ### 完了報告（セッション向け）
 
@@ -97,42 +92,32 @@
 - 残課題: <なければ「なし」>
 ```
 
-**実行証跡は「動くこと」の証拠であり、gate の緑ではない（joshuafolkken/kit#2246）。** 同じ証跡を PR 本文の `## 実機証跡` 節（コマンド＋実出力のフェンス）にも置く。無い実行時の変更は `pnpm josh followup` がマージを拒否する（#2446）。
+**実行証跡は「動くこと」の証拠であり、gate の緑ではない**（joshuafolkken/kit#2246）。同じ証跡を PR 本文の `## 実機証跡` 節（コマンド＋実出力のフェンス）にも置く。無い実行時の変更は `pnpm josh followup` がマージを拒否する（#2446）。
 
-**`run:carry` の実行証跡は `JOSH_TEMP_ROOT` を新しい一時ディレクトリに向けて取る（必須）。** run の状態レコードは、走っている本物の run と共有の 1 か所にあり、作業ディレクトリを移しても `pnpm --dir` を使っても切り離せない。変数は起動時に読まれるので、`JOSH_TEMP_ROOT="$(mktemp -d)" pnpm josh run:carry --begin …` のように各コマンドの頭に付ける（`docs/environment-variables.md` → "Runs"）。**`run:merge` はこれで切り離せない** — レコードの他に main の同期・lane の close・GitHub への書き込みを行うため、一時ルートを変えても本物の run の共有状態に触れる。
+**`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）は完了報告ではない — **`原因` / `対応` / `結果` を使わない**。書式は [`.claude/skills/workflow-commands/backlogrun-handoff-report.md`](../../.claude/skills/workflow-commands/backlogrun-handoff-report.md)。
 
 ### 概要 3 行の書き方（ここが本体）
 
-字数と内部識別子の混入は `report:lint` が検査する。長さ制限だけでは平易にならないので、**語彙と抽象度を制約する**:
+字数と内部識別子の混入は `report:lint` が検査する。平易にするために語彙と抽象度を制約する:
 
 - 専門用語は使わないか、`〜（＝…のこと）` の形でその場で言い換える
-- 変更点の羅列ではなく **原因 → 対応 → 効果の因果**で書く
-- 主語は利用者・システムの振る舞い。「利用者から見て何が違うか」が書けないなら、その行はまだ技術詳細のまま
+- 変更点の羅列ではなく、原因 → 対応 → 効果の因果で書く
+- 主語は利用者・システムの振る舞い。「利用者から見て何が違うか」が書けない行は技術詳細に置く
 
-**送信前セルフチェック**: コードを見ていない読み手が、概要 3 行だけで**どれの話か特定できるか**。できないなら具体的な名詞を 1 つ足す。
+**送信前セルフチェック**: コードを見ていない読み手が、概要 3 行だけでどれの話か特定できるか。できないなら具体的な名詞を 1 つ足す。
 
 ### 具体的な主語を必ず書く（禁止と対になる要求）
 
-「書かない」規則だけを守ると、**何の話か特定できない**概要になる。そこで禁止と対になる要求を置く:
-
-- **何かが「古い」「壊れている」「変わらない」と書くときは、その対象を名指しする。** 対象パッケージ名・画面名・出力の種類のいずれかを必ず含める
-- **主語のない「状況」「案内」「問題」「その処理」だけで済ませない。**
-- **書いてよい具体名**: 利用者が画面で目にするもの — パッケージ名、表示されるコマンドの目的、画面名、メッセージの種類
-- **書いてはいけない具体名**: 内部識別子のみ — ファイルパス、関数名・型名、CLI のオプションフラグ
+- **何かが「古い」「壊れている」「変わらない」と書くときは、その対象を名指しする** — 対象パッケージ名・画面名・出力の種類のいずれかを含める
+- 主語のない「状況」「案内」「問題」「その処理」だけで済ませない
+- 書いてよい具体名: 利用者が画面で目にするもの — パッケージ名、表示されるコマンドの目的、画面名、メッセージの種類
+- 書いてはいけない具体名: 内部識別子 — ファイルパス、関数名・型名、CLI のオプションフラグ
 
-**悪い例**（何の話か特定できない）:
-
-```md
-- **今こうなっている**: 古いままだと警告が出るのに、案内されたコマンドを実行しても状況が変わらないことがある。
-- **こう直す**: 効き目のない案内は理由の説明に置き換え、同じ案内が何度も並ぶのもやめる。
-- **確かめ方**: 自動テストで、無駄な案内が消え・重複が消え・従来の表示は変わらないことを確かめる。
-```
-
-**良い例**（同じ内容で、対象を名指ししている）:
+悪い例は「古いままだと警告が出るのに、案内されたコマンドを実行しても状況が変わらない」（何の話か特定できない）。良い例:
 
 ```md
 - **今こうなっている**: バージョン確認が「全体で使う app-kit が古い」と警告するのに、一緒に出る更新コマンドは既に入っている版を指していて、実行しても何も変わらず同じ警告がまた出る。
@@ -140,8 +125,6 @@
 - **確かめ方**: 自動テストで、効かないコマンドが説明に置き換わり、重複が 1 行になり、通常の表示は変わらないことを確かめる。
 ```
 
-違いは長さではなく、**名指ししているかどうか**にある。良い例には内部識別子は 1 つも出てこない。
-
 ### 成果物（Issue / PR / Telegram）側
 
-言語は「出力の言語（`JOSH_SESSION_LANG`）」に従い、**構造も**セッション向けと同じ 2 層にする。`--notify-message` は `Added ... / Changed ...` の羅列ではなく、`Cause / Fix / Result` の 3 行を先頭に置き、変更点の箇条書きを `Details:` 以下にまとめる（実例は [`followup.md`](../../.claude/skills/workflow-commands/followup.md)）。
+言語は「出力の言語（`JOSH_SESSION_LANG`）」に従い、構造もセッション向けと同じ 2 層にする。`--notify-message` は `Added ... / Changed ...` の羅列ではなく、`Cause / Fix / Result` の 3 行を先頭に置き、変更点を `Details:` 以下にまとめる（実例は [`followup.md`](../../.claude/skills/workflow-commands/followup.md)）。

package/prompts/collaboration-workflow/residency.md

@@ -1,37 +1,37 @@
 ## 常駐ドキュメントと skill の分担（何を常駐に残すか）
 
-**規則をどこに書くか、常駐にどこまで残すかの判定は、このファイルが単一ソースである**（joshuafolkken/kit#2891）。`CLAUDE.md` はすべてのエージェント規則の入口で、`AGENTS.md` / `GEMINI.md` / `.cursorrules` はそこへの導線である。規則のトリガは `CLAUDE.md` に **1 度だけ**、手順と数値は導線の先に **1 度だけ**書く。`CLAUDE.md` の経緯は `docs/maintainers/claude-md-history.md` にある。**規則を散文で書く前に**、下の問いで置き場所を決める — 計算できる答えは `pnpm josh oracle:list` のコマンドへ、順序は `pnpm josh run:step` へ。**読むのは規則を置く・移す・引退させるターンだけ**である。`CLAUDE.md` は毎ターン全文が読み込まれ、上限は `scripts/document/resident-budget.ts` の `RESIDENT_CEILING_BYTES`（残りは `pnpm josh bytes CLAUDE.md`）。**置き場所は書き手の重要度判断ではなく、下の 4 つの問いを順に当てて決める。** 経緯・一覧・作例は `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`）。**置き場所は重要度ではなく、下の問いを順に当てて決める。** 経緯は `docs/maintainers/claude-md-history.md` と `docs/maintainers/residency-rationale.md`。
 
 ### 第 0 問（先に問う）
 
 > **その規則の答えは、機械的に読める入力だけから計算できるか。**
 
-**できるなら、コマンドが答える。** 文書には「このコマンドに聞け」の導線 1 行だけを置く。既存のオラクルは `pnpm josh oracle:list`、単一ソースは `scripts/rules/decision-oracle.ts`。
+できるなら、コマンドが答え、文書には導線 1 行だけを置く。既存のオラクルは `pnpm josh oracle:list`、単一ソースは `scripts/rules/decision-oracle.ts`。
 
 ### 順序の問い（第 0 問の次に問う）
 
 > **その規則は「何を」ではなく「いつ・どの順で・どの引数で」を決めているか。**
 
-**そうであれば、規則はドライバの状態遷移に書き、散文には書かない。** `pnpm josh run:step <N>` が次の 1 手を計算する（`scripts/run/run-step.ts`、joshuafolkken/kit#2248）。文書は導線 1 行を張るだけである。
+そうであれば、規則はドライバの状態遷移に書き、文書は導線 1 行だけにする。`pnpm josh run:step <N>` が次の 1 手を計算する（`scripts/run/run-step.ts`、joshuafolkken/kit#2248）。
 
 ### 第 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"。
+できるなら、規則本文を常駐から出し、配送ガードの行に `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"。
 
 ### 第 2 問 — skill なしのターンでも効く必要があるか
 
 > **その規則は、skill がロードされていないターンでも効く必要があるか。**
 
-**`CLAUDE.md` に残るのは、skill がロードされていないターンでも効く必要がある規則だけである。** 入力は「最初に効くのはコマンド開始の前か後か」の 1 点で、規則の重要さは入力に含まれない。後なら `CLAUDE.md` から導線を張り、再掲しない。
+**`CLAUDE.md` に残るのは、skill がロードされていないターンでも効く必要がある規則だけである。** 入力は「最初に効くのはコマンド開始の前か後か」の 1 点。後なら `CLAUDE.md` から導線を張り、再掲しない。
 
 ### 残すときの書き方と予算
 
 - **常駐規則は、トリガと導線の 2 つで書く。** **判定は、導線を一度も開かないターンでも常駐の記述だけで正しく振る舞えるかである。**
-- **削ることは移すことであり、削除は理由を示して初めて許される例外である。** 先に導線の先へ移し、マーカーテストも付け替える。引退の 3 条件は `docs/maintainers/residency-rationale.md` → "Trigger and pointer, and the narrow retirement route"。
-- **経緯（Issue 番号・なぜ・計測・却下案）は実行時の文書に書かず `docs/maintainers/<topic>-rationale.md` に置く。** agent が読む文書の 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 条件を示した上でユーザーの明示指示を得てから行う。
+- **削ることは移すことであり、削除は理由を示して初めて許される例外である。** 先に導線の先へ移し、マーカーテストも付け替える。引退の 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"。
+常駐に残る規則と配送へ移した規則の一覧は `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"。

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

@@ -1,31 +1,31 @@
 # 引き金つき配送 — 規則を「効く瞬間」に届ける（joshuafolkken/kit#1524）
 
-規則の届け方は 2 つある。**常駐**（`CLAUDE.md` に書き、毎ターン読み込ませる）と、**引き金つき配送**（規則が効く瞬間にフックが本文を突きつける）である。この文書は後者の単一ソースである。配線・判定の細部と経緯は `docs/maintainers/rule-delivery-rationale.md` にあり、ランの途中で読む必要はない。
+規則の届け方は**常駐**（`CLAUDE.md` に書き毎ターン読み込ませる）と**引き金つき配送**（効く瞬間にフックが本文を突きつける）の 2 つ。
 
 ## なぜ配送が要るのか
 
-常駐の経路は実効上限で詰まっており、配送は該当する瞬間だけのコストで届き、拒否は読み飛ばせず、発火を単体テストで固定できる。経緯: `docs/maintainers/rule-delivery-rationale.md` → "Why delivery is needed"。
+`docs/maintainers/rule-delivery-rationale.md` → "Why delivery is needed"。
 
 ## 判定基準 — 引き金を特定できるか
 
-どの規則を配送へ移すかの単一ソースは [`residency.md`](./residency.md) →「第 1 問」であり、ここには写さない。
+どの規則を配送へ移すかは [`residency.md`](./residency.md) →「第 1 問」に従う。
 
 ## 機構 — 1 本だけ、新規に作らない
 
-配送はすべて 1 つの土台に載り、入口はイベントごとに 2 つある。`PreToolUse` の入口が `pnpm josh pretool:guard`（バッチング ／ 調査 ／ 規則の 3 ガードを 1 プロセスで合成）、Stop フックの入口が `pnpm josh stop:guard` である。**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` として数える。配線・停止スイッチ・拒否の優先順位: `docs/maintainers/rule-delivery-rationale.md` → "The mechanism"。
 
 ## 配送されている規則
 
-一覧は `pnpm josh rule:list` が `scripts/rules/delivered-rules.ts` の行から生成する（joshuafolkken/kit#3399）。各項目は規則の単一ソース・発火点・発火しないときを持ち、フックが走らないエージェントはその出力を自己適用のチェックリストにする（`principles.md`）。
+一覧は `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 行を残す（`docs/maintainers/rule-delivery-rationale.md` → "Shell evaluation of a body is one more row of the same mechanism"）。
 
-**「引き金が発火しないターンでは何も起きない」ことは仕様である。** 各項目の発火しない状態は「規則が守られている状態」と一致する。一致が取れない規則は常駐に残す。**誤ったターンで発火するフックは、フックが無いより悪い。**
+引き金が発火しないターンでは何も起きないのが仕様で、各項目の発火しない状態は「規則が守られている状態」と一致させる。一致が取れない規則は常駐に残す。
 
 ## 配送は 1 ラン 1 回
 
-配送文は**ラン 1 回につき 1 度**しか出ないので、**「同じ呼び出しをもう一度出せ」と明記する**。例外は 2 つで、繰り返す行為を止める項目は毎回発火し（joshuafolkken/kit#1570）、前提の行為を求める項目は前提が末尾に現れるまで毎回拒否する（joshuafolkken/kit#2807）。その配送文にはそれぞれ「これは毎回発火する」「前提が末尾に現れるまで拒否する」と明記する。バッチングと調査の 2 ガードは違反が間隔分続けば再び発火する（joshuafolkken/kit#2164）。前提の証拠を読めないときは拒否を基本とする。経緯: `docs/maintainers/rule-delivery-rationale.md` → "One delivery per run"。
+配送文はラン 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"。
+`docs/maintainers/rule-delivery-rationale.md` → "Marker tests"。

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

@@ -1,25 +1,22 @@
 ## 本文をシェルの二重引用符に載せない（joshuafolkken/kit#1198）
 
-「本文をシェルの二重引用符に載せない」規則の単一ソース（`CLAUDE.md` からは [`rule-delivery.md`](./rule-delivery.md) →「配送されている規則」を経て届く）。「ファイル本文をシェルに載せない」（[`file-edits.md`](./file-edits.md)）と対になる規則である。**あちらは「ファイルの中身をシェルに載せるな」、こちらは「本文をシェルに載せるな」** であり、禁じている理由が違う — あちらはコストの二重払い、こちらは**テキストが実行されること**である。
+`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` は …"
 ```
 
-zsh は `pnpm josh ms` を実行し、その標準出力を本文に埋め込む。`pnpm josh followup --notify-message "…"` の本文も同じ根で壊れる。事故の経緯は `docs/maintainers/shell-body-rationale.md` → "The incidents — two kinds of damage, one cause"。
+`pnpm josh followup --notify-message "…"` も同じく壊れる。経緯は `docs/maintainers/shell-body-rationale.md` → "The incidents — two kinds of damage, one cause"。
 
-- **通知経路**: 置換結果が本文に混ざる。壊れ方が静かで、`followup` は正常終了する
-- **`gh` 経路**: 置換された結果が捨てられるのではなく、**コマンドとして実行される**
-
-**発火するのは `` ` `` と `$` であって `!` ではない**（実測表は `docs/maintainers/shell-body-rationale.md` → "Why `!` is not a trigger"）。
+発火するのは `` ` `` と `$` で、`!` ではない（`docs/maintainers/shell-body-rationale.md` → "Why `!` is not a trigger"）。
 
 ### 安全な書き方
 
-**本文をファイルに書いて、パスで渡す。** シェルは本文を一切解釈しない。
+**本文をファイルに書いて、パスで渡す。**
 
 ```bash
 pnpm josh issue:comment <N> --body-file <path>
@@ -28,23 +25,16 @@ pnpm josh followup "<title> #<N>" --notify-message-file <path>
 pnpm josh notify --task-type confirmation --issue-url "<url>" --body-file <path> --recommended "<choice>"
 ```
 
-**PR コメントも同じ経路である** — REST では pull request のコメントは issue のコメントであり、`pnpm josh issue:comment <N> --body-file <path>` がそのまま使える。`gh issue comment` / `gh pr comment` は使わない（GraphQL 経由。理由は `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` は使わない（`docs/maintainers/shell-body-rationale.md` → "Why no `gh` subcommand is written in an executable block"）。
 
 ### コメント投稿は `pnpm josh issue:comment` の 1 綴りだけ（joshuafolkken/kit#2304）
 
-**`gh api` には「本文をパスで渡す」の綴りが 2 つあり、片方は黙って壊れる。**
-
-- `gh api ... -F body=@<path>` ／ `--field body=@<path>` — `@` で始まる値を**ファイルとして読む**。正しい
-- `gh api ... -f body=@<path>` ／ `--raw-field body=@<path>` — 値を**そのまま送る**。`@<path>` というリテラル文字列がコメントとして投稿される
-
-`-f` と `-F` は 1 文字違いで、どちらでも `gh` は終了コード 0 でコメント URL を返す。**壊れたことが分かるのは後で人が Issue を見たときだけ**である（`docs/maintainers/shell-body-rationale.md` → "The comments lost to `-f body=@`"）。
-
-だから **Issue／PR コメントの投稿は `pnpm josh issue:comment <N> --body-file <path>` ただ 1 綴りに寄せる** — 間違ったフラグを選ぶ余地が無く、本文は `cli-body.ts` を通ってパスで渡るためシェルも評価しない。`-f body=@…` の綴りは実行前に `pnpm josh rule:guard` が拒否する（列挙表の `raw-field-body` 行、`scripts/rules/raw-field-body.ts`）。上の Issue body 書き換え（`-X PATCH ... --field body=@<path>`）は `-F` 側で安全なので綴りを変えない。
+`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` 側で安全なのでそのまま使う。
 
-`--body-file` / `--notify-message-file` はいずれも `-` で標準入力を読む（`gh issue create --body-file -` と同じ約束）。読み取りは `scripts/josh/cli-body.ts` の 1 本だけで、`josh notify` / `josh followup` / `epic --rationale-file` / `epic --decision-file` の 4 つがそれを共有する。**`--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` の同時指定は拒否される（`docs/maintainers/shell-body-rationale.md` → "Why `--body` and `--body-file` together are refused"）。
 
-**`$'…'` も安全である。** ANSI-C クォートの中ではコマンド置換も変数展開も起きない。`CLAUDE.md` が Telegram の本文に `--body=$'…'` を指定しているのはそのためであり、この規則はそれを置き換えるものではない。ただし本文が長くなるほどファイルの方が扱いやすい。
+**`$'…'` も安全である。** 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"。
+`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"。

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

@@ -1,38 +1,32 @@
 # 独立した呼び出しは同じターンに載せる（joshuafolkken/kit#1304）
 
-「独立した呼び出しは同じターンに載せる」規則の正典。**常駐側には [`rule-delivery.md`](./rule-delivery.md) →「配送されている規則」への導線だけが残り、規則本文は `pnpm josh batch:guard` が効く瞬間に配送する**（joshuafolkken/kit#1524、`docs/maintainers/turn-batching-rationale.md` → "Why it left residency (joshuafolkken/kit#1524)"）。実測・却下した機構案・経緯は `docs/maintainers/turn-batching-rationale.md` にある。
+常駐側には [`rule-delivery.md`](./rule-delivery.md) →「配送されている規則」への導線だけが残り、規則本文は `pnpm josh batch:guard` が効く瞬間に配送する（`docs/maintainers/turn-batching-rationale.md` → "Why it left residency (joshuafolkken/kit#1524)"）。
 
 ## 何を求めているか
 
-**判断は 1 問で決まる。**
-
 > **この呼び出しの入力は、いま出していない別の呼び出しの結果に依存しているか。**
 
-- no → **その呼び出しは、依存していない他の呼び出しと同じターンに載せる**
+- no → その呼び出しは、依存していない他の呼び出しと同じターンに載せる
 - yes → 結果を待つ。別のターンになるのが正しい
 
-ファイルを 3 つ読むために 3 ターン使う、同じファイルの離れた 3 箇所を直すために 3 ターン使う、`git status` と `pnpm josh issue:state` を別ターンに分ける — いずれも禁じられた形である。**費用は仕事の量ではなく往復の回数にある。** 1 ターンの壁時計はほぼ一定なので、ターン数が run の下限を決める（実測は `docs/maintainers/turn-batching-rationale.md` → "Why the number of turns is the cost"）。
+ファイル 3 つを 3 ターンで読む、`git status` と `pnpm josh issue:state` を別ターンに分ける — いずれも禁止。**費用は仕事の量ではなく往復の回数にある。**（`docs/maintainers/turn-batching-rationale.md` → "Why the number of turns is the cost"）
 
 ## 判断基準は「依存の有無」であって、呼び出しの種類ではない
 
-**`Edit` も同じ規則の対象である** — 別々のファイルや同じファイルの離れた領域への編集は、互いの結果を使っていないので同じターンに載る。逆に、**依存があるなら分けるのが正しい**: `grep` の結果の行番号で `sed -n` を出す、`git switch` の成否を見てから次を出す、Edit の前に対象を読む（**Edit の前に読むことは省略できない**）。
+**`Edit` も同じ規則の対象である** — 別ファイルや離れた領域への編集は同じターンに載せる。依存があるなら分ける: `grep` の行番号で `sed -n` を出す、`git switch` の成否を見てから次を出す、Edit の前に対象を読む（省略できない）。
 
 ## 検証ゲートとレビューは往復を減らす対象ではない
 
-**ゲート・レビュー・差分の読み取りを、往復を減らす名目で弱めてはならない。** `pnpm josh gate` の出力を絞って失敗の内訳を読まずに進む、`git diff main...HEAD` を一部だけ読んで「指摘なし」とする（`output-bounds.md`）、走らせるべきチェックを落とす — いずれも禁止。**往復を減らすのは「同じ仕事を少ないターンで出す」ことであって、「仕事を減らす」ことではない。**
+ゲートの失敗の内訳を読まずに進む、差分を一部だけ読んで「指摘なし」とする（`output-bounds.md`）、チェックを落とす — いずれも禁止。**往復を減らすのは「同じ仕事を少ないターンで出す」ことであって、「仕事を減らす」ことではない。**
 
 ## ガードが見えないところ — ここでは自分で規則を当てる
 
-中断中のターン・`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` のレーン子でも、規則は同じく拘束する。一覧は `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"。
 
 ## 事後の計測 — 実行タイミングレポートの `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`、読み方は `docs/maintainers/turn-batching-rationale.md` → "Reading the round-trip measurement"。
 
 ## 実装中の独立編集に効く合成コマンド（joshuafolkken/kit#2202）
 
-**Step 0 が対象ファイルを列挙した時点で、`pnpm josh read:files <path> …` で読み取りを 1 回に畳み、続く独立した編集は `pnpm josh edit:files` の 1 呼び出しで送る**（`report-format.md` が導く。`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"。
-
-## マーカーテスト
-
-`scripts/rules/turn-batching-rule.test.ts` が固定する。内訳は `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`」、経緯は `docs/maintainers/turn-batching-rationale.md` → "The composite commands"。固定するテストは `docs/maintainers/turn-batching-rationale.md` → "What the marker test pins"。