@joshuafolkken/kit 1.1455.0 → 1.1471.0

package/prompts/collaboration-workflow/issue-citation.md

@@ -2,33 +2,27 @@
 
 ## セッション向け出力で Issue はリンク＋セッション言語の短い要約で参照する（joshuafolkken/kit#1758）
 
-番号だけの言及では、読み手は番号を内容に解決するために毎回 GitHub を開くことになる（`docs/maintainers/issue-citation-rationale.md` → "Why the rule exists"）。発火点が `CLAUDE.md` に常駐している理由は `docs/maintainers/issue-citation-rationale.md` → "Why the trigger is resident in CLAUDE.md" にある。
+理由は `docs/maintainers/issue-citation-rationale.md` → "Why the rule exists"、発火点の常駐理由は `docs/maintainers/issue-citation-rationale.md` → "Why the trigger is resident in CLAUDE.md"。
 
-**規則**: セッション向け出力で Issue を指すときは、次の 2 つを必ず添える。
+**規則**: セッション向け出力で Issue を指すときは、次の 2 つを必ず添える（対応前の「これから走らせる」「待機中」「対象外」の言及も含む）。
 
 1. 番号にチケットへの markdown リンク
-2. セッション言語（`JOSH_SESSION_LANG`、既定 `ja`）の短い要約タイトル
-
-書き方の例:
+2. セッション言語（`JOSH_SESSION_LANG`、既定 `ja`）の短い要約タイトル（全訳でなくてよい）
 
 - `[#<N>](https://github.com/<owner>/<repo>/issues/<N>) — <その Issue が何をするものかの短い要約>`
 
