@joshuafolkken/kit 1.1453.0 → 1.1471.0

package/prompts/collaboration-workflow/file-edits.md

@@ -1,12 +1,12 @@
 ## ファイル編集はコマンド本文に本文を載せない
 
-「ファイル本文をシェルに載せない」規則の正典。`CLAUDE.md` からは [`rule-delivery.md`](./rule-delivery.md) →「配送されている規則」を経て届く。
+`CLAUDE.md` からは [`rule-delivery.md`](./rule-delivery.md) →「配送されている規則」を経て届く。
 
-`pnpm josh rule:guard`（file-body の行）が、既存ファイルを書き戻すヒアドキュメント・書き込みを伴うインタプリタ heredoc / `node -e`・書き込むスクリプトファイルを作るヒアドキュメント・in-place `perl -0pi -e` を、コマンドの何行目にあってもその呼び出しで拒否し、規則を述べる。**このファイルが担うのはガードに見えないもの**である — Bash を通らない Edit / Write の全文書き直し、ガードを素通りする `sed -i` の 4 条件、そしてコストである。
+`pnpm josh rule:guard`（file-body の行）が、既存ファイルを書き戻すヒアドキュメント・書き込むインタプリタ heredoc / `node -e`・書き込むスクリプトを作るヒアドキュメント・`perl -0pi -e` を拒否する。ガードに見えない Edit / Write の全文書き直しと `sed -i` は以下に従う。
 
 ### 何を禁じているか
 
-**編集後のテキストを丸ごとコマンド行に載せる形を禁じる。** 典型は、インタプリタを起動して領域を書き戻す次の形である。
+**編集後のテキストを丸ごとコマンド行に載せる形を禁じる。** 典型（`NEW_REGION` には置換後の本文が載る）:
 
 ```bash
 python3 - <<'PY'          # ← 禁止
@@ -15,64 +15,46 @@ open('CLAUDE.md', 'w').write(text.replace(OLD_REGION, NEW_REGION))
 PY
 ```
 
-`NEW_REGION` は変数ではない。実際には**置換後の本文そのもの**がここに直接書かれ、コマンド行に載る。それがコストの正体である。
-
-領域を指定して書き換える編集は **Edit ツール**（old / new の差分）で行う。`node -e`、`cat > file <<'EOF'`、`tee file <<'EOF'`、`perl -0pi -e` に長い置換文字列を渡す形も同じ理由で禁止される。
+領域を書き換える編集は Edit ツール（old / new の差分）で行う。`node -e`、`cat > file <<'EOF'`、`tee file <<'EOF'`、`perl -0pi -e` に長い置換文字列を渡す形も禁止。
 
 ### 判断基準は「本文を丸ごと運ぶか」であり、ツール名ではない
 
-禁止の対象は**ツールの種類ではない**。判断は 1 問で決まる。
-
 > **そのコマンドは、置換後のテキストを丸ごとコマンド本文に載せているか。**
 
 - yes → 禁止。Edit を使う
-- no → 許可
-
-したがって短い置換に `sed -i` を使うのは**許される**。パターンと置換語しか運ばないので、Edit の `old_string` / `new_string` より本文が小さい。逆に「Edit を使ったから安全」も成り立たない — 300 行のファイルを全文 `new_string` に入れれば、禁じている形と同じコストになる。次節はその後半を条件として書き下したものである。
+- no → 許可（短い置換の `sed -i` は下の 4 条件つきで可）
 
 ### 編集は指摘された箇所だけを対象にする（全文書き直しの条件）
 
-**既定は部分編集である。** 直す行が決まっているなら、`old_string` / `new_string` はその行の周辺までに狭める。数か所を直せば済むファイルを全文書き直しで出力する形は、`python3` の heredoc と同じコストを、ツールを替えただけで払っている。
-
-**ファイルを全文書いてよいのは、ファイルそのものを置き換える意図があるときだけである。** 該当するのは次の 3 つで、それ以外は部分編集にする。
-
-- **新規ファイルの作成** — 既存本文が無いので、運ぶ重複がそもそも発生しない
-- **ファイル全体の作り直し** — 構成の組み替えや生成物の再生成で、変更後の本文が元の本文とほとんど共有しない場合
-- **部分編集のほうが大きくなる場合** — 変更箇所がファイル全域に散っていて、`old_string` / `new_string` の合計が全文を超えるとき。このときも全文は **Write ツール**で書く — ヒアドキュメントやインタプリタで書き戻す形は、この例外でもガードに拒否される
+**既定は部分編集である。** `old_string` / `new_string` は直す行の周辺までに狭める — Edit / Write の全文書き直しは禁じている形と同じコストを払う。全文を書いてよいのは次の 3 つだけ:
 
