@joshuafolkken/kit 1.872.0

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

@@ -0,0 +1,123 @@
+## 運用ルール
+
+- 通知は CI チェック成功後に投稿する
+- 通知投稿に失敗しても、実装完了の事実はログで確認できるようにする
+- 自動投稿される Issue コメント文面は `JOSH_SESSION_LANG` の言語（未設定なら `ja`）で記載する。Issue タイトルだけは英語で固定する
+
+### CI チェック失敗時の対応
+
+`pnpm josh followup` は Required チェックのみ待機するが、**Workers Builds（Cloudflare デプロイ）など非 Required チェックが失敗した場合も必ずユーザーに明示的に報告する**。
+
+- `pnpm josh followup` が印字するチェック一覧を確認し、失敗しているチェックがあればすべて列挙する。手で読み直すときは `gh api repos/{owner}/{repo}/commits/<head-sha>/check-runs --jq '.check_runs[] | {name, conclusion}'` を使う（`gh pr checks` は GraphQL を通るためクラウドセッションでは 403 になる）
+- 修正できた場合: 修正内容を `--notify-message` に含める
+- 修正できなかった場合: `--notify-message` に失敗チェック名・原因・未解決である旨を記載する。**完了コメントに失敗を隠してはならない**
+- ユーザーへの報告も失敗の事実を正直に伝える（「成功」として扱わない）
+
+### auto-merge と `completion` 通知（本文は手順書にある）
+
+**auto-merge（`fullrun` の既定）と `completion` 通知の本文は、[`.claude/skills/workflow-commands/followup.md`](../../.claude/skills/workflow-commands/followup.md) にある。** かつてはこのファイルにも「Auto-merge（default for `fullrun`）」「`completion` 通知は `pnpm josh followup` 経由のみ」の 2 節として全文が重複していたが、joshuafolkken/kit#1187 で手順書へ単一ソース化した。`fullrun` と打つこと自体がマージの承認であること、CI がオールグリーンでも未対応の AI レビュー指摘があればマージしないこと、マージ後の `pnpm josh ms`、`completion` Telegram を手で打たないこと、`pnpm josh followup` を前景で実行することは、いずれもそこが単一ソースである。
+
+### 明示的な起動が必須（MANDATORY）
+
+`kickoff` / `halfrun` / `fullrun` / `backlogrun` ワークフロー（`#N` および `new` バリアントを含む）は、ユーザーが**現在のターンのプロンプト**にキーワードを入力していない限り、絶対に開始してはならない。
+
+- 「実装して」「修正して」「PR を出して」などの会話的な依頼は暗黙の起動ではない。タスクがこれらのワークフローに該当すると判断した場合でも、依頼の形状から起動を推測してはならない
+- 「`halfrun new` を実行してもよいですか？」「`fullrun` を回しますか？」のような確認質問もしてはならない。確認プロンプトは明示的な起動の代替にはならない
+- 代わりに、**ユーザー自身にコマンドを入力してもらうよう促す**。次の形式を使う: 「このタスクは \`<command>\` で起動してください」。例: 「このタスクは \`halfrun new\` で起動してください」「Issue を実行するには \`fullrun #412\` を実行してください」。ユーザーが次のターンで自分でコマンドを入力する
+- 過去のターンで関連ワークフローを承認していた場合でも、このルールは適用される。各起動は現在のターンでユーザーが再入力する必要がある
+
+### 指示されていない行動は取らない
+
+PR マージ・ブランチ削除・force push・共有ブランチへの push・外部通知の追加送信・リポジトリ設定の変更など、**共有状態に影響する操作はその場でユーザーに明示指示されたものだけ実行する**。
+
+- `fullrun` の auto-merge は `fullrun` の指示自体に含まれるため許可される（本文は [`followup.md`](../../.claude/skills/workflow-commands/followup.md)）。それ以外の状況で勝手にマージしてはならない
+- `kickoff` / `pnpm josh followup` 単独実行は文書化されたスコープで終了する。PR が OPEN のまま完了したら状態を報告して停止する
+- 「チェックが全部 green だから次のステップに進む」は承認ではない
+- **`gh pr merge` の直接実行は kit 配布の `.claude/settings.json` の `deny`（`Bash(gh pr merge*)`）で機械的に遮断されている。** `fullrun` の auto-merge は `pnpm josh followup` が node スクリプト内部から gh を起動するため影響を受けない — Bash マッチャに見えるのは `pnpm josh …` だけである。**ただし deny は実装であって規則ではない** — パターンが取りこぼす綴りを禁じているのは本節の規則のほうである
+- **同じ規則が禁じる force push とブランチ削除も deny に載っている**（joshuafolkken/kit#1062）。`Bash(git push *--force*)` / `Bash(git push * -f)` はフラグを引数の後ろに書いた綴りを、`Bash(git push *--delete*)` / `Bash(git branch -d*)` / `Bash(git branch -D*)` / `Bash(gh api *DELETE*git/refs/heads/*)` はブランチ削除を止める。**deny は規則より狭いが、その差は配送ガードが埋めている** — `git -C` を前置した綴り、短縮フラグをまとめた綴り（`git push -uf`）、`:` をリテラルにできず glob が照合できない `git push origin :branch` は、いずれも `pnpm josh rule:guard` の `git-force` 行が argv を解析して拒否する（joshuafolkken/kit#2120）。**「マージ経路は deny が保証している」とは読まないこと**
+- **共有状態に影響する操作（このセクションの対象＝Tier C）は迷ったら確認する。** 確認のコストは低いが、意図しない操作の巻き戻しは高コスト
+- ただしこの「迷ったら確認」は Tier C に限る。**可逆な実装・設計判断（Tier A）は別ルール**（CLAUDE.md「Decision autonomy」の3層ポリシー）に従い、明確に優位な選択肢は確認せず自動で選んで記録する — 本当に甲乙つけがたい（Tier B）ときだけ確認する。下記「意思決定の自律ポリシー」を参照
+
+### git index を勝手に変更しない（自律 staging の禁止）
+
+**git の index（ステージング領域）はユーザーのものである。** ユーザーは「後の変更を差分で見るための基準スナップショット」として意図的にステージしていることがあり、`git add` / `git add -A` / `git rm --cached` / `git restore --staged` はそれを上書きする。index には履歴がないため、**上書きされた直前のステージ状態は復元できない**。
+
+- **調査目的の staging は絶対に行わない。** 「diff stat を出したい」「未追跡ファイルの中身を差分で見たい」といった理由で `git add` してはならない。これが実際に事故（ユーザーが意図的に作ったスナップショットの破壊）を起こしたケースがある
+- **調査は読み取り専用コマンドで行う**:
+  - 変更ファイル一覧: `git status --short`
+  - 作業ツリーの差分: `git diff` / `git diff --stat` / `git diff HEAD`
+  - ステージ済みの差分: `git diff --staged`（読み取りのみ、index は変えない）
+  - **未追跡ファイルの中身**: `git diff --no-index /dev/null <new-file>`（staging 不要）。あるいは単にファイルを直接読む
+- **staging してよいのは次の 2 ケースだけ**:
+  1. ユーザーが**そのターンで明示的に**ステージを指示した
+  2. 承認済みのコミットフローの一部として実行される（`pnpm josh git`、および `fullrun` / `backlogrun` の起動に含まれるコミット手順。`halfrun` はコミットしないので含まれない）
+- 上記以外で staging が必要だと考えたときは、**実行せずに先に確認する**
+- **レーンの中で競合を解決したあとの「解決済み」の記録は、ケース 2 に含まれる（Tier A）。** レーンは run 専用の作業ツリーで、守るべき利用者の staging はない。利用者に `git add` の許可を求めず、`pnpm josh git -y` で記録する。手順は `.claude/skills/workflow-commands/chain-rule.md` →「origin/main is merged in before the gate」の 1 か所にだけ書く（joshuafolkken/kit#2445）
+- 同じ理由で、`git reset` / `git checkout -- <path>` / `git restore <path>` など index や作業ツリーを破壊的に書き換える操作も、自分の判断で実行しない
+- **`git stash` は例外的に、明文化されたフローの中でのみ自動実行してよい**: `fullrun new` / `halfrun new` の手順 5（作業ツリーに変更がある状態で `josh latest` を回す前の退避）、`backlogrun` のラン開始時の `josh latest`、「別パッケージ起因の問題は割り込み Issue で対応する」、および `backlogrun` が epic の子を始める前の preflight（`pnpm josh run:hold <N>` が `reclaim` と答えたときの回収 — joshuafolkken/kit#926, joshuafolkken/kit#1965）。**この 5 番目だけが復元を伴わない。前の 4 つはいずれも直後に `pnpm josh stash:pop "<メッセージ>"` で復元することが手順に含まれている**（stash はリポジトリ単位の 1 本のスタックを全 work tree が共有するため、位置指定や引数なしの `git stash pop` は別のレーンが最後に積んだ stash を取り込む — メッセージで対象を特定する。joshuafolkken/kit#2050）。 回収するのは異常終了したランの置き土産であって、いま実行中のランの作業ではないから、pop して戻す先がない。**代わりに stash を子の Issue にコメントで記録する** — 前提 Issue で中断するときの stash（`SKILL.md` §2d）と同じく、**その記録だけが後で pop させられる唯一の手がかり**であり、記録し忘れた stash は誰にも拾われない。これら以外の場面で退避したくなったときは、実行せずに先に確認する
+- **この禁止は kit 配布の `.claude/settings.json` の `deny`（`Bash(git add*)` / `Bash(git stage*)` / `Bash(git rm*)` / `Bash(git mv*)` / `Bash(git reset*)` / `Bash(git restore --staged*)` / `Bash(git restore -S*)` / `Bash(git commit*)`）で機械的にも遮断されている。** `pnpm josh git` は node スクリプト内部から git を起動するため影響を受けず、承認済みのコミットフロー（上記ケース 2）は従来どおり動く。**deny には「そのターンでユーザーが明示指示した」という例外がないため、上記ケース 1 も AI 側では実行できない** — その場合はユーザー自身の端末で実行してもらう（ユーザーの手元では従来どおり動く）。恒久的な機械的保証のほうが、コマンド 1 本で回避できる例外より価値が高いという判断（joshuafolkken/kit#850）
+- **`Bash(git commit*)` だけはステージング操作ではないが、同じ deny に入っている。** `git add` を拒否されたエージェントが次に手を伸ばすのが `git commit -a`（追跡済みファイルをまとめてステージしてコミットする）であり、それも拒否されると素の `git commit -m` である。フラグ単位で塞いでいる限りこの退避路は最後の 1 本が残るため、joshuafolkken/kit#1075 でサブコマンド全体へ広げた。**ユーザーが明示的にコミットを指示した場合も AI 側では実行できない点は上と同じ** — 承認済みのコミットは `pnpm josh git` を通す
+- **「拒否される操作」と「禁止された操作」は同じ集合ではない。** deny に載っているのは上記の直接実行だけだが、このセクションが同じく禁じている `git checkout -- <path>` / `git restore <path>` / 認可外の `git stash`（bare・メッセージ無し push・位置指定 pop など。メッセージ付き `git stash push -m` と `pnpm josh stash:pop` は認可済みなので通る）は、`pnpm josh rule:guard` の `worktree-mutation` 行が拒否する（joshuafolkken/kit#2120）。**ツールが通したことを許可と読み替えてはならない** — 何をしてよいかを決めるのは deny でも配送ガードでもなくこのルールである（フックは Claude Code にしか届かない）
+- このルールは横断ドキュメント（CLAUDE.md「Git Rules」→「Never stage or mutate the git index on your own」）のカノニカル参照
+
+### 意思決定の自律ポリシー（確認停止を減らす）
+
+AI ツール（Opus / Gemini / Cursor）が判断の分岐で止まりすぎるのを防ぐため、各判断を3層に分類して扱う。停止して確認するのは**本当にユーザーの判断が必要な分岐だけ**にする。このセクションが横断ドキュメント（CLAUDE.md「Decision autonomy」）のカノニカル参照。
+
+- **Tier A — 可逆な実装・設計判断**（明確に優位な選択肢があるライブラリ選定、命名、ファイル構成、テスト手法、リファクタの形）。メリット比較で1案が明確に優位なら**確認せず自動で選んで進める**。本来ユーザー確認すべき分岐だった場合は、後から監査・差し戻せるよう判断を記録する（下記「自動判断の記録」）
+- **Tier B — 本当に甲乙つけがたい判断**。上位2案がどちらも妥当で差が僅差。**ここだけが停止する層** — ユーザーに確認する（`AskUserQuestion` が使えるなら使う）。拮抗する候補とトレードオフを提示する
+  - **起票した Issue の所属先は、候補が複数の epic に散っていても Tier B ではない**（joshuafolkken/kit#1339）。`epic --add` 1 回で移せるので推奨する 1 つを選び、採用・却下・理由・決定日を Issue と epic の両方に記録して進む。止まるのは 2 つの epic が本当に甲乙つけがたいときだけである
+- **Tier C — 不可逆・共有状態・スコープ外の操作**（マージ、ブランチ削除、force push、破壊的操作、リポジトリ設定変更、タスク範囲外の変更、`devEngines` / overrides の編集（`pnpm-workspace.yaml` `overrides:` と `package.json` `pnpm.overrides` のいずれも））。**このポリシーの対象外。** 1案が明確に優位に見えても、常にユーザーの明示指示を要する。既存の安全ルール（上記「指示されていない行動は取らない」、`devEngines` / overrides 保護）が優先される
+
+**A と B の判定基準**: 確認するのは「差が僅差 **かつ** 後戻りしにくい／アーキテクチャに長く影響する」ときだけ。「迷っている」だけでは停止理由にならない — 明確に優位な選択肢は多少の不確実性が残っても自動で選び、僅差でも安価に巻き戻せる選択は自動で決めて記録して進む。
+
+**Tier A に含まれる「自己修正」**: 次の 2 つは設計判断ではなく後始末であり、**確認せずに実行してよい**。
+
+- **自分が公開した成果物の事実誤りの訂正**: Issue / PR コメントや Issue 本文の誤記・誤った帰属（例: 欠陥を実際とは別のパッケージに帰属させた記述）を、自分で訂正する
+- **同じセッションで自分が特定した、自分の作業の抜けの穴埋め**: 例として、欠けていると自分で指摘した相互リンクを後から追加する
+
+どちらも可逆で、望ましい結果が 1 つしかなく、放置をユーザーが選ぶことはない。**この半分に回避策のリスクはない** — 問題を迂回するのではなく、既に行った作業を修復するだけだからである。
+
+- **「相談と実行を区別する」との境界**: ここでの Tier A は **すでに承認され実行された作業を完了・修復する**ことに限られる。目標の表明（「〜したい」）や進め方への問い（「どうすべき？」）に対して勝手に動いてよい、という意味ではない（→「相談と実行を区別する（議論中にファイルを編集しない）」）
+- **Tier C との境界（再掲）**: 自分のコメントの訂正は Tier A。マージ・ブランチ削除・force push・スコープ外の変更は、**その問題を招いたのが自分自身であっても** Tier C のまま
+- 記録は下記「自動判断の記録」に従う。確認を外しても監査証跡は外さない
+
+**自動判断の記録**: 本来確認すべき Tier A の分岐を自動判断したときは、候補と理由を記録する:
+
+- Issue 駆動ワークフロー内（`kickoff` / `halfrun` / `fullrun` / `backlogrun`）: `pnpm josh issue:comment <N> --body-file <path>` で、採用案・不採用の代替案・なぜ採用案が明確に優位かを記載する
+- Issue が存在しない会話タスク: 同じ内容を「Auto-decided: `<choice>` over `<alt>` because `<reason>`」の1行として応答に明示する
+
+### 確認待ちで停止するときの Telegram 通知（`confirmation`）
+
+`kickoff` / `fullrun` 実行中に AI ツールがユーザーの確認・承認・指示待ちで停止するときは、停止の **直前に** Telegram 通知を 1 回送る。これにより、画面を見ていなくてもユーザーが応答すべきタイミングに気付ける。
+
+```bash
+pnpm josh notify --task-type confirmation --issue-url "<issue-url>" --body=$'<停止理由>\n<ユーザーに求める判断>'
+```
+
+- 本文が `-` で始まる場合は `--body=...` の形式（1 トークン）で渡す。スペース区切りでは `parseArgs` がエラーになる
+- 同一の停止に対して通知は 1 回のみ。再評価のたびに送らない
+- ユーザー自身がそのターンで停止を指示した場合は通知しない（既に把握しているため）
+
+### 作業ツリーは 1 本のランが保持する（`josh run:hold`）
+
+手順の単一ソースは `.claude/skills/workflow-commands/SKILL.md` → 「2f. The working-tree hold — one run per tree」にある。ここに書くのは、キーワードが打たれていないターンでも読まれる位置に、引き金だけを置くためである。
+
+`fullrun` / `halfrun` は、**他の何よりも先に `pnpm josh run:hold` を実行し、その答えに従う**。`busy` または `unknown` なら、`confirmation` Telegram を送って停止する — **起票もブランチ作成もファイル編集もしない**。`new` 系の入口では起票より前に問う。起票してから気付けば、掃除すべき副作用が残るためである。
+
+**`kickoff` は対象外である**（joshuafolkken/kit#1799）。このガードが守るのは 1 本のブランチ・1 つの index・1 つの未コミット差分であり、`kickoff` はそのいずれにも触れない — Issue を読み、タイトルを正規化し、計画を投稿し、通知して止まる、そのすべてが GitHub 側の操作である。取得させると、そのランが決して乱さない資源のために、無関係なランの実行中ずっと計画作業が止まっていた。取得しない以上、解除もしない。
+
+**解除は、どのランのものかを名乗る**（joshuafolkken/kit#1799）。`pnpm josh run:release <N>` は記録が `<N>` を名乗るときだけ削除し、引数なしの形は未採番ランの記録だけを削除する。それ以外のランの記録なら `held` を返して何も消さない。以前はそこにある記録を無条件に消していたため、`busy` の停止メッセージが案内する復旧手順そのものが、稼働中のランの作業ツリーを解放する経路になっていた。本当に放棄された記録を消すのは `pnpm josh run:release --force` だけである。
+
+**判定の単位は作業ツリーであり、リポジトリではない。** `backlogrun` が使う `epic-busy.ts` はリポジトリに問う読み取りで、「1 リポジトリにつき同時 1 子」を実装している。これらの入口が奪い合う資源は 1 本のブランチ・1 つの index・1 つの未コミット差分であり、別 worktree ならそれらは別々に存在するので競合しない。ここでリポジトリ単位の判定を使うと、正当な 2 本目まで止まる。**`backlogrun` 側の既存ガードは変更しない** — 両者は別の資源を守っており、片方が片方を置き換えることはできない（joshuafolkken/kit#1091）。
+
+### overrides の保護（`pnpm-workspace.yaml` / `package.json` の両方を見る）
+
+overrides に設定された制約は、**セキュリティ・互換性・動作保証のために意図的に追加されたもの**である。
+
+**実効のある overrides は `pnpm-workspace.yaml` に置く。** pnpm 11 と 12 は `package.json` の旧 `pnpm.overrides` を無視する（pnpm 12.6.0 で実測）。両ファイルの既存宣言を点検して意図しない変更を防ぐが、旧欄を有効な override と数えてはならない。**`pnpm.overrides` が空、あるいは `pnpm` フィールドが無いことは、そのプロジェクトに overrides が無いことの証拠にはならない。** app-kit でも実効のある設定は workspace 側にある（kit #740）。
+
+- **確認は「実行するコマンド」であって「到達する結論」ではない。** `josh latest` / `pnpm update --latest` などの依存更新コマンドの実行後は、`git diff -- pnpm-workspace.yaml package.json` を実行し、`overrides:` ブロックと `pnpm.overrides` の双方が無傷であることを確認する
+- `josh latest` は overrides の判定を自分で出力する（最後の overrides 行が `✔ overrides unchanged (<n> from <file>)`、変化していれば `⚠ overrides changed` 警告）。`pnpm josh overrides` は実効のある workspace 設定をスナップショットと比較し、無視される package 側の宣言も報告する。**実際に出力された行を引用して報告する**こと — 推測した判定を書いてはならない
+- overrides が自動的に変更・削除された場合は、**理由を調査してから**ユーザーに報告し、明示的な承認なしに変更してはならない
+- 例: `"esbuild@<=0.24.2": ">=0.25.0"` などのバージョン制約は、Workers ビルド互換性やパッケージの動作保証のために入れてある場合がある

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

@@ -0,0 +1,107 @@
+# コマンド出力が文脈へ持ち込む量の上限（joshuafolkken/kit#1173）
+
+**上限は機構で決まり、実行側の判断には委ねられない。** どのコマンドが何行返すかは実行前には分からないので、「たぶん短いだろう」と推測して絞るかどうかを決める形は、費用の圧力が高いときほど「これくらいなら素通しでよい」へ倒れる。joshuafolkken/kit#1094 が「区切りを判断ではなく機構にする」と述べたのと同じ原則を、出力側へ適用したものである。
+
+## 何をしているか
+
+配布される `.claude/settings.json` の `env` ブロックが `BASH_MAX_OUTPUT_LENGTH` を宣言する。Claude Code は Bash ツールの出力がこの文字数を超えると真ん中を省略して渡すので、**1 回のコマンドが文脈へ持ち込む量に harness 側で上限が掛かる**。エージェントは何も判断しない。
+
+```json
+"env": {
+	"BASH_MAX_OUTPUT_LENGTH": "8000"
+}
+```
+
+**8,000 文字。** harness の既定は 30,000 文字、受け付ける最大は 150,000 文字である（`claude` バイナリ内の `default:30000, upperLimit:150000`）。
+
+## なぜ既定の 30,000 では足りないか
+
+直近 25 セッション・tool_result 2,333 件を実測した。**Bash の出力は tool_result トークンの 87.5%（1,848 件・1,241,642 トークン）**を占める。その 1,848 件のうち **30,000 文字を超えたものは 0 件**だった — 既定の上限はこのプロジェクトで一度も作動していない。存在するが届かない上限は、上限が無いのと同じである。
+
+Bash 出力の長さの分布（文字数）: p50 = 570 / p75 = 1,920 / p90 = 4,421 / p95 = 8,342 / p99 = 15,989 / 最大 = 28,908。
+
+上限ごとに、真ん中を省略したときに削れる量:
+
+| 上限（文字）   | 該当する呼び出し  | 削れる量（tool_result 全体に対して） |
+| -------------- | ----------------- | ------------------------------------ |
+| 4,000          | 218 件（11.8%）   | 26.6%                                |
+| 6,000          | 124 件（6.7%）    | 18.2%                                |
+| **8,000**      | **95 件（5.1%）** | **12.7%**                            |
+| 10,000         | 69 件（3.7%）     | 8.7%                                 |
+| 15,000         | 22 件（1.2%）     | 2.5%                                 |
+| 30,000（既定） | 0 件              | 0%                                   |
+
+**8,000 を採ったのは p95 だからである。** 20 回に 19 回はこれまでと何も変わらず、残る 1 回だけが範囲を指定して読み直す形になる。4,000 は削れる量こそ倍だが 8 回に 1 回が切り詰められ、読み直しの往復が上限で浮かせた分を食い返す。
+
+## 却下した案と、その理由
+
+- **非有界コマンドを PreToolUse guard が拒否する。** 実測が否定した。tool_result の上位には `cd`（5.4%）と `for`（4.4%）が入り、先頭語を見ても正体が分からない — 命令は `cd <dir> && …` や `for n in …; do …; done` の内側にある。さらに 2 位の `sed`（16.6%）は本 Issue が推奨する範囲指定の形そのもので、構文上は有界なのに 1 ブロック 8,000 トークンを運んでいる（`sed -n '30,400p'`）。**形で見分ける案は、実データ上で外れる。** 大きさで切る案にはこの弱点がない。
+- **共通ラッパで切り詰める（`josh` のサブコマンド等）。** ラッパを通すかどうかが実行側の判断になり、本 Issue が問題視した構造がそのまま残る。上限を機構にするという要件を満たさない。
+
+## 切り詰められたときにどうするか
+
+**情報を落とすのではなく、必要な範囲に合わせて読み直す。** 同じコマンドを再実行しても上限は同じなので、絞り込んで読む:
+
+- ファイルなら範囲を指定する（`sed -n '120,180p' <file>`）か、`Read` ツールの `offset` / `limit` を使う
+- 一覧なら件数を絞る（`--limit`、`| head -30`）
+- JSON なら必要な項目だけ取り出す（`gh api … --jq '…'`）
+- どうしても全量が要るときは、いったんファイルへ落として（`> <file>`）から範囲を読む
+
+## 切り詰められた出力を、完全な出力として読まない
+
+**検証ゲートと差分は、切り詰められた結果で判断しない。** 上限は harness が掛けるので、`pnpm josh gate` の出力も `git diff main...HEAD` も等しく対象になる。両者の性質は違い、危険なのは後者である。
+
+- **`pnpm josh gate` は判定そのものは失わない。** 真ん中が省略されても先頭と末尾は残り、合否の 1 行（`✔ verification gate passed` / `✗ verification gate failed: …`）は末尾に出るので、赤いゲートが緑に見えることはない。**失われうるのは失敗の内訳だが、それはもうコンソールだけの存在ではない**（joshuafolkken/kit#1227）。ゲートは毎回、全チェックの全文を一時ディレクトリのファイルへ書き、その場所を合否行の直前に `full output: <path>` として出す。切り詰めのマーカーを見たらそのパスを読む — 個別のチェックを single で回し直すのは、機構が入る前の暫定の答えだった。記録済みの緑を再利用してスキップしたときはこの 2 行が出ず `✔ this tree is already green …` だけになるが、出力そのものが 2 行なので切り詰めの対象にならず、かつ緑のときにしか出ない（joshuafolkken/kit#1328）。
+- **差分には判定行が無い。** `git diff` が切り詰められると、抜けた hunk があること自体は省略マーカーで分かるが、抜けた内容は復元されない。自己レビューの対象が欠けたまま「指摘なし」と結論づけるのは、ゲートを弱めたのと同じである。**差分はファイルへ落としてから範囲で読む。**
+
+```bash
+git diff main...HEAD > /tmp/diff.patch && wc -l /tmp/diff.patch
+```
+
+**切り詰めは黙って起きない** — 省略された箇所には harness がマーカーを残す。マーカーを見たら、それは「短い出力」ではなく「一部しか読んでいない出力」である。
+
+## 検証コマンドをパイプに繋がない（joshuafolkken/kit#1556）
+
+**パイプラインの終了コードは最後のコマンドのものである。** `pnpm josh gate 2>&1 | tail -40` は `tail` の終了コードで終わるので、**赤いゲートがシェルの上では成功として返る。**
+
+joshuafolkken/kit#1546 の実行中に実際に起きた。2 回目のゲートが `✗ verification gate failed` を印字しながら、パイプラインは 0 を返していた。失敗は本物（Prettier の整形と、マーカーテスト 1 件）で、**実行した子が出力を読んでいたから気づいた**。終了コードだけを見ていれば、赤いツリーがそのままコミットされていた。
+
+**これは `josh gate` の欠陥ではない。** 非ゼロは正しく返っており、パイプラインの終了コードが最後のコマンドのものになるのは POSIX シェルの規定どおりの挙動である。**直すべきはコマンドではなく、呼び出し方である。**
+
+### どう呼ぶか
+
+- **既定はパイプなしで実行する。** josh の各チェックは合否の 1 行を末尾に出すので、この文書の上限で真ん中が省略されても判定は残る（前節）。切り詰める理由がそもそも無い
+- **出力をどうしても絞るなら、ファイルへ落として範囲で読む**（`pnpm josh gate > /tmp/gate.log 2>&1; tail -40 /tmp/gate.log`）。リダイレクトは終了コードを奪わない
+- **パイプが避けられないなら `set -o pipefail` を前置する。** パイプラインが検証側の終了コードを運ぶ
+- **どの形でも、印字された判定行を読む。終了コードだけを答えにしない**
+
+### 対象は「結果が合否を意味するコマンド」だけ
+
+`gate` ／ `check` ／ `lint*` ／ `cspell*` ／ `test*` ／ `eval` — 合否を返すものに限る。
+
+**`git log | head` や `gh issue list | head` は対象外であり、意図的にそうしている。** 一覧を `| head` で絞るのは読み方として正しく、そこで拒否するフックは transcript の最頻形で発火することになる。**規則を広げると無視される方向に働き、無視される規則は無い規則より悪い**（`rule-delivery.md` →「誤ったターンで発火するフックは、フックが無いより悪い」）。
+
+**フックは 2 つの形にも黙る。** `set -o pipefail` を前置したパイプラインは検証側の終了コードを運ぶので握りつぶしていない。引用符の中のコマンド列（`--body "cd x && pnpm josh gate | tail"` のような Issue 本文）はテキストであって呼び出しではない。**どちらも「規則に従った呼び出しを拒否しない」ためである** — 配送はラン 1 回きりなので、従った呼び出しで 1 回を使い切ると、後から本当に握りつぶしている呼び出しが素通りする。
+
+`latest:scope` ／ `review:brief --level-only` ／ `review:brief` も対象外である。これらは**判定ではなく答えを印字する**コマンドで、`$(...)` で受けるのが正しい使い方である。コマンド置換そのものの無音の失敗は別の規則が扱う（`docs/josh-commands.md` →「`VAR=$(...) && cmd`」）。
+
+### 引き金つき配送で強制する —— 却下した 2 案
+
+- **手順書の実行例を書き換える。** 却下。**書き換える例が存在しない。** 文書・プロンプト・skill の全体を調べて、パイプ付きの検証例は `docs/josh-commands.md` の 1 件だけで、しかもそれはこの不具合の説明そのものだった。パイプは手本から写されているのではなく、**毎ターン新しく発明されている**
+- **呼び出し規約として書く**（「ゲートをパイプに繋ぐな」「`set -o pipefail` を前置しろ」）。却下。**同じ案が既に却下されている** — `scripts/time-runtime/time-reported-failure.ts` が「規約は守られるか守られないかのどちらかであり、図が捉えるべきは『そうすべきだったこと』ではなく『実際にしたこと』である」としてこれを退け、代わりに検出器を置いた。散文が数値を動かさなかった計測は joshuafolkken/kit#1344 と joshuafolkken/kit#1460 にもある
+
+採ったのは**引き金つき配送**である（`rule-delivery.md`）。`pnpm josh rule:guard` が、合否を意味する josh のチェックがパイプの手前に立った `Bash` 呼び出しを**その場で拒否する**。**拒否は読み飛ばせない。**
+
+**検出器は残る。** `scripts/time-runtime/time-reported-failure.ts` はゲート自身の `✗ verification gate failed:` 行を `is_error` の上に読む。フックが届くのは Claude Code だけで、停止スイッチを立てたセッションにも他の harness にも届かない — 検出器はその外側を覆い、かつ**規則が守られたかどうかを事後に測れる唯一の経路**である。配送と検出は代替ではなく、前者が防ぎ後者が数える。
+
+### 検査
+
+`scripts/rules/piped-verification-rule.test.ts` が、配送文が仕組み・逃げ道・境界の 3 つを運ぶこと、この節が規則と却下した 2 案を単一ソースとして持つこと、そして `rule-delivery.md` の列挙表に行があることを固定する。発火・非発火そのものは `scripts/rules/delivered-rules.test.ts` が両方向から固定する。
+
+## この上限が届かないもの
+
+`BASH_MAX_OUTPUT_LENGTH` は **Bash ツールにだけ効く**。実測では `Read` ツールが tool_result の 10.6%（単一最大 18,991 トークン）、`Agent` が 2.3% を占めており、どちらもこの上限の対象外である。別の量として別途扱う。
+
+## 検査
+
+`scripts/lib/bash-output-cap.test.ts` が、配布設定に上限が宣言されていること、値が harness の既定 30,000 より小さい（＝実際に作動する高さである）こと、受け付ける最大 150,000 を超えないこと、そしてこの文書が設定と同じ数値を書いていることを固定する。**「宣言されている」だけでは不十分**で、30,000 以上に戻された上限は宣言があっても作動しない — この文書が書かれた理由がそれである。

package/prompts/collaboration-workflow/overview.md

@@ -0,0 +1,35 @@
+## Overview
+
+1. Issue を作成する
+2. Issue を元に実装提案を作る
+3. 計画コメントを Issue に残して Telegram 通知を送る
+4. 実装を進める
+5. 実装完了後に Issue へ完了コメントを投稿する
+
+### フェーズ分離
+
+ワークフローは 2 つのフェーズに分けて実行できる。
+
+- **Planning phase（`kickoff`）**: Step 1〜3 — Issue 作成・計画投稿・Telegram 通知で止まる。実装前にレビューや承認を挟みたい場合に使う。
+- **Execution phase（`fullrun #N`）**: Step 4〜5 — 既存 Issue の計画に基づいて実装・PR 作成・完了通知を行う。
+
+一括実行する場合は `fullrun new` で Step 1〜5 を通しで実行する。
+
+### 手順の置き場所（常時ロードとオンデマンドの分離）
+
+`kickoff` / `fullrun` / `halfrun` / `backlogrun` の**操作手順**は、常時ロードされる `CLAUDE.md` からは外され、`.claude/skills/workflow-commands/` に置かれている（joshuafolkken/kit#854）。`CLAUDE.md` に残るのはキーワードとスキルへの導線、およびスキルが読み込まれていない状態でも効く必要のある規則だけである。依存更新後の overrides / `devEngines` 検証手順も同様に `.claude/skills/dependency-update/` へ移した。**どの規則が「残す」側かは →「常駐ドキュメントと skill の分担（何を常駐に残すか）」が判定基準と全 4 件を定義する。**
+
+このドキュメントは引き続き**正典の詳細版**であり、スキルは操作手順である。両者は一致していなければならないので、片方だけを更新してはならない。
+
+### 出力の言語（`JOSH_SESSION_LANG`）
+
+ワークフローの出力言語は、環境変数 `JOSH_SESSION_LANG`（例: `ja` / `en`）で決まる。対象は「開発者との対話」と「成果物の散文」の**両方**であり、**変数が未設定・空・`.env` なしのときはどちらも `ja` を既定とする**。英語で書くなら `JOSH_SESSION_LANG=en` を設定する。
+
+- **対話は `JOSH_SESSION_LANG` に従う**: セッション中の説明・質問、および `halfrun` などで提示する **`AskUserQuestion` の選択肢ラベル・説明**。未設定の場合は `ja` を既定とする（1 語のプロンプトでは言語を判定できず、周囲の英語に流れてしまうため）。
+- **成果物の散文も `JOSH_SESSION_LANG` に従う**: Issue 本文、Issue／PR コメント（Step 3 の計画コメント、`pnpm josh followup` が自動投稿する完了コメントを含む）、Telegram 通知の本文（`--body` / `--notify-message`）。**未設定の場合は `ja` を既定とする。**
+- **設定に関わらず英語で固定するもの**（3 つ）:
+  1. **Issue／PR タイトル**: Step 1 のタイトル正規化ルールは変更しない。Issue 一覧の見通しを保ち、`pnpm josh git` が作るブランチ名を ASCII に保つため。
+  2. **コード内コメント、テストタイトル（`describe` / `it` / `expect`）、コミットメッセージ**: リポジトリのコード規約であり、開発者個人の言語設定とは別の軸で決まる。
+  3. **スクリプトが出力する固定文字列**: Telegram のヘッダーラベル（`Planning` / `Completion` など）、`Issue:` / `PR:` の URL ラベル、`--notify-message` 省略時の既定メッセージ。AI が書く文面ではなく、翻訳の仕組みも持たない。
+
+`JOSH_SESSION_LANG` は **開発者個人の設定**であり、`.env`（gitignore 済み・非コミット）に置く。リポジトリ共有の設定ではないため、consumer ごと・開発者ごとに自由に変えてよい。`josh sync` で上書きされることもない。**解決値は毎ターン、`UserPromptSubmit` フック（`pnpm josh session:lang`）が 1 度だけコンテキストへ差し込む**ので、エージェントが `.env` を読まなくても言語を取り違えない（最初のターンで二重解決していたため `SessionStart` からは外した）。フック出力を表示しないハーネス（Codex / Gemini / Cursor）は従来どおり `.env` を読んで解決する。この変数がスクリプトの挙動を変えることはなく（`session:lang` が解決値を表示のために読むだけ）、制御するのは AI が書く文面の言語だけである。

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

@@ -0,0 +1,85 @@
+## Step 3: 計画コメントを記録して通知する
+
+1. 提案を人間が判断する
+2. 採用した計画を Issue に記録する（Issue body が空の場合は `gh api -X PATCH repos/{owner}/{repo}/issues/<N> -f body="<plan>"` で body に書き込む。body が既にある場合は `pnpm josh issue:comment <N> --body-file <path>` でコメント追加する）
+3. Telegram で計画開始を通知する:
+
+   ```bash
+   pnpm josh notify --task-type planning --issue-url "<issue-url>" --body=$'- <bullet1>\n- <bullet2>'
+   ```
+
+   - `--task-type` はヘッダーのアイコンを決める（`planning` 📋 / `completion` ✅ / `failure` ❌ / `warning` ⚠️ / `kickoff_retry` 🔄 / `confirmation` ⏸️）
+   - `warning` は **`pnpm josh followup` が自分で送る種別** であり、手で打つものではない（マージは成功したが実行記録を残せなかった場合など、`failure` と呼ぶと嘘になる事象のための種別: joshuafolkken/kit#1628）
+   - `--repo-name` と `--issue-title` は未指定なら `gh` から自動取得される
+   - Issue URL を必ず含める
+   - 箇条書きの間に改行を入れて読みやすくする
+   - `kickoff` コマンドの場合はここで **停止** する（実装に進まない）
+
+4. ワークフロー開始時点で作業ツリーにステージング済みまたは変更済みのファイルが既にある場合（例: ユーザーが事前に kit/設定ファイルをステージングした場合）、先に変更を退避する:
+   ```bash
+   git stash push -m "plan: pre-existing changes"
+   ```
+5. メインブランチへ切り替えて最新を取得する:
+   ```bash
+   git switch main && git pull
+   ```
+6. 依存関係を最新化し、脆弱性を確認する（**必須—作業ツリーに変更があっても省略してはならない**。`pnpm latest` は内部で `pnpm audit` も実行する）:
+   ```bash
+   pnpm latest
+   # 脆弱性が見つかった場合: package.json の overrides に対象バージョンを追加して pnpm install 後に再確認
+   ```
+   ステップ 4 で stash した場合は、ここでメッセージ指定で復元する（位置指定や引数なしの `git stash pop` は使わない — stash は全 work tree が共有する 1 本のスタックで、別のレーンの stash を取り込む恐れがある。joshuafolkken/kit#2050）:
+   ```bash
+   pnpm josh stash:pop "plan: pre-existing changes"
+   ```
+7. **作業サマリを提示してから**実装を開始する（`CLAUDE.md` の Code Change Rules Step 0）。書式は下記「報告フォーマット（平易な概要 ＋ 技術詳細）」に従う — `JOSH_SESSION_LANG` の言語で、平易な概要 3 行を先頭に置き、技術詳細（触るファイル / モジュール、アプローチとその理由、副作用・スコープ外、テスト宣言）はその下に置く。
+
+   `fullrun` / `halfrun` / `backlogrun` では Issue ごとに 1 回、実装に着手する直前に提示する。**Issue body が既に埋まっていて計画コメントを投稿しなかった場合も必ず提示する**（この場合ユーザーには他に作業内容が見えないため）。`kickoff` は既に計画を Issue に投稿するので対象外。
+
+   提示は説明のためであり、**確認待ちで停止する意味ではない**。同一ターンでそのまま実装へ進むこと（停止条件にはならず、`/code-review` → `followup` のチェーン規則にも影響しない）。セッション向け出力のみに留め、Issue コメントとしては投稿しない。
+
+8. 実装完了後、**lint/test より前に** `prompts/refactoring.md` に従ってリファクタリングを適用する（高・中優先度項目が残らなくなるまで収束させる）
+9. 検証ゲート（`CLAUDE.md` の Completion gate）を実行する
+
+`pnpm josh git` の基本実行（`-y` で確認プロンプトをスキップ）。**子はバージョンを上げない**（joshuafolkken/kit#1486）。子の PR に `package.json` の version 変更は入らず、版を決めるのは main の履歴を読む `pnpm josh release` ただ 1 箇所である。
+
+```bash
+pnpm josh git -y "<issue-title> #<issue-number>"
+```
+
+> **Note**: Issue タイトルは `pnpm josh git` を実行する前に、簡潔で明瞭な英語に整えること。
+> 日本語で書かれている場合は英語に変換する。すでに英語で書かれている場合でも、文法・明確さ・簡潔さの観点で改善できるなら書き換えて良い（AI ツールは実装前にタイトル品質を判断する）。
+> いずれの場合も `gh api -X PATCH repos/{owner}/{repo}/issues/<number> -f title="<english-title>"` で GitHub Issue タイトルを合わせて更新する。
+
+### Recovery after failed push (pre-push hook blocked)
+
+If `pnpm josh git -y` fails at the push step (e.g. blocked by the pre-push hook), fix the blocking issue and then 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 generates `closes #N`, causing the Issue to remain open after merge.
+
+`fullrun` フローでは、コミットの前に `/code-review` スキルを実行する（下記「レビュー工程は実装セッションがコミット前に実行する」と同じ時期であり、以前ここに書かれていた「コミット後」は誤りだった）。高・中優先度の指摘が見つかった場合は修正を行い、再度 `pnpm josh review:brief` と `/code-review <what it printed>` を実行してから次のステップへ進む（**2 周目は差分全体の読み直しではなく修正の検証パス**。下記「レビュー工程は実装セッションがコミット前に実行する」）。**レビューは合計 2 回まで**であり、2 回目を終えた時点で残る Low/Medium は follow-up Issue に切り出し、**現在の Issue が閉じる前に `pnpm josh epic:bundle <新規>` を実行して答えに従う** — `add_to_epic` / `create_epic` は Tier A で、対応する `pnpm josh epic --add` / `pnpm josh epic` を実行する（本文の手編集は不可）。`ask` も Tier A であり、推奨する epic を選んで追加し理由を記録する（停止も park もしない — joshuafolkken/kit#1339）。`none` は何もしない。**この起票と束ね直しは `pnpm josh git -y` の後・`pnpm josh followup` の前に置く** — コードを変えない作業なので CI 待ちの中に収まり、Issue が閉じるのはマージ時点なので期限も満たす（`prompts/review.md` → "Review round cap"、→「後追い Issue は起票した直後に EPIC へ束ね直す」）。
+
+**`/code-review` の出力で停止してはならない**という連鎖規則の本文は、`.claude/skills/workflow-commands/chain-rule.md` にある — 停止してよい 2 状況、決定表、アンチパターン集、ターン終端セルフチェックはすべてそこが単一ソースである（joshuafolkken/kit#1186）。
+
+### レビュー工程は実装セッションがコミット前に実行する
+
+ワークフロー内のレビュー工程（各フローの `pnpm josh review:brief` と `/code-review <what it printed>`）は、**実装したセッション自身が、コミットの前に**インラインで実行する。対象は `git diff main`、実行時期は検証ゲートの後半（refactor → **`pnpm josh gate` をレビューと同時に開始し、コミット前に join する** → `/code-review` with the brief `pnpm josh review:brief` prints）であり、`fullrun` / `halfrun` / `backlogrun` のいずれも同じ時期・同じ対象でレビューする。1 周目の High/Medium はその場で修正し、**指摘を潰し切ってから最初のコミットを作る**。ただし**2 周目は 1 周目の反復ではなく、修正の検証パスである** — 対象は差分全体ではなく 1 周目の修正が触った範囲（fix delta）で、問いは「各指摘は実際に閉じたか／修正自体が欠陥を入れていないか」に変わる。基準は変わらず、閉じていない指摘は元の severity のまま残る（`prompts/review-rubric.md` → "The second round is a verification pass, not a second full review"）。**再実行は 2 周まで**であり、2 周を終えた時点で残る High 以外の指摘は、**内容から機械的に決まる 3 分岐**に振り分ける（`prompts/review.md` → "Review round cap"）。分岐は、既に触れているファイル内で数行・設計判断なしに閉じるなら**その場で直す（新しいレビュー巡は起こさない）**、実行経路に届くか判断が要るなら**起票する**、利用者に届かない Low なら**PR に 1 行残して落とす**、の 3 つ。同じ根本判断に帰着する複数の指摘は**1 件の Issue にまとめる**。起票する場合、**切り出しは起票では終わらない** — 起票に続けて `pnpm josh epic:bundle <新規>` を実行し、`add_to_epic` / `create_epic` は確認せずに実行する。**ただし PR を開くフロー（`fullrun` / `backlogrun`）では、起票と束ね直しの実行位置はコミットの前ではなく `pnpm josh git -y` の後・`pnpm josh followup` の前**である。`halfrun` は PR を開かず、隠れる先の CI が無いので、振り分けが決まった時点で実行する（→「後追い Issue は起票した直後に EPIC へ束ね直す」）。したがって PR に貼るレビューコメントは発生しない。
+
+**PR を開く位置は 2 周の間である**（joshuafolkken/kit#1261）。1 周目の修正が入ったら `pnpm josh gate` → join → `pnpm josh git -y` の順で進め、**2 周目は そのコミットが起動した CI と並走させる**。join とコミットの間でツリーを書き換えるものは何も無い（joshuafolkken/kit#1486 で子のバージョン上げが消えた）ので、コミットが乗るゲートはそのツリーちょうどを覆い、2 周目のブリーフは `Already verified` のままである。2 周目がその場修正を出した場合だけ、同一ブランチへの追加コミットが 1 つ増え、そのコミットに対して CI が回り直す — マージが待つのはその結果である。1 周目が clean なら 2 周目自体が無いので、順序は従来どおり。単一ソースは `.claude/skills/workflow-commands/chain-rule.md` → "The pull request opens between the rounds, so CI runs beside round 2"。
+
+**その追加コミットは、ゲートより先に push する**（joshuafolkken/kit#1326）。修正が届く単一チェック（`pnpm josh lint:related` / `pnpm josh cspell:dot` / `pnpm josh test:related` / そのプロジェクト自身の型チェック）を回してから `pnpm josh git -y "<title> #<N>"` を打ち、`pnpm josh gate` はその push が起動した CI と並走させて **`pnpm josh followup` の前に join する**。先に push しても未検証のコードを送ることにはならない — commit / push フックがステージ済みファイルの lint・スペルチェックと型検査、そしてユニット全件を走らせ、CI 側の `Checks` ジョブは `pnpm josh gate --verbose` を実行するからである。それでも join を省いてよいわけではない: `followup` は PR のチェックだけを読み、ゲートの記録は読まない。ゲートが赤なら直して同じ単一チェックを回し直し、もう一度 `pnpm josh git -y` を打つ。追い越された CI は `ci.yml` の `concurrency: cancel-in-progress: true` によって打ち切られ、マージが待つのは常に HEAD コミットのチェックである。マージ条件（必須チェック全緑・ゲート緑・変更要求なし）は一切緩めない。単一ソースは `.claude/skills/workflow-commands/chain-rule.md` → "The round-2 fix commit is pushed before its gate"。
+
+**2 周目が clean なら、その結果を読んだターンでマージを打つ**（joshuafolkken/kit#1333）。joshuafolkken/kit#1326 の run（PR #1327）では、CI がレビュー 2 周目の内側に完全に隠れてもなお、全チェック緑（06:34:37）からマージ（06:36:51）まで 134 秒が残り、うち **19 秒はレビュー結果を読んだターンと `followup` を打つターンが別だっただけの空白**だった（同 run はモデル 1 往復あたり平均 10.1 秒・67 往復）。clean かどうかは判断ではなく機械的に決まり、条件は 2 つある — **確定した High が残っていないこと**と、3 分岐の 1（その場で直す）に振り分けた指摘が 1 件も無いこと。High はそもそも 3 分岐のいずれにも入らないので、branch 1 の条件だけでは High について何も言っていない — 2 周を終えてなお残る High は `confirmation` 通知を送って run を止める側であり、マージは打たない。**Low だけが出た周は clean である**（Low は分岐 2 か 3 に入り、どちらもコードを 1 行も変えない）。起票（分岐 2）と PR への 1 行注記（分岐 3）はコードを 1 行も変えないので、`pnpm josh epic:bundle` まで含めて**同じターンのマージ発行より前**に置き、最後の 1 つが返った時点でマージを打つ。**検証は何ひとつ省かない** — ゲートの join と緑、必須 CI チェックはいずれも従来どおり読み、`followup` が待つものも変わらない。縮むのは「読んでから打つまで」の空白だけである。2 周目がその場修正を出した場合はこの規則の対象外で、直前の段落が定める順序（単一チェック → push → ゲートを CI と並走 → join → マージ）に入る。単一ソースは `.claude/skills/workflow-commands/chain-rule.md` → "A clean second round issues the merge in the same turn"。
+
+**そのゲートは 1 ラン 1 回であって、1 編集 1 回ではない**（joshuafolkken/kit#1246）。kit#1242 が決めたのは 1 回のゲートを**いつ**開始するかであって、**何回**回るかには触れていない。実測（kit#1241）では 49.1 分のランでゲートが 10 回・合計 8.2 分を占め、うち 6 回はレビュー開始前の「いま入れた編集が通ったか」の確認で、答えを出したのは毎回 lint か cspell の 1 チェックだけだった。**実装中は、単一チェックを名前で回す**（`pnpm josh lint:related` / `pnpm josh cspell:dot` / `pnpm josh test:related` / そのプロジェクト自身の型チェック）。**そこでのユニットチェックは絞り込んだ側**である（joshuafolkken/kit#1257）— `pnpm josh test:related` は変更ファイルが到達するテストだけを走らせ、絞り込めないときは全件に戻ってその旨を印字する。全件を走らせる `pnpm josh test:unit` は、コミット前のゲートが回すものとして変わらない。一度ゲートを回した後は、各ブロックのヘッダが実際に走ったコマンドを印字しているので、そこからコピーすればよい。全ゲートか単一チェックかは**「レビューが始まったか」**だけで決まり、編集の大きさでは決まらない。レビューと同時にゲートを開始した後は、赤の修正も指摘の修正もツリーを変えて前の結果を陳腐化させるので、単一チェックに戻るのではなく全ゲートを回し直す。分岐表は `.claude/skills/workflow-commands/chain-rule.md` → "The gate runs beside this review, not in front of it" にある。
+
+**フレッシュコンテキストのサブエージェントに委譲する方式（kit#752）と、PR 作成後に実行して結果を PR コメントとして投稿する方式（kit#758）は、これを置き換えるものではなく、これに置き換えられた。** 別コンテキストのレビュアーは実装者のバイアスを持ち込まない利点があったが、毎ラウンド変更を読み直し、指摘のたびに修正コミット・push・必須チェック 6 件の CI 再実行が走るため、PR 作成からレビュー確定まで 10 分を超えるのが常態だった（kit#758 の PR 自身が 3 ラウンドで 10 分 53 秒）。**レビュアーが実装者と同一コンテキストである点は、この方式が受け入れているトレードオフである** — 作者の思い込みが素通りする確率は上がるが、コミット前セルフレビュー（`prompts/review.md`）は従来どおり必須のゲートとして残る。

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

@@ -0,0 +1,23 @@
+## Step 2: 提案依頼（AI 共通）
+
+Issue URL を渡して、次の観点で提案を依頼する。
+
+- 要件の分解
+- 実装候補（複数案がある場合は比較）
+- 影響ファイル
+- テスト方針（unit/e2e）
+- リスクと回避策
+
+最小プロンプト:
+
+```md
+Issue: <issue-url>
+
+以下を提案してください:
+
+1. 要件分解
+2. 実装方針（必要なら複数案）
+3. 変更予定ファイル
+4. テスト戦略（unit/e2e）
+5. リスクと対策
+```