-**この引用行は手で組み立てるものではなく、`pnpm josh issue:cite <N> [<N> ...]` が出す。** 番号を並べて渡すと、貼れる引用行を 1 呼び出しでまとめて出す（複数 Issue に 1 回、他リポジトリは `--repo <owner/repo>` あるいは `owner/repo#N` 表記。`docs/maintainers/issue-citation-rationale.md` → "Why issue:cite prints the line"）。要約はその Issue のタイトルをそのまま用いる。詳細は [docs/josh-commands.md](https://github.com/joshuafolkken/kit/blob/main/docs/josh-commands.md) の `josh issue:cite` を参照。josh がセッション向けに出す警告・進捗行・要約行の Issue 番号は、はじめからリンク形で出るので、転記するときに組み直さなくてよい。コミットメッセージ・PR 本文・イベント行・Telegram 本文など GitHub やプログラムが読むために素の `#N` のまま出る行を写すときは、引用形に直す（`docs/maintainers/issue-citation-rationale.md` → "Why josh prints the citation form itself"）。
-
-**要約タイトルは全訳ではなく要約でよい。** 何をするものか分かれば足りる。長い訳を作ることが目的ではない。`issue:cite` が出すタイトルを、必要ならセッション言語に言い換えて使う。
-
-**対応前の言及も対象である。** 「これから走らせる」「待機中」「対象外」を並べる場面も含む。
+**この引用行は `pnpm josh issue:cite <N> [<N> ...]` が出す。** 複数 Issue は 1 呼び出しにまとめ、他リポジトリは `--repo <owner/repo>` か `owner/repo#N` 表記（`docs/maintainers/issue-citation-rationale.md` → "Why issue:cite prints the line"、詳細は [docs/josh-commands.md](https://github.com/joshuafolkken/kit/blob/main/docs/josh-commands.md) の `josh issue:cite`）。タイトルは必要ならセッション言語に言い換える。素の `#N` の行（コミットメッセージ・PR 本文・イベント行・Telegram 本文）を写すときは引用形に直す（`docs/maintainers/issue-citation-rationale.md` → "Why josh prints the citation form itself"）。
 
 ### 適用範囲
 
 **対象** — セッション向け出力。会話の説明、計画の提示、進捗報告、完了報告、`AskUserQuestion` の選択肢。
 
-**対象外** — GitHub 上の artifact prose（Issue 本文、Issue / PR コメント）。GitHub は issue 参照を自動でリンクし、ホバーでタイトルを出すため、この規則が解決しようとしている問題がそもそも起きない。
+**対象外** — Issue 本文、Issue / PR コメント。
 
 ### 英語固定の 3 つとは衝突しない
 
-英語のままにするものは従来どおり 3 つ（`overview.md` →「出力の言語（`JOSH_SESSION_LANG`）」）。番号に添えるセッション言語の要約は GitHub 上の**タイトル**ではなく、セッション内の散文の一部なので、タイトルの英語固定とは矛盾しない。
+要約はタイトルではなくセッション内の散文なので、`overview.md` →「出力の言語（`JOSH_SESSION_LANG`）」の英語固定とは矛盾しない。
 
 ### 停止時の担保（joshuafolkken/kit#2247）
 
-`Stop` フック `pnpm josh stop:guard` が返信の地の文に裸の `#N` を見つけると**停止をブロックし**、その番号と `pnpm josh issue:cite <N...>` の実行形を差し戻す。差し戻されたら、その実行形で引用し直す（仕組みは `docs/maintainers/issue-citation-rationale.md` → "How the Stop hook delivers it"）。検出が外す範囲は [docs/josh-commands.md](https://github.com/joshuafolkken/kit/blob/main/docs/josh-commands.md) の `josh stop:guard` を参照。
+`Stop` フック `pnpm josh stop:guard` は返信の地の文に裸の `#N` があると停止をブロックし、`pnpm josh issue:cite <N...>` の実行形を差し戻す。差し戻されたらその実行形で引用し直す（`docs/maintainers/issue-citation-rationale.md` → "How the Stop hook delivers it"、検出が外す範囲は [docs/josh-commands.md](https://github.com/joshuafolkken/kit/blob/main/docs/josh-commands.md) の `josh stop:guard`）。

package/prompts/collaboration-workflow/issue-template.md

@@ -1,6 +1,6 @@
 ## Step 1: Issue 作成テンプレ
 
-タイトルは簡潔で明瞭な英語で記載する（「出力の言語（`JOSH_SESSION_LANG`）」の例外）。日本語のタイトルや改善できる英語のタイトルは、実装開始前に書き換え、`gh api -X PATCH repos/{owner}/{repo}/issues/<N> -f title="<title>"` で GitHub 側も合わせる。本文は次の最小テンプレートの節をすべて含める:
+タイトルは簡潔で明瞭な英語にする（「出力の言語（`JOSH_SESSION_LANG`）」の例外）。日本語や改善できるタイトルは実装開始前に `gh api -X PATCH repos/{owner}/{repo}/issues/<N> -f title="<title>"` で書き換える。本文は次のテンプレートの節をすべて含める:
 
 ````md
 ## 背景
@@ -50,45 +50,45 @@
 
 ### `## 背景` 直下の宣言と分類ラベル
 
-起票は `pnpm josh issue:file "<title>" --body-file <本文ファイル> --depth <n>` で行う。本文の検査（`pnpm josh issue:lint <path>` と同じ）と、下表の宣言から決まる分類ラベルの付与は、このコマンドが 1 回の作成リクエストで行う。**宣言を選ぶのは起票者の判断であり、コマンドは単語から推測しない。** `- 人の判断:` の行は必須で、`issue:file` だけが検査し（`issue:lint` は見ない）、`auto-ok` の判定に使う。判定は人が依頼した起票も含めてすべて同じ（`scripts/issue/issue-auto-ok.ts`、`docs/how-to/run-backlog.md`）。**`不要` を宣言する起票には `--label run:lane`（kit 自身の検証の不具合なら `run:solo`）も付ける** — 付いていなければ `issue:file` が拒否する。
+起票は `pnpm josh issue:file "<title>" --body-file <本文ファイル> --depth <n>` で行い、本文の検査（`pnpm josh issue:lint <path>` と同じ）と下表のラベル付与はコマンドが行う。**宣言は起票者が選ぶ。** `- 人の判断:` の行は必須で、`issue:file` が検査し `auto-ok` の判定に使う（`scripts/issue/issue-auto-ok.ts`、`docs/how-to/run-backlog.md`）。`不要` を宣言する起票には `--label run:lane`（kit 自身の検証の不具合なら `run:solo`）も付ける — 無ければ `issue:file` が拒否する。
 
-| 宣言                   | 付くラベル                        | 選ぶ基準                                                                                                        |
-| ---------------------- | --------------------------------- | --------------------------------------------------------------------------------------------------------------- |
-| `- 種別: 不具合`       | `bug`                             | 報告された症状を直す。`- 種別: 非不具合` とどちらか一方を必ず置く                                               |
-| `- 目的: 機能追加`     | `enhancement`                     | 新しい機能。不具合修正・文書のみ・依存更新・保守作業には書かない                                                |
-| `- 目的: 機能改善`     | `enhancement`                     | 既存機能の改善。目的が曖昧なら期待結果と受け入れ条件を具体化してから選ぶ                                        |
-| `- 互換性: 破壊的変更` | `breaking-change`                 | 既存の利用者・API・設定の契約を変える。移行措置があっても書き、廃止対象と影響を説明する                         |
-| `- 種別: 振る舞い変更` | なし                              | AI の振る舞いを変える。`## 発火点` / `## ベースライン` / `## 再現` の 3 見出しが必須になる                      |
-| `- 人の判断: 不要`     | `auto-ok`（除外ラベルがなければ） | 方針の判断・外部アカウント・人の目視確認のどれも要らない。`- 人の判断: 要（<どれか>）` とどちらか一方を必ず置く |
+| 宣言                   | 付くラベル                        | 選ぶ基準                                                   |
+| ---------------------- | --------------------------------- | ---------------------------------------------------------- |
+| `- 種別: 不具合`       | `bug`                             | 報告された症状を直す（無ければ `- 種別: 非不具合`）        |
+| `- 目的: 機能追加`     | `enhancement`                     | 新しい機能。修正・文書・依存更新・保守には書かない         |
+| `- 目的: 機能改善`     | `enhancement`                     | 既存機能の改善。目的が曖昧なら受け入れ条件を具体化してから |
+| `- 互換性: 破壊的変更` | `breaking-change`                 | 契約を変える。移行措置があっても書き、廃止対象と影響を書く |
+| `- 種別: 振る舞い変更` | なし                              | AI の振る舞いを変える。下の 3 見出しが必須                 |
+| `- 人の判断: 不要`     | `auto-ok`（除外ラベルが無ければ） | 方針の判断・外部アカウント・目視確認のどれも要らない       |
 
-- **持ち主の意図と違う動きは、コード・コメント・テストに書かれた設計どおりでも `- 種別: 不具合` とする。** コードは意図を写したもので、意図そのものではない。変更の形（コードか文書か）でも決めない。例: コメントとテストに固定されたまま意図より広く働く自動付与、文書だけでも意図と違う分類を生む基準
-- **`- 種別: 不具合` の Issue の回帰テストは、利用者が症状を見たのと同じ粒度で書く。** 修正前のツリーでも緑になるテストは `pnpm josh git -y` がコミットを拒否する（joshuafolkken/kit#2448）
-- **`bugfix` は PR のリリース分類であり、Issue の `bug` の代わりにしない。** `enhancement` と `breaking-change` の両方を持つ Issue の PR は `breaking-change` 一つに分類する
-- **`## 発火点`** の名前は `prompts/collaboration-workflow/rule-delivery.md` の配送表と突き合わされる
-- **`## ベースライン`** の測定コマンドは、マージ後に `pnpm josh measure:rerun <N>` が再実行して before / after を印字する（作者が `OWNER` / `MEMBER` / `COLLABORATOR` の Issue に限る）
-- **公開しないと利用側が使えない変更には `--release` を付ける**（既存 Issue は `pnpm josh issue:release <N>`）。リリース用 Issue の blocker になる（`docs/josh-commands-backlog.md` → `josh issue:release`）
+- **持ち主の意図と違う動きは、コード・コメント・テストに書かれた設計どおりでも `- 種別: 不具合` とする。** 例: コメントとテストに固定されたまま意図より広く働く自動付与、文書だけでも意図と違う分類を生む基準
+- `- 種別: 不具合` の回帰テストは、利用者が症状を見たのと同じ粒度で書く。修正前のツリーでも緑になるテストは `pnpm josh git -y` が拒否する（joshuafolkken/kit#2448）
+- `bugfix`（PR のリリース分類）を Issue の `bug` の代わりにしない。`enhancement` と `breaking-change` の両方を持つ Issue の PR は `breaking-change` にする
+- `## 発火点` の名前は `prompts/collaboration-workflow/rule-delivery.md` の配送表と突き合わされる
+- `## ベースライン` の測定コマンドは、マージ後に `pnpm josh measure:rerun <N>` が再実行して before / after を印字する（作者が `OWNER` / `MEMBER` / `COLLABORATOR` の Issue に限る）
+- 公開しないと利用側が使えない変更には `--release` を付ける（既存 Issue は `pnpm josh issue:release <N>`、`docs/josh-commands-backlog.md` → `josh issue:release`）
 
 ### 起票元へのバックリンク（`## Origin` / `## Upstream issues`）
 
-**別リポジトリのセッションから起票した Issue には、起票元へのリンクを双方向で必ず書く。** 欠陥がどのプロジェクトでどう現れたかの証拠は起票元にしかない。
+**別リポジトリのセッションから起票した Issue には、起票元へのリンクを双方向で必ず書く。**
 
-| 方向                  | 置き場所                      | 固定見出し              | 内容                                                 |
-| --------------------- | ----------------------------- | ----------------------- | ---------------------------------------------------- |
-| 上流 Issue → 起票元   | 上流 Issue の本文             | `## Origin`             | 起票元 Issue（`owner/repo#N` または URL）            |
-| 起票元 Issue → 上流   | 起票元 Issue の本文かコメント | `## Upstream issues`    | そこから起票した上流 Issue を全件列挙する            |
-| 起票元 Issue → 未起票 | 起票元 Issue の本文かコメント | `## Upstream candidate` | 第三者リポジトリへ報告する候補（**未起票**）と下書き |
+| 方向            | 置き場所               | 固定見出し              | 内容                       |
+| --------------- | ---------------------- | ----------------------- | -------------------------- |
+| 上流 → 起票元   | 上流 Issue の本文      | `## Origin`             | 起票元 Issue               |
+| 起票元 → 上流   | 起票元の本文かコメント | `## Upstream issues`    | 起票した上流 Issue 全件    |
+| 起票元 → 未起票 | 起票元の本文かコメント | `## Upstream candidate` | 第三者への報告候補と下書き |
 
-- **見出しは固定する**（grep で見つかるように）。起票元の本文が確定済みなら、同じ見出しでコメントに書く
-- **リンクは必ずリポジトリ修飾する**（`owner/repo#N` または完全 URL）。裸の `#N` は上流側で別 Issue に解決される
-- **チェックボックス行（`- [ ] owner/repo#N`）で書かない。** 散文か素の箇条書き（`- owner/repo#N`）にする — チェックボックス付きの他リポジトリ参照は epic の自動クローズを止める
-- **未起票の候補は `## Upstream candidate` に置く。** third-party への報告はユーザーの明示指示まで起票しない（→「第三者リポジトリへの書き込みは Tier C（明示指示が必要）」）
+- 見出しは固定する。起票元の本文が確定済みなら、同じ見出しでコメントに書く
+- **リンクは必ずリポジトリ修飾する**（`owner/repo#N` または完全 URL）
+- チェックボックス行（`- [ ] owner/repo#N`）で書かず、散文か素の箇条書き（`- owner/repo#N`）にする（epic の自動クローズを止めるため）
+- third-party への報告はユーザーの明示指示まで起票しない（→「第三者リポジトリへの書き込みは Tier C（明示指示が必要）」）
 - 割り込みで起票する手順は `upstream-interrupt.md`
 
 ### 複数 Issue に分割するときの epic Issue
 
-**1 つの要望を 2 件以上の Issue に分割したら、件数や順序の有無にかかわらず常に epic を作る。** 分割の設計図を、最初にクローズされる子 Issue ではなく閉じない置き場に残すためである。作成は `pnpm josh epic`、点検は `pnpm josh epic:check <E>`、子の追加は `pnpm josh epic --add` で行い、本文を手で編集しない。epic 自体を実装ランに渡さない（`backlogrun #<E> --only` が子を回す）。コマンドと本文の記法は `epic-commands` スキル →「Creating an epic」。
+**1 つの要望を 2 件以上の Issue に分割したら、件数や順序の有無にかかわらず常に epic を作る。** 作成は `pnpm josh epic`、点検は `pnpm josh epic:check <E>`、子の追加は `pnpm josh epic --add` で行い、本文を手で編集しない。epic 自体を実装ランに渡さない（`backlogrun #<E> --only` が子を回す）。記法は `epic-commands` スキル →「Creating an epic」。
 
-**`josh` が使えない環境での手作業手順:**
+`josh` が使えない環境での手作業手順:
 
 1. 子 Issue をすべて起票し、番号を控える。
 2. ラベルを用意する: `gh api repos/{owner}/{repo}/labels -f name=epic -f color=5319e7 -f description="Tracks a batch of child issues from one split" --silent 2>/dev/null || true`
@@ -115,4 +115,4 @@
 
 4. 順序があるときだけ、別ステップで依存を足す（Issue 番号ではなく database id を渡す）: `gh api repos/{owner}/{repo}/issues/<N2>/dependencies/blocked_by -F issue_id="$(gh api repos/{owner}/{repo}/issues/<N1> --jq .id)"`
 
-各手順の理由と経緯は kit の `docs/maintainers/epic-commands-rationale.md` →「Creating an epic by hand」。
+各手順の理由は kit の `docs/maintainers/epic-commands-rationale.md` →「Creating an epic by hand」。

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

@@ -1,72 +1,63 @@
 ## 運用ルール
 
 - 通知は CI チェック成功後に投稿する
-- 通知投稿に失敗しても、実装完了の事実はログで確認できるようにする
-- 自動投稿される Issue コメント文面は `JOSH_SESSION_LANG` の言語（未設定なら `ja`）で記載する。Issue タイトルだけは英語で固定する
+- 通知投稿に失敗しても、実装完了の事実をログで確認できるようにする
+- 自動投稿する Issue コメントは `JOSH_SESSION_LANG` の言語（未設定なら `ja`）で書く。Issue タイトルだけは英語
 
 ### CI チェック失敗時の対応
 
-`pnpm josh followup` は Required チェックのみ待機するが、**Workers Builds（Cloudflare デプロイ）など非 Required チェックが失敗した場合も必ずユーザーに明示的に報告する**。
+`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` に失敗チェック名・原因・未解決である旨を記載する。**完了コメントに失敗を隠してはならない**
-- ユーザーへの報告も失敗の事実を正直に伝える（「成功」として扱わない）
+- `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` に書く。**完了コメントに失敗を隠してはならない**
+- ユーザーへの報告でも失敗を「成功」として扱わない
 
 ### ほかの単一ソースにある規則
 
-auto-merge と `completion` 通知・明示的な起動・`confirmation` 通知・作業ツリーの保持・overrides の保護は、それぞれの単一ソースにあり、ここには繰り返さない。移動先の一覧は `docs/maintainers/operating-rules-rationale.md` → "Rules that moved to their single source"。
+auto-merge と `completion` 通知・明示的な起動・`confirmation` 通知・作業ツリーの保持・overrides の保護の置き場は `docs/maintainers/operating-rules-rationale.md` → "Rules that moved to their single source"。
 
 ### 指示されていない行動は取らない
 
-規則そのもの — 共有状態に影響する操作はその場で明示指示されたものだけ実行し、マージを認可するのはどのコマンドの起動か — は `CLAUDE.md` → "Git Rules" に常駐している。ここに書くのは、その規則を実行するときの細則である。対象には共有ブランチへの push・外部通知の追加送信・リポジトリ設定の変更も含まれる。
+`CLAUDE.md` → "Git Rules" の細則。対象には共有ブランチへの push・外部通知の追加送信・リポジトリ設定の変更も含む。
 
 - auto-merge の本文は [`followup.md`](../../.claude/skills/workflow-commands/followup.md)、`backlogrun` の子への継承は [`backlogrun-child.md`](../../.claude/skills/workflow-commands/backlogrun-child.md)
 - `kickoff` / `pnpm josh followup` 単独実行は文書化されたスコープで終了する。PR が OPEN のまま完了したら状態を報告して停止する
-- 「チェックが全部 green だから次のステップに進む」は承認ではない
-- **deny と配送ガードは実装であって規則ではない。** `gh pr merge`・force push・ブランチ削除の直接実行は `.claude/settings.json` の `permissions.deny` と `pnpm josh rule:guard` が拒否する（一覧は各ファイルと [`rule-delivery.md`](./rule-delivery.md) →「配送されている規則」）が、それらは規則より狭い — 取りこぼす綴りを禁じ、ツールが通したことを許可と読ませないのは `CLAUDE.md` → "Git Rules" である。`fullrun` の auto-merge は `pnpm josh followup` の内部から gh を起動するため影響を受けない
-- **共有状態に影響する操作（このセクションの対象＝Tier C）は迷ったら確認する。** 確認のコストは低いが、意図しない操作の巻き戻しは高コスト
-- ただしこの「迷ったら確認」は Tier C に限る。**可逆な実装・設計判断（Tier A）は別ルール**（下記「意思決定の自律ポリシー」）に従う
+- 「チェックが全部 green」は次へ進む承認ではない
+- **deny と配送ガードは実装であって規則ではない。** `gh pr merge`・force push・ブランチ削除は `.claude/settings.json` の `permissions.deny` と `pnpm josh rule:guard` が拒否する（一覧は [`rule-delivery.md`](./rule-delivery.md) →「配送されている規則」）が、規則より狭い。ツールが通したことを許可と読まない。`fullrun` の auto-merge は `pnpm josh followup` の内部から gh を起動するため影響を受けない
+- 共有状態に影響する操作（Tier C）は、迷ったら確認する。可逆な実装・設計判断（Tier A）は下記 "decision-autonomy" に従う
 
 ### no-self-staging — git index を勝手に変更しない（自律 staging の禁止）
 
-規則そのもの — index はユーザーのスナップショットであり、自分の判断でステージ・コミットしない — は `CLAUDE.md` → "Git Rules" に常駐している。ここに書くのは、その規則を実行するときの細則である。index には履歴がなく、上書きされた直前のステージ状態は復元できない（経緯は `docs/maintainers/operating-rules-rationale.md` → "Why the index is the user's"）。
-
-- **調査目的の staging は絶対に行わない。** 調査は読み取り専用コマンドで行う:
-  - 変更ファイル一覧: `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` は例外的に、次の明文化されたフローの中でのみ自動実行してよい**:
-  1. `fullrun new` / `halfrun new` の手順 5（作業ツリーに変更がある状態で `josh latest` を回す前の退避）
+`CLAUDE.md` → "Git Rules" の細則。index には履歴がなく、上書きされたステージ状態は復元できない（`docs/maintainers/operating-rules-rationale.md` → "Why the index is the user's"）。
+
+- **調査目的の staging はしない。** 読み取り専用コマンドを使う: `git status --short`、`git diff` / `git diff --stat` / `git diff HEAD`、`git diff --staged`、未追跡ファイルは `git diff --no-index /dev/null <new-file>` か直接読む
+- staging してよいのは次の 2 ケースだけ。それ以外は実行せずに確認する:
+  1. ユーザーがそのターンで明示的にステージを指示した
+  2. 承認済みのコミットフロー（`pnpm josh git`、`fullrun` / `backlogrun` のコミット手順。`halfrun` は含まない）
+- レーンの中で競合を解決したあとの記録はケース 2（Tier A）。許可を求めず `pnpm josh git -y` で記録する。手順は `.claude/skills/workflow-commands/chain-rule.md` →「origin/main is merged in before the gate」（joshuafolkken/kit#2445）
+- `git reset` / `git checkout -- <path>` / `git restore <path>` など index や作業ツリーを破壊的に書き換える操作も、自分の判断で実行しない
+- **`git stash` を自動実行してよいのは次のフローだけ**。ほかの場面では実行せずに確認する:
+  1. `fullrun new` / `halfrun new` の手順 5（`josh latest` 前の退避）
   2. `backlogrun` のラン開始時の `josh latest`
   3. 「別パッケージ起因の問題は割り込み Issue で対応する」
   4. `backlogrun` が epic の子を始める前の preflight（`pnpm josh run:hold <N>` が `reclaim` と答えたときの回収 — joshuafolkken/kit#926, joshuafolkken/kit#1965）
 
-  **4 番目だけが復元を伴わない。1〜3 はいずれも直後に `pnpm josh stash:pop "<メッセージ>"` で復元することが手順に含まれている**（stash はリポジトリ単位の 1 本のスタックを全 work tree が共有するため、位置指定や引数なしの `git stash pop` は別のレーンが最後に積んだ stash を取り込む — メッセージで対象を特定する。joshuafolkken/kit#2050）。 回収するのは異常終了したランの置き土産であって、いま実行中のランの作業ではないから、pop して戻す先がない。**代わりに stash を子の Issue にコメントで記録する** — 前提 Issue で中断するときの stash（`prerequisite.md`）と同じく、**その記録だけが後で pop させられる唯一の手がかり**であり、記録し忘れた stash は誰にも拾われない。これら以外の場面で退避したくなったときは、実行せずに先に確認する
-
-- **会話で作った実装をランへ渡す「引き渡し用の stash」も `pnpm josh stash:pop "<メッセージ>"` で復元する。当てたあと stash は消える**（経緯は `docs/maintainers/operating-rules-rationale.md` → "Why a handed-over stash is popped"）
-  - **計画には復元手順としてこの 1 行だけを書く。** `git stash apply` / `git stash pop` も「drop しない」という条件も書かない
-  - **計画がガードの拒否する復元形を指していたら、実行側は `stash:pop` に読み替えて続行し、Issue コメントに残す（Tier A）。** `needs-decision` では止まらない
-  - **stash を残すのは持ち主の判断だけである。** 持ち主が計画に理由を書き、ランはそこで止まって確認する
+  1〜3 は直後に `pnpm josh stash:pop "<メッセージ>"` で復元する。stash は全 work tree が共有する 1 本のスタックなので、位置指定や引数なしの `git stash pop` は使わない（joshuafolkken/kit#2050）。4 は復元しない — 代わりに stash を子の Issue にコメントで記録する（`prerequisite.md` の stash と同じく、記録だけが後で pop させる手がかり）
 
-- **staging・index の書き換え・`git commit` の直接実行は deny されており、deny には「そのターンでユーザーが明示指示した」という例外がない。** だから上記ケース 1 は AI 側では実行できず、ユーザー自身の端末で実行してもらう。ユーザーが明示的にコミットを指示した場合も、承認済みのコミットは `pnpm josh git` を通す（理由は `docs/maintainers/operating-rules-rationale.md` → "Why the index is the user's"）
-- index を守る deny と `pnpm josh rule:guard`（`worktree-mutation`・`index-mutation`・`destructive-command`・`protected-file` 行）も事故防止の実装である — 上記「指示されていない行動は取らない」→「deny と配送ガードは実装であって規則ではない」
+- **会話で作った実装をランへ渡す「引き渡し用の stash」も `pnpm josh stash:pop "<メッセージ>"` で復元する。当てたあと stash は消える**（`docs/maintainers/operating-rules-rationale.md` → "Why a handed-over stash is popped"）
+  - 計画には復元手順としてこの 1 行だけを書く。`git stash apply` / `git stash pop` も「drop しない」という条件も書かない
+  - 計画がガードの拒否する復元形を指していたら、実行側は `stash:pop` に読み替えて続行し、Issue コメントに残す（Tier A）。`needs-decision` では止まらない
+  - stash を残すのは持ち主の判断だけ。持ち主が計画に理由を書き、ランはそこで止まって確認する
+- staging・index の書き換え・`git commit` の直接実行は deny されており、deny には「そのターンでユーザーが明示指示した」という例外がない。ケース 1 はユーザー自身の端末で実行してもらう。コミットを指示されたら `pnpm josh git` を通す
+- index を守る deny と `pnpm josh rule:guard`（`worktree-mutation`・`index-mutation`・`destructive-command`・`protected-file` 行）も実装である（→「deny と配送ガードは実装であって規則ではない」）
 
 ### decision-autonomy — 意思決定の自律ポリシー（確認停止を減らす）
 
-3 層の定義（Tier A / B / C）、起票した Issue の epic 所属と自己修正が Tier A であること、自動判断の記録先は `CLAUDE.md` → "Decision autonomy" に常駐している。ここに書くのは、その境界の細則である。
+`CLAUDE.md` → "Decision autonomy" の境界の細則。
 
-- **A と B の判定基準**: 確認するのは「差が僅差 **かつ** 後戻りしにくい／アーキテクチャに長く影響する」ときだけ。「迷っている」だけでは停止理由にならない — 明確に優位な選択肢は多少の不確実性が残っても自動で選び、僅差でも安価に巻き戻せる選択は自動で決めて記録して進む
-- **起票した Issue の所属先は、候補が複数の epic に散っていても Tier B ではない**（joshuafolkken/kit#1339）。`epic --add` 1 回で移せるので推奨する 1 つを選び、採用・却下・理由・決定日を Issue と epic の両方に記録して進む。止まるのは 2 つの epic が本当に甲乙つけがたいときだけである
-- **自己修正**は設計判断ではなく後始末である — 自分が公開した成果物の事実誤り（誤った帰属を含む）の訂正と、同じセッションで自分が特定した自分の作業の抜けの穴埋め（例: 欠けていると自分で指摘した相互リンクの追加）。どちらも可逆で、望ましい結果が 1 つしかなく、問題を迂回せず既に行った作業を修復するだけなので、回避策のリスクはない
-- **「相談と実行を区別する」との境界**: ここでの Tier A は **すでに承認され実行された作業を完了・修復する**ことに限られる。目標の表明（「〜したい」）や進め方への問い（「どうすべき？」）に対して勝手に動いてよい、という意味ではない（→ `principles.md` → "consult-vs-execute"）
-- **Tier C との境界**: 自分のコメントの訂正は Tier A。マージ・ブランチ削除・force push・スコープ外の変更は、**その問題を招いたのが自分自身であっても** Tier C のまま。確認を外しても監査証跡は外さない
-- **major のバージョン bump は Tier C**: `pnpm josh bump major` は自分の判断で実行せず、提案もしない。破壊的な変更に見えても既定は minor / patch で、major はユーザーがそのターンで明示したときだけ（0.x の major は 1.0.0 になり、戻せない公開を伴う）。`josh bump` が版を変えたら、変わった挙動の `docs/` をコミット前に更新する
-- **自動判断の記録の書き方**: Issue 駆動ワークフロー内では `pnpm josh issue:comment <N> --body-file <path>` で、採用案・不採用の代替案・なぜ採用案が明確に優位かを記載する
+- **A と B の判定**: 確認するのは「差が僅差 かつ 後戻りしにくい／アーキテクチャに長く影響する」ときだけ。明確に優位な選択肢は自動で選び、僅差でも安価に巻き戻せる選択は決めて記録して進む
+- 起票した Issue の所属先は、候補が複数の epic に散っていても Tier B ではない（joshuafolkken/kit#1339）。1 つを選び、採用・却下・理由・決定日を Issue と epic の両方に記録する。止まるのは 2 つが本当に甲乙つけがたいときだけ
+- 自己修正（自分が公開した成果物の事実誤りの訂正、同じセッションで自分が特定した自分の作業の抜けの穴埋め）は Tier A。承認済みの作業の完了・修復に限り、目標の表明や問いで動いてよい意味ではない（→ `principles.md` → "consult-vs-execute"）
+- **Tier C との境界**: マージ・ブランチ削除・force push・スコープ外の変更は、自分が招いた問題でも Tier C。確認を外しても監査証跡は外さない
+- **major のバージョン bump は Tier C**: `pnpm josh bump major` は自分の判断で実行も提案もしない。既定は minor / patch で、major はユーザーがそのターンで明示したときだけ（0.x の major は 1.0.0 になり戻せない）。`josh bump` が版を変えたら、変わった挙動の `docs/` をコミット前に更新する
+- 自動判断の記録: Issue 駆動ワークフロー内では `pnpm josh issue:comment <N> --body-file <path>` で、採用案・不採用の代替案・採用案が優位な理由を書く

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

@@ -1,6 +1,6 @@
 # コマンド出力が文脈へ持ち込む量の上限（joshuafolkken/kit#1173）
 
-**上限は機構で決まり、実行側の判断には委ねられない。** 配布される `.claude/settings.json` の `env` ブロックが `BASH_MAX_OUTPUT_LENGTH` を宣言し、Claude Code は Bash ツールの出力がこの文字数を超えると真ん中を省略して渡す。
+配布される `.claude/settings.json` の `env` ブロックが `BASH_MAX_OUTPUT_LENGTH` を宣言し、Bash ツールの出力がこの文字数を超えると真ん中が省略される。
 
 ```json
 "env": {
@@ -8,34 +8,34 @@
 }
 ```
 
-**8,000 文字**（harness の既定は 30,000、受け付ける最大は 150,000）。値の根拠となった分布と却下した案は `docs/maintainers/output-bounds-rationale.md` → "Why 8,000"。上限は **Bash ツールにだけ効き**、`Read` と `Agent` の結果には効かない。
+**8,000 文字**（harness の既定は 30,000、最大は 150,000。根拠は `docs/maintainers/output-bounds-rationale.md` → "Why 8,000"）。効くのは Bash ツールだけで、`Read` と `Agent` の結果には効かない。
 
 ## 切り詰められたときにどうするか
 
-**情報を落とすのではなく、必要な範囲に合わせて読み直す。** 同じコマンドを再実行しても上限は同じなので、絞り込んで読む:
+**情報を落とすのではなく、必要な範囲に合わせて読み直す。** 再実行ではなく絞り込む:
 
-- ファイルなら範囲を指定する（`sed -n '120,180p' <file>`）か、`Read` ツールの `offset` / `limit` を使う
-- 一覧なら件数を絞る（`--limit`、`| head -30`）、JSON なら必要な項目だけ取り出す（`gh api … --jq '…'`）
-- どうしても全量が要るときは、いったんファイルへ落として（`> <file>`）から範囲を読む
+- ファイルは範囲を指定する（`sed -n '120,180p' <file>`、または `Read` の `offset` / `limit`）
+- 一覧は件数を絞る（`--limit`、`| head -30`）、JSON は必要な項目だけ取り出す（`gh api … --jq '…'`）
+- 全量が要るときは、ファイルへ落として（`> <file>`）から範囲を読む
 
 ## 切り詰められた出力を、完全な出力として読まない
 
-**検証ゲートと差分は、切り詰められた結果で判断しない。** 省略された箇所には harness がマーカーを残す — それは「短い出力」ではなく「一部しか読んでいない出力」である。
+**検証ゲートと差分は、切り詰められた結果で判断しない。**
 
-- **`pnpm josh gate`** は合否の 1 行を末尾に出すので判定は失われない。失敗の内訳が切れたら、合否行の直前に出る **`full output: <path>` のファイルを読む**（joshuafolkken/kit#1227）
-- **差分には判定行が無い。** 欠けた差分で「指摘なし」とするのはゲートを弱めたのと同じなので、**差分はファイルへ落としてから範囲で読む**（`git diff main...HEAD > /tmp/diff.patch && wc -l /tmp/diff.patch`）
+- `pnpm josh gate` は合否の 1 行を末尾に出す。失敗の内訳が切れたら、合否行の直前の `full output: <path>` のファイルを読む（joshuafolkken/kit#1227）
+- 差分には判定行が無い。差分はファイルへ落としてから範囲で読む（`git diff main...HEAD > /tmp/diff.patch && wc -l /tmp/diff.patch`）
 
 ## 検証コマンドをパイプに繋がない（joshuafolkken/kit#1556）
 
-**パイプラインの終了コードは最後のコマンドのものである。** `pnpm josh gate 2>&1 | tail -40` は `tail` の終了コードで終わるので、**赤いゲートがシェルの上では成功として返る。** **これは `josh gate` の欠陥ではない。** POSIX どおりの挙動であり、直すべきは呼び出し方である。
+**パイプラインの終了コードは最後のコマンドのものである。** `pnpm josh gate 2>&1 | tail -40` は赤いゲートを成功として返す。**これは `josh gate` の欠陥ではない。** 直すのは呼び出し方である。
 
-- **既定はパイプなしで実行する。** 判定行は末尾に出るので、上限で真ん中が省略されても残る
-- 絞るなら、ファイルへ落として範囲で読む（`pnpm josh gate > /tmp/gate.log 2>&1; tail -40 /tmp/gate.log`）。リダイレクトは終了コードを奪わない
+- **既定はパイプなしで実行する。** 判定行は末尾に出るので、省略されても残る
+- 絞るなら、ファイルへ落として範囲で読む（`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` は対象外であり、意図的にそうしている。** `latest:scope` ／ `review:brief` も、判定ではなく答えを印字するので `$(...)` で受けてよい。`pnpm josh pretool:guard` は検証コマンドをパイプした `Bash` を、行が検証と後段の `tail` ／全行読みの `grep` だけなら `pipefail` 前置に書き換え、他は拒否する（`rule-delivery.md`）。経緯・却下した案・検査は `docs/maintainers/output-bounds-rationale.md` → "Why the pipe rule is delivered by a trigger"。
+対象は結果が合否を意味するコマンドだけ — `gate` ／ `check` ／ `lint*` ／ `cspell*` ／ `test*` ／ `eval`。**`git log | head` や `gh issue list | head` は対象外であり、意図的にそうしている。** `latest:scope` ／ `review:brief` も、判定ではなく答えを印字するので `$(...)` で受けてよい。`pnpm josh pretool:guard` は、後段が `tail` ／全行読みの `grep` だけの検証パイプラインを `(set -o pipefail; …)` で包み、他のパイプは拒否する（`rule-delivery.md`、`docs/maintainers/output-bounds-rationale.md` → "Why the pipe rule is delivered by a trigger"）。
 
 ## 検査
 
-`scripts/lib/bash-output-cap.test.ts` が、配布設定の上限がこの文書の値と一致し、harness の既定より小さく最大を超えないことを固定する（`docs/maintainers/output-bounds-rationale.md` → "What the tests pin"）。
+`scripts/lib/bash-output-cap.test.ts` が、配布設定の上限がこの文書の値と一致し、既定より小さく最大を超えないことを固定する（`docs/maintainers/output-bounds-rationale.md` → "What the tests pin"）。

package/prompts/collaboration-workflow/overview.md

@@ -8,34 +8,29 @@
 
 ### フェーズ分離
 
-ワークフローは 2 つのフェーズに分けて実行できる。
+- Planning phase（`kickoff`）: Step 1〜3 — Issue 作成・計画投稿・Telegram 通知で止まる。実装前にレビューや承認を挟むときに使う。
+- Execution phase（`fullrun #N`）: Step 4〜5 — 既存 Issue の計画に基づいて実装・PR 作成・完了通知を行う。
 
-- **Planning phase（`kickoff`）**: Step 1〜3 — Issue 作成・計画投稿・Telegram 通知で止まる。実装前にレビューや承認を挟みたい場合に使う。
-- **Execution phase（`fullrun #N`）**: Step 4〜5 — 既存 Issue の計画に基づいて実装・PR 作成・完了通知を行う。
-
-一括実行する場合は `fullrun new` で Step 1〜5 を通しで実行する。
+`fullrun new` は Step 1〜5 を通しで実行する。
 
 ### 出力の言語（`JOSH_SESSION_LANG`）
 
-ワークフローの出力言語は、環境変数 `JOSH_SESSION_LANG`（例: `ja` / `en`）で決まる。対象は「開発者との対話」と「成果物の散文」の**両方**であり、**変数が未設定・空・`.env` なしのときはどちらも `ja` を既定とする**。英語で書くなら `JOSH_SESSION_LANG=en` を設定する。
+開発者との対話と成果物の散文は、環境変数 `JOSH_SESSION_LANG`（例: `ja` / `en`）の言語で書く。**未設定・空・`.env` なしのときは `ja`**。
 
-- **対話は `JOSH_SESSION_LANG` に従う**: セッション中の説明・質問、および `halfrun` などで提示する **`AskUserQuestion` の選択肢ラベル・説明**。
-- **成果物の散文も `JOSH_SESSION_LANG` に従う**: Issue 本文、Issue／PR コメント（Step 3 の計画コメント、`pnpm josh followup` が自動投稿する完了コメントを含む）、Telegram 通知の本文（`--body` / `--notify-message`）。
+- 対話: セッション中の説明・質問、`AskUserQuestion` の選択肢ラベル・説明
+- 成果物の散文: Issue 本文、Issue／PR コメント（Step 3 の計画コメント、`pnpm josh followup` の完了コメントを含む）、Telegram 通知の本文（`--body` / `--notify-message`）
 - **設定に関わらず英語で固定するもの**（3 つ）:
-  1. **Issue／PR タイトル**: Step 1 のタイトル正規化ルールは変更しない。
-  2. **コード内コメント、テストタイトル（`describe` / `it` / `expect`）、コミットメッセージ**。
-  3. **スクリプトが出力する固定文字列**: Telegram のヘッダーラベル（`Planning` / `Completion` など）、`Issue:` / `PR:` の URL ラベル、`--notify-message` 省略時の既定メッセージ。
+  1. Issue／PR タイトル（Step 1 のタイトル正規化ルール）
+  2. コード内コメント、テストタイトル（`describe` / `it` / `expect`）、コミットメッセージ
+  3. スクリプトが出力する固定文字列: Telegram のヘッダーラベル（`Planning` / `Completion` など）、`Issue:` / `PR:` の URL ラベル、`--notify-message` 省略時の既定メッセージ
 
-`JOSH_SESSION_LANG` は **開発者個人の設定**であり、`.env`（gitignore 済み・非コミット）に置く。**設定値は毎ターン `UserPromptSubmit` フック（`scripts/hooks/run-hook.sh session-lang`）が差し込み、未設定なら出さない。** Codex も `.codex/hooks.json` で同じフックを実行する。フックが走らないハーネス（Gemini / Cursor）は `.env` を読む。各既定の理由は `docs/maintainers/overview-rationale.md` → "Why the session language defaults the way it does" にある。
+`JOSH_SESSION_LANG` は開発者個人の設定で、`.env`（gitignore 済み）に置く。設定値は毎ターン `UserPromptSubmit` フック（`scripts/hooks/run-hook.sh session-lang`、Codex は `.codex/hooks.json`）が差し込み、未設定なら出さない。フックが走らないハーネス（Gemini / Cursor）は `.env` を読む。既定の理由は `docs/maintainers/overview-rationale.md` → "Why the session language defaults the way it does"。
 
 ### 配布ドキュメントの層ごとの言語（joshuafolkken/kit#2997）
 
-ドキュメントは**層ごとに 1 つの言語**で書き、1 つの層の中で言語を混ぜない。`JOSH_SESSION_LANG` はこれを変えない。
+ドキュメントは**層ごとに 1 つの言語**で書き、層の中で言語を混ぜない（`JOSH_SESSION_LANG` に依らない）。
 
-| 層                                                                                      | 言語   |
-| --------------------------------------------------------------------------------------- | ------ |
-| `CLAUDE.md`、`AGENTS.md` / `GEMINI.md`、スキル（`.claude/skills/`）、フックが差し込む文 | 英語   |
-| `prompts/` のトピックファイル（次の行の 3 文書を除く）                                  | 日本語 |
-| `prompts/review.md`、`prompts/review-rubric.md`、`prompts/sonar-hotspot-handling.md`    | 英語   |
+- 英語: `CLAUDE.md`、`AGENTS.md` / `GEMINI.md`、スキル（`.claude/skills/`）、フックが差し込む文、`prompts/review.md`、`prompts/review-rubric.md`、`prompts/sonar-hotspot-handling.md`
+- 日本語: それ以外の `prompts/` のトピックファイル
 
-英語の層から日本語のトピックファイルの節を指すポインターは、見出しの先頭に置いた**英語 ID** を引く（例: 見出し `## no-clones — クローン禁止・…` を `principles.md` → "no-clones" で指す）。`pnpm josh doc:section` は見出しの前方一致で節を引くので、ID だけで解決し、`JOSH_SESSION_LANG=en` の利用者や日本語を読まないエージェントにも参照先が読める。ID の無い日本語見出しは原文のまま引く。
+英語の層から日本語のトピックファイルの節を指すときは、見出しの先頭の**英語 ID** を引く（例: `## no-clones — クローン禁止・…` を `principles.md` → "no-clones"。`pnpm josh doc:section` は前方一致で解決する）。ID の無い日本語見出しは原文のまま引く。

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

@@ -1,8 +1,8 @@
 ## Step 3: 計画コメントを記録して通知する
 
 1. 提案を人間が判断する
-2. 採用した計画を Issue に記録する（Issue body が空の場合は計画をファイルに書き、`gh api -X PATCH repos/{owner}/{repo}/issues/<N> --field body=@<path>` で body に書き込む — 本文はパスで渡し、シェルの二重引用符には載せない（`shell-body.md`）。body が既にある場合は `pnpm josh issue:comment <N> --body-file <path>` でコメント追加する）
-   - **計画が stash の復元を含むとき（会話で先に作った実装を stash でランへ渡す場合を含む）、復元手順には `pnpm josh stash:pop "<メッセージ>"` だけを書く。** `git stash apply` / `git stash pop` と「drop しない」という条件は書かない — 単一ソースは `operating-rules.md` → "no-self-staging"
+2. 採用した計画を Issue に記録する。body が空なら計画をファイルに書き `gh api -X PATCH repos/{owner}/{repo}/issues/<N> --field body=@<path>` で書き込む（本文はパスで渡す — `shell-body.md`）。body があれば `pnpm josh issue:comment <N> --body-file <path>` でコメントする
+   - 計画が stash の復元を含むときの書き方: `operating-rules.md` → "no-self-staging"
 3. Telegram で計画開始を通知する:
 
    ```bash
@@ -10,12 +10,12 @@
    ```
 
    - `--task-type` はヘッダーのアイコンを決める（`planning` 📋 / `completion` ✅ / `failure` ❌ / `warning` ⚠️ / `kickoff_retry` 🔄 / `confirmation` ⏸️）
-   - `warning` は **`pnpm josh followup` が自分で送る種別** であり、手で打つものではない（joshuafolkken/kit#1628）
+   - `warning` は `pnpm josh followup` が自分で送る種別で、手で打たない（joshuafolkken/kit#1628）
    - `--repo-name` と `--issue-title` は未指定なら `gh` から自動取得される
    - Issue URL を必ず含め、箇条書きの間に改行を入れる
-   - `kickoff` コマンドの場合はここで **停止** する（実装に進まない）
+   - `kickoff` はここで**停止**する（実装に進まない）
 
-4. ワークフロー開始時点で作業ツリーにステージング済みまたは変更済みのファイルが既にある場合、先に変更を退避する:
+4. 作業ツリーに変更（ステージ済みを含む）が既にあれば退避する:
    ```bash
    git stash push -u -m "plan: pre-existing changes"
    ```
@@ -23,16 +23,16 @@
    ```bash
    pnpm josh ms
    ```
-6. 依存関係の更新はコマンドに問う — `pnpm josh latest:scope` が `required` と答えたときだけ `pnpm josh latest` を実行し、`dependency-update` スキルに従う（単一ソースは `.claude/skills/workflow-commands/latest-gate.md`）。脆弱性への override は `pnpm-workspace.yaml` の `overrides` に書く（pnpm 11/12 は `package.json` の `pnpm.overrides` を無視する）。
-   ステップ 4 で stash した場合は、ここでメッセージ指定で復元する（stash は全 work tree が共有するため、位置指定や引数なしの `git stash pop` は使わない — joshuafolkken/kit#2050）:
+6. `pnpm josh latest:scope` が `required` と答えたときだけ `pnpm josh latest` を実行し、`dependency-update` スキルに従う（`.claude/skills/workflow-commands/latest-gate.md`）。脆弱性への override は `pnpm-workspace.yaml` の `overrides` に書く（pnpm 11/12 は `package.json` の `pnpm.overrides` を無視する）。
+   ステップ 4 で stash したら、ここでメッセージ指定で復元する（位置指定や引数なしの `git stash pop` は使わない — joshuafolkken/kit#2050）:
    ```bash
    pnpm josh stash:pop "plan: pre-existing changes"
    ```
-7. **作業サマリを提示してから**実装を開始する（`CLAUDE.md` の Code Change Rules Step 0）。書式は `report-format.md` に従う。`fullrun` / `halfrun` / `backlogrun` では Issue ごとに 1 回、Issue body が既に埋まっていても必ず提示する（`kickoff` は計画を Issue に投稿するので対象外）。提示は説明のためであり、**確認待ちで停止しない** — 同一ターンでそのまま実装へ進み、Issue コメントとしては投稿しない。
-8. 実装完了後、**lint/test より前に** `prompts/refactoring.md` に従ってリファクタリングを適用する（高・中優先度項目が残らなくなるまで収束させる）
+7. **作業サマリを提示してから**実装を開始する（`report-format.md` → "作業前サマリはいつ・どう出すか"）。Issue body が埋まっていても提示し、Issue コメントとしては投稿しない。
+8. 実装完了後、lint/test より前に `prompts/refactoring.md` に従い、高・中優先度項目が残らなくなるまでリファクタリングする
 9. 検証ゲート（`CLAUDE.md` の Completion gate）を実行する
 
-`pnpm josh git` の基本実行（`-y` で確認プロンプトをスキップ）。**子はバージョンを上げない** — 版を決めるのは `pnpm josh release` ただ 1 箇所である（joshuafolkken/kit#1486）。Issue タイトルは実行前に整える（規則は `issue-template.md` の Step 1 冒頭）。
+`pnpm josh git` を実行する（`-y` で確認プロンプトをスキップ）。**子はバージョンを上げない** — 版を決めるのは `pnpm josh release` だけ（joshuafolkken/kit#1486）。Issue タイトルは実行前に `issue-template.md` の Step 1 冒頭に沿って整える。
 
 ```bash
 pnpm josh git -y "<issue-title> #<issue-number>"
@@ -40,7 +40,7 @@ pnpm josh git -y "<issue-title> #<issue-number>"
 
 ### Recovery after failed push (pre-push hook blocked)
 
-If `pnpm josh git -y` fails at the push step (e.g. blocked by the pre-push hook), fix the blocking issue and then recover with:
+If `pnpm josh git -y` fails at the push step, fix the blocking issue and recover with:
 
 ```bash
 # 1. Push manually after fixing the issue
@@ -51,8 +51,8 @@ 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.
+Do not run `gh pr create` directly — it bypasses `build_body`, which writes `closes #N`.
 
 ### レビューからマージまで
 
-レビューは実装したセッションが**コミットの前に** `pnpm josh review:brief` で始め、`/code-review` は `Agent` ツールのサブエージェントが実行する。ゲートとの重ね方、2 周の上限と 2 周目の検証パス、2 周の間で PR を開く位置、残った指摘の振り分けと `pnpm josh epic:bundle`、マージを打つターンは、すべて `.claude/skills/workflow-commands/chain-rule.md` が単一ソースである — "Run the review-to-merge chain"、"The review runs in a subagent, never a main-line skill load"、方針は `prompts/review.md` → "Review round cap"。**`/code-review` の出力で停止しない。**
+レビューは実装したセッションがコミットの前に `pnpm josh review:brief` で始め、`/code-review` は `Agent` ツールのサブエージェントが実行する。周回の上限、残った指摘の振り分けと `pnpm josh epic:bundle`、マージを打つターンは `.claude/skills/workflow-commands/chain-rule.md` → "Run the review-to-merge chain"、"The review runs in a subagent, never a main-line skill load"、方針は `prompts/review.md` → "Review round cap"。**`/code-review` の出力で停止しない。**