-**レビュー指摘の修正がこの規則の主戦場である。** 「この行の条件が逆」「この定数を切り出す」といった局所的な指摘ほど、部分編集は小さくなる。一方で全文書き直しのコストはファイルの大きさで決まり、指摘の小ささでは下がらない。**指摘が局所的であるほど、全文書き直しとの差は開く。**
+- 新規ファイルの作成
+- ファイル全体の作り直し — 変更後の本文が元とほとんど共有しない場合
+- 部分編集のほうが大きくなる場合 — `old_string` / `new_string` の合計が全文を超えるとき（このときも Write で書く）
 
-実測では 1 ランで約 2 分 45 秒が、すでに存在する行を打ち直すことに使われていた（joshuafolkken/kit#1260）。内訳は `docs/maintainers/file-edits-rationale.md` → "Measured cost of whole-file rewrites"。
+実測は `docs/maintainers/file-edits-rationale.md` → "Measured cost of whole-file rewrites"（joshuafolkken/kit#1260）。
 
 ### `sed -i` を使う前に満たす 4 条件
 
-`sed` が安いのは事実だが、Edit と違って**一致した全行**を書き換え、**一致が 0 件でも黙って成功する**。Edit の一意性検査に相当するものが無いので、使う前に次を満たす。
+`sed` は一致した全行を書き換え、一致 0 件でも黙って成功する。使う前に次を満たす。
 
-1. **出現回数を先に数える** — `grep -o '<pattern>' <file> | wc -l` が `1` であること。**`grep -c` を使ってはならない** — 数えるのは一致した「行数」であって出現回数ではないので、同じ行に 2 回出る場合も `1` を返す。`s///` は 1 行につき 1 回しか置換しないため、そこを一意と読むと**半分だけ書き換わったファイル**が黙って残る。`0` なら何も起きないまま成功して返る
-2. **メタ文字を持ち込まない — パターン側と置換語側の両方** — 区切りの `/`、`&`、`\`、正規表現の `.` `*` `[` `]` `^` `$` のいずれかがどちらかに入るなら Edit を使う。散文が対象のこの repository では `/` とバッククォートが頻出し、**危ないのはむしろパターン側**である（`s/prompts\/…/…/` はエスケープを 1 つ落とすだけで `unterminated 's' command`、`.` は書き手が意図していない箇所に静かに一致する）
-3. **`-i` の引数はプラットフォームで違う** — BSD / macOS は `sed -i '' 's/…/…/' file`、GNU / Linux は `sed -i 's/…/…/' file`。片方の形を他方で走らせると、エラーになるか `''` という名前のバックアップファイルが残る。**配布ドキュメントに手順として書くときは必ずこの差を明示する** — kit の成果物は両方のプラットフォームの consumer に届く
-4. **編集後に自分で整形する** — `.claude/settings.json` の `PostToolUse` フックは `Bash` にも一致する（joshuafolkken/kit#1337）が、渡されるペイロードにはコマンドしか入らずファイルパスが無いため、Bash 経由の編集では整形は走らない。`sed` で表の行や折り返しのある段落に触れたら、続けて `pnpm josh format` を走らせる。**`format:edited` は手で呼べない** — フックが渡す JSON を stdin から読んで `tool_input.file_path` を取り出す設計で、引数にパスを取らないからである。放置すると `pnpm josh lint`（`prettier --check .`）が後から落ちる
+1. **出現回数を先に数える** — `grep -o '<pattern>' <file> | wc -l` が `1` であること。`grep -c` は行数を数えるので使わない
+2. **メタ文字を持ち込まない — パターン側と置換語側の両方** — `/`、`&`、`\`、`.` `*` `[` `]` `^` `$` のいずれかが入るなら Edit を使う
+3. **`-i` の引数はプラットフォームで違う** — BSD / macOS は `sed -i '' 's/…/…/' file`、GNU / Linux は `sed -i 's/…/…/' file`。配布ドキュメントに書くときはこの差を明示する
+4. **編集後に自分で整形する** — Bash 経由の編集では `PostToolUse` の整形が走らない（joshuafolkken/kit#1337）ので `pnpm josh format` を走らせる（`format:edited` は手で呼べない）
 
-**4 条件のどれかが面倒に見えたら、そこが Edit を使う場所である。** `sed` はコストを下げるための例外であって、既定の編集手段ではない。
+**4 条件のどれかが面倒に見えたら、そこが Edit を使う場所である。**
 
-| 形                                                 | 可否         | 理由                                                      |
-| -------------------------------------------------- | ------------ | --------------------------------------------------------- |
-| Edit（数行の old / new）                           | 可           | 差分だけが本文に載る                                      |
-| `sed -i` の短い置換                                | 条件付きで可 | パターンと置換語しか載らない。上の 4 条件を満たすこと     |
-| `python3 - <<'PY'` で領域を書き戻す                | 不可         | 置換後の本文が丸ごと載る                                  |
-| `cat > file <<'EOF'` で既存ファイルを書き直す      | 不可         | 同上                                                      |
-| `cat > new-file <<'EOF'` で新規ファイルを作る      | 可           | 既存本文を運んでいない。ただし長文なら Write のほうが安い |
-| `cat > edit.py <<'EOF'` で書き込むスクリプトを作る | 不可         | 実行を 1 呼び出し後ろにずらしただけで、置換後の本文が載る |
-| 読み取り・検索（`cat` / `sed -n` / `grep`）        | 可           | 本文を運ばない                                            |
+| 形                                               | 可否                |
+| ------------------------------------------------ | ------------------- |
+| Edit（数行の old / new）                         | 可                  |
+| `sed -i` の短い置換                              | 上の 4 条件つきで可 |
+| `python3 - <<'PY'` で書き戻す                    | 不可                |
+| `cat > file <<'EOF'`（既存ファイル）             | 不可                |
+| `cat > new-file <<'EOF'`（新規、長文なら Write） | 可                  |
+| `cat > edit.py <<'EOF'`（書き込むスクリプト）    | 不可                |
+| 読み取り（`cat` / `sed -n` / `grep`）            | 可                  |
 
 ### なぜコストが二重になるか
 
-インタプリタで書き戻す形は、編集後の本文が**コマンド本文とファイルの両方**に載る。さらに悪いのは持続性である。**コマンド本文は、書いた時点以降のすべてのリクエストで読み直される。** ランの序盤に書いた編集スクリプトほど、そのランの残り全リクエストぶん課金され続ける。ファイル側は次に読んだときだけ載るのに対し、コマンド側は消えない。実測の内訳は `docs/maintainers/file-edits-rationale.md` → "Measured breakdown of command text"。
-
-### なぜ resident に置くか
-
-根拠は `docs/maintainers/file-edits-rationale.md` → "Why it is resident"。
-
-### マーカーテスト
-
-固定している内容は `docs/maintainers/file-edits-rationale.md` → "Marker tests"。
+書き戻す形は本文がコマンドとファイルの両方に載り、コマンドは以降の全リクエストで読み直される。内訳は `docs/maintainers/file-edits-rationale.md` → "Measured breakdown of command text"、常駐の根拠は `docs/maintainers/file-edits-rationale.md` → "Why it is resident"、固定内容は `docs/maintainers/file-edits-rationale.md` → "Marker tests"。

package/prompts/collaboration-workflow/gh-rest.md

@@ -2,54 +2,38 @@
 
 ## 規則
 
-**GitHub への操作は `gh api`（REST）で書く。`gh issue …` / `gh pr …` / `gh repo …` といったサブコマンド
-形は使わない。** クラウドセッション（エージェントのコンテナ）では GitHub の GraphQL エンドポイントへの
-egress が `403` で拒否されるため、GraphQL を経由するサブコマンドはそこで一切動かない。
+**GitHub への操作は `gh api`（REST）で書く。** `gh issue …` / `gh pr …` / `gh repo …` のサブコマンド形は使わない —
+クラウドセッションでは GraphQL への egress が `403` で拒否される。
 
-例外は 2 つだけである。
+例外は 2 つだけ:
 
-- **`gh auth token`** — ローカルの CLI が既に持っている認証情報を返すだけで、どのエンドポイントにも
-  接続しない。REST で書き換えられる呼び出しが存在しない。読み出すのはローカルの認証情報だけである。
-- **GitHub Actions のワークフロー** — ランナー上では `gh` が通常どおり動き、`gh pr merge --auto` が使う
-  API は GraphQL にしか存在しない。
+- `gh auth token` — ローカルの認証情報を返すだけで、どのエンドポイントにも接続しない
+- GitHub Actions のワークフロー — ランナー上では `gh` が動き、`gh pr merge --auto` の API は GraphQL にしか無い
 
 ## 認証は環境によって別物である
 
-**手元では `gh auth login` を一度実行すれば足り、`GH_TOKEN` は要らない。** 認証情報は OS のキーチェーンに
-入り、`gh auth status` が読めるのはそれである。
-
-**CI とクラウドセッションにはそのキーチェーンが無いので、`GH_TOKEN` を設定する。** どちらか一方しか書かない
-説明は、もう一方の環境で誤った案内になる —— 手元で `gh auth login` 済みの機械に `GH_TOKEN` を設定させたり、
-クラウドで存在しないキーチェーンを探させたりする。
+**手元では `gh auth login` を一度実行すれば足り、`GH_TOKEN` は要らない**（認証情報は OS のキーチェーン）。
+**CI とクラウドセッションにはキーチェーンが無いので、`GH_TOKEN` を設定する。** 説明を書くときは両方を書く。
 
 ## 散文でも「指示の形」なら REST で書く
 
-**この規則はフェンス付きコードブロックの中だけの話ではない。文書の散文に書かれたコマンドでも、読み手に
-実行を指示する形であれば REST で書く。**
+**文書の散文に書いたコマンドでも、読み手に実行を指示する形なら REST で書く。**
 
-- **指示の形**（REST で書く）— 「数えるのはコマンド 1 つで済む: `…`」「各子 Issue に `…` でコメントを
-  書く」のように、読み手がそのまま打つことを期待している書き方。
-- **引用の形**（そのままでよい）— 「`gh issue create` は使わない」のような禁止の引用や、「このサブコマンドは
-  GraphQL を経由する」のような CLI の対応状況の記録。書き換えると、何を禁じているのかが読めなくなる。
+- 指示の形（REST で書く）— 「数えるのはコマンド 1 つで済む: `…`」「各子 Issue に `…` でコメントを書く」のように、
+  読み手がそのまま打つ書き方
+- 引用の形（そのままでよい）— 「`gh issue create` は使わない」のような禁止の引用や、CLI の対応状況の記録
 
-**この区別は機械には引けない** — 文書ガードはフェンス付きコードブロックだけを走査するので、散文の側は
-書き手がこの区別で守る（`docs/maintainers/gh-rest-rationale.md` → "Why the document guard scans fences only"）。
+文書ガードはフェンス付きコードブロックだけを走査するので、散文は書き手がこの区別で守る
+（`docs/maintainers/gh-rest-rationale.md` → "Why the document guard scans fences only"）。
 
-**書き換えるときは `pnpm josh` のコマンドで置き換えられないかを先に見る。** 例えば Issue の状態を読むのは
-`gh issue view` ではなく `pnpm josh issue:state <N>` で、これはラベルと `human_review` まで一度に返す。
+書き換えるときは先に `pnpm josh` のコマンドで置き換えられないかを見る（例: `gh issue view` ではなく
+`pnpm josh issue:state <N>`）。
 
 ## REST 化は `gh` を不要にしない
 
-**すべての REST 呼び出しは今も `execa('gh', ['api', …])` である。** サブコマンドをやめたことで消えたのは
-GraphQL への依存であって、バイナリへの依存ではない。**`gh` が入っていないコンテナは実在する** — その環境
-では `pnpm josh epic:next` も `pnpm josh pr` も `pnpm josh followup` も完了できず、`fullrun`
-は GitHub に一切到達しない。`git push` が通り `GH_TOKEN` が効いていても、である。
-
-`check_gh_installed` は `gh CLI is not installed` と明示するが、git remote からリポジトリを読む側の
-コマンド（`epic:next` / `epic:bundle` / `issue:scout` / `epic --add`）は「Could not read this
-repository from `git remote`, so the children cannot be keyed by repository — check `gh auth status`
-and that this is a checkout with an `origin` remote.」と出るため、原因が `gh` の不在であることが読み取り
-にくい。**そのメッセージを見たら、まず `gh` の有無を確かめる。**
+REST 呼び出しも `execa('gh', ['api', …])` なので、`gh` が無いコンテナでは `pnpm josh epic:next` /
+`pnpm josh pr` / `pnpm josh followup` も完了しない。`epic:next` / `epic:bundle` / `issue:scout` / `epic --add` が
+「Could not read this repository from `git remote`, so the children cannot be keyed by repository — check
+`gh auth status` and that this is a checkout with an `origin` remote.」と出したら、**まず `gh` の有無を確かめる。**
 
-環境ごとの前提と、開けるべきホストの一覧は
-[`docs/cloud-session.md`](https://github.com/joshuafolkken/kit/blob/main/docs/cloud-session.md) にある。
+環境ごとの前提とホストは [`docs/cloud-session.md`](https://github.com/joshuafolkken/kit/blob/main/docs/cloud-session.md)。

package/prompts/collaboration-workflow/glossary.md

@@ -1,17 +1,15 @@
 # ワークフロー用語集
 
-**これは定義集であり、規則を定める場所ではない。** 各語は 1〜2 行の定義と、その語の本文がある単一ソースへのポインタだけを持つ。手順・条件・数値は指し先が持ち、ここでは言い換えない — 言い換えた行は指し先より先に古くなる（joshuafolkken/kit#3080）。
+各語は 1〜2 行の定義と本文へのポインタだけを持つ。手順・条件・数値はここで言い換えない（joshuafolkken/kit#3080）。
 
-`scripts/document/workflow-glossary.test.ts` が、下の主要語が定義されていることと、各ポインタが実在する節に解決することを検査する。
-
-- **lane** — `backlogrun` が子 Issue を並行実行するための、専用ブランチ・`.env`・ポートを持つ git worktree。実装・ゲート・レビューは並行し、マージは直列。→ `.claude/skills/workflow-commands/backlogrun-lanes.md` → "Lanes — running more than one child at a time"
-- **cut** — 実行中のプロセスを意図して終わらせ、新しいプロセスが同じ作業を引き継ぐ境界。レーン子のゲート前の cut と、`backlogrun` のセッション cut がある。→ `.claude/skills/workflow-commands/pre-gate-cut.md` → "The pre-gate cut"、`.claude/skills/workflow-commands/backlogrun-progress.md` → "The hand-off"
+- **lane** — `backlogrun` が子 Issue を並行実行する、専用ブランチ・`.env`・ポートを持つ git worktree。マージは直列。→ `.claude/skills/workflow-commands/backlogrun-lanes.md` → "Lanes — running more than one child at a time"
+- **cut** — プロセスを意図して終わらせ、新しいプロセスが作業を引き継ぐ境界（ゲート前の cut、セッション cut）。→ `.claude/skills/workflow-commands/pre-gate-cut.md` → "The pre-gate cut"、`.claude/skills/workflow-commands/backlogrun-progress.md` → "The hand-off"
 - **hold** — 1 つの作業ツリーを 1 つのランが占有しているという記録。`pnpm josh run:hold` が取り、`pnpm josh run:release` が外す。→ `.claude/skills/workflow-commands/working-tree-hold.md` → "The working-tree hold"
 - **park** — `backlogrun` が自分で決められない子を `needs-decision` で止め、バッチ全体は止めずに次の子へ進むこと。→ `.claude/skills/workflow-commands/backlogrun-park.md` → "park and continue"
-- **point of use** — 文書を入口ではなく、その文書に従うべき操作と同じターンで、その操作の直前に読むこと。→ `.claude/skills/workflow-commands/SKILL.md` → "Four documents are read at the point of use, not at the entry"
+- **point of use** — 文書を入口ではなく、従うべき操作の直前に同じターンで読むこと。→ `.claude/skills/workflow-commands/SKILL.md` → "Four documents are read at the point of use, not at the entry"
 - **entry read** — コマンド起動時に読む文書の集合。`pnpm josh read:set` がその集合と費用を答える。→ `.claude/skills/workflow-commands/SKILL.md` → "Which file to read"
 - **oracle** — 機械的に読める入力だけから規則の答えを計算するコマンド。一覧は `pnpm josh oracle:list`。→ `prompts/collaboration-workflow/residency.md` → "第 0 問"
-- **interrupt** — WIP 上限を超えても起票できる、3 条件で決まる発見。別パッケージ起因の上流起票（割り込み Issue）とは別の区分。→ `prompts/collaboration-workflow/wip-cap.md` → "割り込み起票"、`prompts/collaboration-workflow/upstream-interrupt.md` → "別パッケージ起因の問題は割り込み Issue で対応する"
+- **interrupt** — WIP 上限を超えても起票できる、3 条件で決まる発見。上流起票の割り込み Issue とは別。→ `prompts/collaboration-workflow/wip-cap.md` → "割り込み起票"、`prompts/collaboration-workflow/upstream-interrupt.md` → "別パッケージ起因の問題は割り込み Issue で対応する"
 - **Tier** — 判断点の 3 区分。A は可逆で自分で決める、B は拮抗していて人に聞く、C は不可逆・共有状態で明示指示が要る。→ `CLAUDE.md` → "Decision autonomy"、`prompts/collaboration-workflow/operating-rules.md` → "decision-autonomy"
 - **carry** — `backlogrun` の 1 回の起動の予算と進捗を、セッション cut をまたいで引き継ぐ記録（`pnpm josh run:carry`）。→ `.claude/skills/workflow-commands/backlogrun-steps.md` → "The session cut is inside the invocation"
 - **wave** — エピックの子をまとめて並行実行する組。仕組みではなく、依存宣言で表す形。→ `.claude/skills/epic-commands/execution-waves.md` → "Execution waves — parallel, then one alone, then the rest"

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"）。