@joshuafolkken/kit 1.1455.0 → 1.1471.0

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

@@ -1,59 +1,51 @@
 ## 別パッケージ起因の問題は割り込み Issue で対応する
 
-作業中（実装・検証・レビュー対応のいずれの段階でも）に新たな課題を発見した場合、**即席対応を優先せず根本的な解決を先に行う**。発見した問題が、実は別パッケージ（依存パッケージや、このプロジェクトが消費している配布元 = kit / `josh` ツールなど）に起因する場合でも同様で、現在のリポジトリ内のローカル回避策（ハック・パッチ・回避コード）で押し切ってはならない。根本原因を **対象パッケージ側** で解決する。
+作業中（実装・検証・レビュー対応のどの段階でも）に見つけた問題が別パッケージ（依存パッケージ、配布元の kit / `josh` ツールなど）に起因するとき、現在のリポジトリ内のローカル回避策（ハック・パッチ・回避コード）で押し切らず、**根本原因を対象パッケージ側で解決する**。`CLAUDE.md` → "Cross-package problems → file the upstream Issue, then stop" の本体。
 
 ### 無条件ルール: 起票は確認なし、停止は必ず
 
-**この手順に「これは今の作業をブロックするか？」という判定は一切存在しない。** 上流の欠陥は、ブロックするものもしないものも、**発見した時点で**同じ手順を通る。例外はない。判定を置かない理由は `docs/maintainers/upstream-interrupt-rationale.md` → "Why there is no blocking test" にある。
+**「今の作業をブロックするか」は判定しない。** 上流の欠陥は、発見した時点で例外なく同じ手順を通る（`docs/maintainers/upstream-interrupt-rationale.md` → "Why there is no blocking test"）。
 
-- **トリガーは「発見」であって「ブロックし始めたとき」ではない**
-- **起票は Tier A（確認なし）**。起票してよいか、どのリポジトリへ起票するか、いずれもユーザー確認を取らない。対象は first-party に限る（→「第三者リポジトリへの書き込みは Tier C（明示指示が必要）」）
-- **停止は無条件**。Issue が存在する状態にしてから停止する。上流の修正を待つか先送りするかは、Issue を目の前にしたユーザーが決める
-- **`backlogrun` の中では、停止の範囲がセッション全体ではなくその子 Issue に限定される**。起票と回避策の禁止は変わらない。上流の修正を待つか先送りするかは人の判断なので、該当の子に `needs-decision` を付けて park し、依存していない他の子へ進む（→ `.claude/skills/workflow-commands/backlogrun-park.md` → "Only a person's judgement carries `needs-decision`"）
+- 起票は Tier A — 起票するか・どこへ起票するかをユーザーに確認しない。対象は first-party に限る（→「第三者リポジトリへの書き込みは Tier C（明示指示が必要）」）
+- **停止は無条件**。Issue を作ってから停止し、待つか先送りするかはユーザーが決める
+- `backlogrun` の中では、停止はその子 Issue に限る。起票と回避策の禁止は変わらない。該当の子に `needs-decision` を付けて park し、依存していない他の子へ進む（→ `.claude/skills/workflow-commands/backlogrun-park.md` → "Only a person's judgement carries `needs-decision`"）
 
 ### 実行中のリポジトリ自身のラン機構の不具合
 
-**この手順の対象は別パッケージであり、実行中のリポジトリ自身は含まない。** kit の中で kit のラン機構（`backlog:drive`、`run:wake`、`run:carry`、レーン、分類、カウンタ、ガードなど）の不具合を見つけた場合、それは上流の欠陥ではなく**このリポジトリの割り込み**である。上流 Issue を立てて停止する代わりに、次の手順を取る。この節がその単一ソースである。
+**実行中のリポジトリ自身はこの手順の対象外である。** kit の中で kit のラン機構（`backlog:drive`、`run:wake`、`run:carry`、レーン、分類、カウンタ、ガードなど）の不具合を見つけたら、上流 Issue で停止する代わりに、このリポジトリの割り込みとして次を行う。
 
 1. **起票する** — `pnpm josh issue:file "<title>" --body-file <path> --depth <n> --route interrupt --label priority:high`。上限は効かない（`wip-cap.md` →「割り込み起票 — 上限が効かない側」の条件 2）
-2. **止まらずに直す** — 壊れた機構を迂回しない（回避策の禁止と、検証ゲートを緩めない規則はここでも変わらない）。`backlogrun` の中では、その割り込みを次の子にし、修正が着地してから塞がれていた子へ戻る。プールから選ぶランでは `priority:high` が先頭に並べ、epic の下では `wip-cap.md` の手順 3 で挿入する。名前を指定したランのドライバーは指定された Issue しか出さないので、`pnpm josh lane:launch <N>` で自分で dispatch する。バッチの外では `wip-cap.md` の手順 4 が変わらず効く — 起票まで済ませ、打つべき `fullrun #<N>` を報告して止まる
-3. **再開できるなら自分で再開し、動くことを確かめる** — 修正のマージ後、再開の手段がある答えには人の打ち直しを求めない。手渡し済みの記録、所有者が死んだ記録、監督プロセスの停止（`warning` Telegram）には `pnpm josh run:wake --start`、`run:carry` の `standing` には `pnpm josh run:carry --resume "<invocation>" --owner "$PPID"` を自分で打つ。そのあと `pnpm josh run:wake --list` が監督プロセスを示し、そのログに次の子の dispatch が現れることを確かめて報告する
-4. **人に打ち直しを求めるのは再開の手段が無いときだけ** — `mismatch`（別の起動の記録）、別の生きた所有者の `busy`。新しい承認を宣言するのは人だけ、という規則も変わらない
-5. **`needs-decision` を付けない** — ランが自分で直せる不具合は人の判断を要さない（`.claude/skills/workflow-commands/backlogrun-park.md` → "Only a person's judgement carries `needs-decision`"）
+2. **止まらずに直す** — 壊れた機構を迂回せず、検証ゲートも緩めない。`backlogrun` の中では割り込みを次の子にし、着地後に塞がれていた子へ戻る（プールでは `priority:high` が先頭、epic の下では `wip-cap.md` の手順 3 で挿入、名前指定のランでは `pnpm josh lane:launch <N>` で自分で dispatch）。バッチの外では `wip-cap.md` の手順 4 どおり、打つべき `fullrun #<N>` を報告して止まる
+3. **再開できるなら自分で再開し、動くことを確かめる** — 修正のマージ後、手渡し済み・所有者が死んだ記録・監督プロセスの停止（`warning` Telegram）には `pnpm josh run:wake --start`、`run:carry` の `standing` には `pnpm josh run:carry --resume "<invocation>" --owner "$PPID"` を打つ。`pnpm josh run:wake --list` が監督プロセスを示し、ログに次の子の dispatch が現れることを確かめて報告する
+4. **人に打ち直しを求めるのは再開の手段が無いときだけ** — `mismatch`（別の起動の記録）、別の生きた所有者の `busy`。新しい承認を宣言するのは人だけ
+5. **`needs-decision` を付けない**（`.claude/skills/workflow-commands/backlogrun-park.md` → "Only a person's judgement carries `needs-decision`"）
 
 手順:
 
-1. **現在の作業を退避する**: `git stash push -u -m "upstream-interrupt: paused #<N>"`（WIP コミットでも可）。退避したことを忘れないよう、この時点で stash を作る。メッセージ付きで積むのは、復元をメッセージで特定するため（下記ステップ 5）
-2. **進行中の Issue に状況を明記する**: `pnpm josh issue:comment <N> --body-file <path>` で、(a) 作業を stash したこと、(b) 中断理由（どの別パッケージの・どんな問題で中断したか）、(c) 対象パッケージに作成した新 Issue へのリンクを `## Upstream issues` 見出しの下に `owner/repo#N` 形式で、を記載する。これにより「なぜこの Issue が一時停止しているか」と「何を待っているのか」が後から監査できる（→「起票元へのバックリンク」）
-3. **対象パッケージのリポジトリに新しい Issue を作成する（確認なし）**: `pnpm josh issue:file "<root-cause title>" --body-file <body-file> --depth <n> --route tier-a --repo <owner>/<repo>`（`route:tier-a` は実装中の Tier A 起票を経路として集計するためのラベル — joshuafolkken/kit#1083）。本文の検査、本文が宣言する分類ラベルの付与、`## Origin` 節の確認、起票先での重複探し、`epic:bundle` はこのコマンドが実行する（`docs/josh-commands-backlog.md` → `josh issue:file`）。分類の単一ソースは `prompts/collaboration-workflow/issue-template.md`。根本原因・再現・期待結果を Step 1 のテンプレに沿って記載し、**本文に `## Origin` 節を置いて起票元 Issue を `owner/repo#N` 形式で書く**（→「起票元へのバックリンク」）。ここで「起票してよいか」を尋ねて停止してはならない
-4. **`confirmation` Telegram を送って停止する**: 上流 Issue の URL と、何が止まっているかを本文に書く（→ `CLAUDE.md` → "Mid-workflow stop notification (`confirmation`)"）。無人実行でも画面外でユーザーが気付ける。停止は Issue が既に存在する状態で行うので、ユーザーは「待つ / 先送りする」を Issue を見ながら 1 語で答えられる
-5. **元の作業を再開する**: 上流の修正がマージされた、または**ユーザーが先送りを明示判断した**後に `pnpm josh stash:pop "upstream-interrupt: paused #<N>"`（位置指定や引数なしの `git stash pop` は使わない — stash は全 work tree が共有する 1 本のスタックで、別のレーンの stash を取り込む恐れがある）して、退避していた元タスクを続行する。上流 Issue を割り込みで実装するかどうかもユーザーの判断（上流パッケージの実装・PR・マージはそれぞれのワークフロー規則に従う）
+1. **現在の作業を退避する**: `git stash push -u -m "upstream-interrupt: paused #<N>"`（WIP コミットでも可）
+2. **進行中の Issue に状況を書く**: `pnpm josh issue:comment <N> --body-file <path>` で、stash したこと、中断理由（どの別パッケージのどんな問題か）、新 Issue へのリンク（`## Upstream issues` 見出しの下に `owner/repo#N` 形式、→「起票元へのバックリンク」）
+3. **対象パッケージのリポジトリに Issue を作成する（確認なし）**: `pnpm josh issue:file "<root-cause title>" --body-file <body-file> --depth <n> --route tier-a --repo <owner>/<repo>`（joshuafolkken/kit#1083）。検査・分類ラベル・重複探し・`epic:bundle` はコマンドが行う（`docs/josh-commands-backlog.md` → `josh issue:file`）。根本原因・再現・期待結果を `prompts/collaboration-workflow/issue-template.md` の Step 1 のテンプレで書き、`## Origin` 節に起票元 Issue を `owner/repo#N` 形式で書く
+4. **`confirmation` Telegram を送って停止する**: 上流 Issue の URL と何が止まっているかを書く（→ `CLAUDE.md` → "Mid-workflow stop notification (`confirmation`)"）
+5. **元の作業を再開する**: 上流の修正がマージされた、またはユーザーが先送りを明示判断した後に `pnpm josh stash:pop "upstream-interrupt: paused #<N>"` で復元する（`operating-rules.md` → "no-self-staging"）。上流 Issue を割り込みで実装するかもユーザーが決める
 
 ### 第三者リポジトリへの書き込みは Tier C（明示指示が必要）
 
-上の「起票は確認なし」は **first-party**（`pnpm josh repo:party` が `first-party` と答えるリポジトリ）だけに成り立つ。**自分たちが所有しないリポジトリへの書き込みは、これとは別物**として扱う。
+「起票は確認なし」は first-party だけに成り立つ。
 
-- **判定は機械的に行い、判断に委ねない**: `pnpm josh repo:party [<owner/repo>]` が `first-party` / `third-party` / `unknown` の 1 語で答える（対象リポジトリの owner がセッションのリポジトリの owner と一致すれば **first-party**、owner を読めなければ **unknown** で third-party 扱いはしない）。**それ以外は全て third-party** で、fork も、単に contribute しているだけの org リポジトリも third-party に入る
-- **first-party は従来どおり**: Tier A。確認なしで起票し、双方向バックリンクを書き、停止する
-- **third-party は書き込みの種別を問わず Tier C**: Issue・コメント・PR・Discussion・レビューのいずれも、**その turn におけるユーザーの明示指示**なしに行ってはならない。公開は外向きかつ実質不可逆である（`docs/maintainers/upstream-interrupt-rationale.md` → "Why third-party writes are Tier C"）
-- **third-party だと判明したときの手順**: (1) **自分たちの側の Issue** に証拠込みで所見を記録する。見出しは `## Upstream candidate` を使い、`## Upstream issues` は使わない（後者は「起票済み」を主張する見出しであるため）。(2) 報告本文の下書きをその Issue 内に用意し、ユーザーが 1 メッセージで承認できる状態にする。(3) 対象プロジェクト名と報告しようとしている内容を書いた `confirmation` Telegram を送って**停止する**
-- **third-party 報告の証拠バー**（下書きを提示する前に満たす）:
-  - **自プロジェクトの外で成立する最小再現**（対象の依存だけを入れた素の scaffold）。用意できない場合は「プロジェクト組み込みの再現しかない」ことを下書きに明記する
-  - **本文の全主張が検証済み**であること。推測を事実として書かない
-  - 同じ欠陥を扱う**既存 Issue の検索**
-- **取り下げも外向きの行為**: 既に起票した third-party Issue のクローズ・編集・コメントも、同じく明示指示を要する
-- **正しい診断は公開の許可ではない**。所見の正しさは、この節のどの要求も免除しない（事例: `docs/maintainers/upstream-interrupt-rationale.md` → "Why a correct diagnosis is not authorization"）
+- **判定は `pnpm josh repo:party [<owner/repo>]` が答える**: `first-party` / `third-party` / `unknown`（unknown は third-party 扱いしない）。fork や contribute しているだけの org リポジトリも third-party
+- **third-party への書き込みは種別を問わず Tier C**: Issue・コメント・PR・Discussion・レビュー、既存 Issue のクローズ・編集も、その turn のユーザーの明示指示なしに行わない。正しい診断も許可ではない（`docs/maintainers/upstream-interrupt-rationale.md` → "Why third-party writes are Tier C"、`docs/maintainers/upstream-interrupt-rationale.md` → "Why a correct diagnosis is not authorization"）
+- third-party と判明したら: (1) 自分たちの側の Issue に証拠込みで所見を `## Upstream candidate` 見出しで記録する（`## Upstream issues` は使わない）。(2) 報告本文の下書きをその Issue 内に用意する。(3) 対象プロジェクト名と報告内容を書いた `confirmation` Telegram を送って停止する
+- 下書きの前に揃える証拠: 自プロジェクトの外で成立する最小再現（無ければ「プロジェクト組み込みの再現しかない」と明記）、全主張の検証、既存 Issue の検索
 
 ### 検証ゲートを緩めることも「回避策」である
 
-ローカルに回避コードを書くことだけが違反ではない。**上流の欠陥に合わせて `lint` / `tsc` / `cspell` / unit / E2E の出力を絞り込む・狭める・読み替える行為も、ローカルパッチを書くのと同じ違反**であり、同じ停止を引き起こす。
+**上流の欠陥に合わせて `lint` / `tsc` / `cspell` / unit / E2E の出力を絞り込む・狭める・読み替えることは、ローカルパッチと同じ違反**で、同じ停止を引き起こす。
 
-- 典型例: 上流が配布する設定によって生成されるディレクトリ由来の型エラーを除外し、「プロジェクトソースはエラー 0」として完了ゲートを通過したことにする
-- **絞り込んだことを正直に開示しても、ルールを満たしたことにはならない**。完了報告の読者は「緑ではない型チェック」を緑として受け取る
-- 検証ゲートは上流の欠陥に合わせて調整しない。**調整したくなった時点が、このルールの発火点**である
+- 例: 上流が配布する設定で生成されるディレクトリ由来の型エラーを除外し、「プロジェクトソースはエラー 0」としてゲートを通す
+- 絞り込みを開示しても、ルールを満たしたことにはならない
+- ゲートを調整したくなった時点が、このルールの発火点である
 
 注意:
 
-- **即席回避と根本対応は「迷って選ぶもの」ではない**。上流起因と分かった時点で選択肢は根本対応だけであり、「今回は軽いから即席で」という判断はこの手順に存在しない
-- 上流パッケージの **マージ等の共有状態操作** は、起票と違って Tier A ではない。通常どおりそれぞれのワークフローの明示起動を要する
-- このルールは横断ドキュメント（CLAUDE.md「Cross-package problems → file the upstream Issue, then stop」）のカノニカル参照
+- 上流起因と分かったら選択肢は根本対応だけ。「今回は軽いから即席で」はない
+- 上流パッケージのマージ等の共有状態操作は Tier A ではない。それぞれのワークフローの明示起動を要する

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

@@ -1,73 +1,67 @@
 # オープン Issue の WIP 上限
 
-**単一ソースはこのファイルである。**
-
-**この規則は常駐しておらず、配送もされない — 起票するコマンドそのものが守らせる**（joshuafolkken/kit#1524 で常駐を外し、その後 `rule:guard` の配送行も外した）。`pnpm josh issue:file` が起票の前に件数を数え、上限を超えて免除が無ければ何も送らずに保留し、そこで拒否・2 つの免除・免除を決める 3 条件を印字する（`gh issue create` や `…/issues` への `title` 付き POST による直接起票は `direct-filing` が毎回拒否するので、起票は必ずこのコマンドを通る）。事前の拒否と出し直しの往復は無い。保留文の実体は `scripts/issue/issue-wip.ts` の `HELD_MESSAGE` にある（固定するテストは `docs/maintainers/wip-cap-rationale.md` → "Tests that pin the wording"）。
-
-背景・測定・経緯は保守者向けの文書にあり（上限が要る理由は `docs/maintainers/wip-cap-rationale.md` → "Why a cap is needed — the measurement"）、ラン中に読む必要はない。
+常駐も配送もされず（joshuafolkken/kit#1524）、起票コマンドが守らせる（直接起票は `direct-filing` が拒否する）。保留文は `scripts/issue/issue-wip.ts` の `HELD_MESSAGE`（`docs/maintainers/wip-cap-rationale.md` → "Tests that pin the wording"）、背景は `docs/maintainers/wip-cap-rationale.md` → "Why a cap is needed — the measurement"。
 
 ## 規則
 
 **オープン Issue が上限を超えている状態で新しく起票するときは、先に 1 件閉じる。**
 
-**件数は `pnpm josh issue:file` が起票の前に数える**（joshuafolkken/kit#3181）。手で数えることも、見積もりや記憶で済ませることもない。数え方・印字・保留の詳細は `docs/josh-commands-backlog.md` → "`josh issue:file`" にある。
+**件数は `pnpm josh issue:file` が起票の前に数える**（joshuafolkken/kit#3181、`docs/josh-commands-backlog.md` → "`josh issue:file`"）。手や記憶で数えない。
 
-- **上限は 30。** これを超える 1 件を作る前に 1 件閉じる。エージェントが読む文書（`CLAUDE.md`・`prompts/`・配布 skill）がこの数字を書くのはこの行だけで、一次情報は `scripts/issue/issue-wip.ts` の `WIP_CAP` である（一致はテストが固定する）。
-- コマンドは起票先（`--repo` を付ければそのリポジトリ）のオープン Issue を epic も含めて数え、`wip:` 行に件数・上限・判定を印字する。上限を超えて免除が宣言されていなければ**何も送らずに保留し、免除の問いを印字する**。
-- **免除を宣言するのはこのファイルの判断である** — `--route interrupt`（下の 3 条件）、`--route split` / `--route tier-a`（実行が詰まる起票）はルートそのものが宣言になる。ルートの無い実行が詰まる起票（利用者が `new` と打った入口など）は `--over-cap` を付けて出し直す。裁量起票（`--route review-cap` を含む）に `--over-cap` を付けてはならない。
+- **上限は 30。** 一次情報は `scripts/issue/issue-wip.ts` の `WIP_CAP`（他の文書にこの数字を書かない）。
+- コマンドは起票先（`--repo` 指定時はそのリポジトリ）のオープン Issue を epic 込みで数えて `wip:` 行に印字し、超過して免除が無ければ何も送らずに保留し、免除の問いを印字する。
+- 免除の宣言: `--route interrupt`（下の 3 条件）、`--route split` / `--route tier-a`（実行が詰まる起票）はルート自体が宣言になる。ルートの無い実行が詰まる起票（利用者が `new` と打った入口など）は `--over-cap` を付けて出し直す。裁量起票（`--route review-cap` を含む）に `--over-cap` を付けてはならない。
 
 ## 超過時の手順
 
-起票しようとした時点で上限を超えていたら、**その起票が裁量によるものか、実行がそれに詰まっているか、割り込みか**の 3 つに分岐する。判断ではなく、起票の種類で決まる。**上限が効くのは裁量側だけである。**
+起票の種類で分岐する。**上限が効くのは裁量側だけである。**
 
-**判定するのは「起票 1 件」ではなく「起票のひとまとまり」である。** 分割判定が作る子 N 件とその epic、割り込み Issue とその上流バックリンク、起票直後の `epic:bundle` が `create_epic` と答えたときの epic — これらは 1 回の起票行為であり、途中で上限に当たって半分だけ作るのが最悪の結果になる。**ひとまとまりの先頭で 1 回だけ判定し、通ったらまとまり全体を作り切る。**
+**判定するのは「起票 1 件」ではなく「起票のひとまとまり」である。** 分割の子と epic、割り込みと上流バックリンク、`epic:bundle` が `create_epic` と答えた epic は、先頭で 1 回だけ判定し、通ったら全体を作り切る。
 
 ### 裁量起票 — 上限が効く側
 
-レビュー上限の branch 2 と、思いついた改善や気付きの記録。**起票しなくても現在の実行が完了するもの**が該当する。
+レビュー上限の branch 2 と、改善や気付きの記録 — 起票しなくても現在の実行が完了するもの。
 
-1. **まず 1 件閉じる。** 閉じてよいのは、実際に終わっているもの・重複・別の Issue に取って代わられたもの・もう要らないと判断できるものだけである。クローズコメントにどれに当たるかを 1 行書く。
-2. **正直に閉じられるものが無いなら、起票しない。** 場所を空けるために、まだ意味のある Issue を閉じてはならない。それは上限を満たしたことにはならず、記録を壊すだけである。
-3. **起票しない場合、その指摘は起票以外の出口を取る。** レビュー指摘なら branch 3（PR 本文に 1 行残して落とす）である。**これは既定の出口であり、上限に阻まれたときの代替ではない。**
+1. まず 1 件閉じる（終わった・重複・取って代わられた・不要のものだけ。クローズコメントにどれかを 1 行書く）。
+2. **正直に閉じられるものが無いなら、起票しない。** 場所を空けるために、まだ意味のある Issue を閉じてはならない。
+3. 起票しない指摘は起票以外の出口を取る。レビュー指摘なら branch 3（PR 本文に 1 行残して落とす）で、これは既定の出口であり上限に阻まれたときの代替ではない。
 
 ### 実行が詰まる起票 — 上限が効かない側
 
-前提 Issue（`prerequisite.md`）、別パッケージ起因の割り込み Issue、ユーザーが `new` と打った入口、`issue:scout` が重複無しと答えた新規作業、**そして分割判定が作る子 Issue と epic**。**これらは起票しないと実行が進まない。**
+前提 Issue（`prerequisite.md`）、別パッケージ起因の割り込み Issue、ユーザーが `new` と打った入口、`issue:scout` が重複無しと答えた新規作業、そして分割判定が作る子 Issue と epic。
 
 - **上限を理由に止めない。** 理由は `docs/maintainers/wip-cap-rationale.md` → "Why a filing a run is blocked by is not stopped"。
-- **分割の子がここに入る理由**: 分割を検出した `fullrun` / `halfrun` は「子と epic を起票して **STOP**」と定められている（`fullrun.md` / `halfrun.md`）。**分割するかどうかを決めるのは分割判定の側**で、既定はもう「分割しない」に上がっている — 上限が二重に効く必要はない。
-- **超過した事実は完了報告に 1 行書く**（例: 「オープン 34 件で起票した」）。上限は可視化のための装置なので、超えたことが見えていれば役割は果たしている。
+- **分割の子がここに入る理由**: 分割を検出した `fullrun` / `halfrun` は「子と epic を起票して STOP」と定められており（`fullrun.md` / `halfrun.md`）、分割するかは分割判定の側が決める。
+- 超過した事実は完了報告に 1 行書く（例: 「オープン 34 件で起票した」）。
 
 ### 割り込み起票 — 上限が効かない側（3 条件で機械的に決める）
 
-**重大な欠陥の発見は、それが現在のランを止めていなくても捨ててはならない。** 上限の目的は増加を見えるようにすることであって、**発見を捨てることではない**（`docs/maintainers/wip-cap-rationale.md` → "Why a cap is needed — the measurement"）。由来は `docs/maintainers/wip-cap-rationale.md` → "Where the interrupt category comes from"。
-
-**別パッケージ起因の割り込みとは別の区分である。** あちらは上流リポジトリへ起票して停止する手順（`upstream-interrupt.md`、`route:tier-a`）で、実行が詰まる側に属する。ここで言う割り込みは、**このリポジトリの欠陥で、発見したランをブロックしていないもの**を指す。
+重大な欠陥の発見は、ランを止めていなくても捨てない（`docs/maintainers/wip-cap-rationale.md` → "Where the interrupt category comes from"）。対象はこのリポジトリの欠陥で、発見したランをブロックしていないもの（別パッケージ起因は `upstream-interrupt.md`、実行が詰まる側）。
 
 #### 3 条件 — 該当するかは判断ではない
 
-**次の 3 つのいずれかを満たすかどうかだけで決める。**
+次のいずれかを満たすかだけで決める。
 
 1. **検証が誤った答えを返す** — 緑であってはならないものが緑になる、または無実の変更が赤にされる
-2. **文書化された作業手順が完了できなくなる** — 並列レーン、`josh propagate` など、ドキュメントに書かれた手順が現状のコードでは通らない
+2. **文書化された作業手順が完了できなくなる** — 並列レーン、`josh propagate` など、ドキュメントの手順が現状のコードでは通らない
 3. **データが失われる、またはリポジトリの外に書き込む**
 
-**3 つのいずれにも当たらない発見は、従来どおり裁量側の出口を取る。** 改善案、設計上の好み、未検証の疑い、「あとで直したい」はここに入らない — レビュー指摘なら branch 3（PR 本文に 1 行残して落とす）であり、それは既定の出口であって上限に阻まれたときの代替ではない。
+**3 つのいずれにも当たらない発見は、従来どおり裁量側の出口を取る。** 改善案、設計上の好み、未検証の疑い、「あとで直したい」がこれに当たる。
 
 **深刻さの自己申告は条件ではない。** 理由は `docs/maintainers/wip-cap-rationale.md` → "Why self-reported severity is not a condition"。
 
 #### 該当したときの手順
 
-1. **上限に関係なく起票する。** 1 件閉じることを条件にしない。起票は `pnpm josh issue:file` で行う。本文の検査、本文が宣言する分類ラベルの付与、重複探し、`epic:bundle` はこのコマンドが実行する（`docs/josh-commands-backlog.md` → `josh issue:file`）。
+1. **上限に関係なく起票する。** 1 件閉じることを条件にしない。本文の検査、分類ラベルの付与、重複探し、`epic:bundle` はコマンドが行う（`docs/josh-commands-backlog.md` → `josh issue:file`）。
 
    ```bash
    pnpm josh issue:file "<title>" --body-file <body-file> --depth <n> --route interrupt
    ```
 
-2. **超過している事実と、当たった条件の番号を本文に 1 行書く**（例:「オープン 37 件で起票。3 条件のうち 2（文書化された手順が完了できない）に該当」）。**どちらか一方では足りない** — 件数だけでは判定が再現できず、条件だけでは上限の可視化が効かない。
-3. **次に実行されるものとして挿入する。** epic の下にあるなら `pnpm josh epic --add <E> <N>` で、**位置を指定せずに**追加する（`<E>` が epic、`<N>` が起票した割り込み）。**`--before` / `--after` を使ってはならない。** それらは `blocked-by` を書き込み、「発見したランをブロックしていない欠陥」という割り込みの定義と矛盾する**偽の依存関係**になる。**順序は実行側が持つ** — 先に提示させたいときは、行だけを動かす `--order-before <M>` を使う。仕組みと経緯は `docs/maintainers/wip-cap-rationale.md` → "Why an addition names no position"。**epic の下に無いなら挿入先そのものが無い**ので、この手順は飛ばして 4 だけを行う。
-4. **着手は、既にある承認の内側でのみ、指示を待たずに行う。** `backlogrun` の中なら、打たれたキーワードがバッチを承認しているので、割り込みは次の子として着手してよい。**バッチの外では `CLAUDE.md` →「Explicit invocation required」が変わらず効く** — 起票と挿入まで済ませたうえで、利用者に打つべきコマンド（`fullrun #<N>`）を報告して止まる。**割り込みは上限の例外であって、明示起動規則の例外ではない。**
+2. 超過している事実と当たった条件の番号を、両方とも本文に 1 行書く（例:「オープン 37 件で起票。3 条件のうち 2（文書化された手順が完了できない）に該当」）。
+3. 次に実行されるものとして挿入する。epic の下なら `pnpm josh epic --add <E> <N>` で**位置を指定せずに**追加する（`<E>` が epic、`<N>` が割り込み）。**`--before` / `--after` を使ってはならない。** それらは `blocked-by` を書き込み、**偽の依存関係**になる。**順序は実行側が持つ** — 先に提示させたいときは行だけを動かす `--order-before <M>` を使う（`docs/maintainers/wip-cap-rationale.md` → "Why an addition names no position"）。**epic の下に無いなら挿入先そのものが無い**ので、4 だけを行う。
+4. 着手は既にある承認の内側でのみ、指示を待たずに行う。`backlogrun` の中なら次の子として着手してよい。バッチの外では `CLAUDE.md` →「Explicit invocation required」が効き、起票と挿入まで済ませて打つべきコマンド（`fullrun #<N>`）を報告して止まる。**割り込みは上限の例外であって、明示起動規則の例外ではない。**
 
-**起票と、実行されるようにするところまでが 1 つのまとまりである。** epic の下にある割り込みを起票だけして追加しなければ、`epic:next` はそれを候補にすら出さない — Issue は残るが実行されないという、コメントに埋もれるのと大差ない状態になる。**epic の外にある割り込みでは、まとまりの後半は 4 の報告そのもの**であり、打つべきコマンドを利用者に渡すまでが 1 回の行為である。上の「ひとまとまりで判定する」がここにも効く。
+起票と、実行されるようにするところまでが 1 つのまとまりである — epic の下で追加しなければ `epic:next` は候補に出さない。**epic の外にある割り込みでは、まとまりの後半は 4 の報告そのもの**である。
 
-**割り込みをバッチの中で単独で走らせるか、並列のレーンで走らせるか**は `.claude/skills/workflow-commands/backlogrun-lanes.md` → "A solo run" が単一ソースである（理由は `docs/maintainers/wip-cap-rationale.md` → "Why a solo run"）。上限の数字の変え方は `docs/maintainers/wip-cap-rationale.md` → "Changing the cap itself"、上限が分割判定・レビュー上限と一緒に動く理由は `docs/maintainers/wip-cap-rationale.md` → "The three move together"と `docs/maintainers/wip-cap-rationale.md` → "Why the three landed in one commit"にある。
+割り込みを単独で走らせるか並列レーンで走らせるかは `.claude/skills/workflow-commands/backlogrun-lanes.md` → "A solo run" に従う（`docs/maintainers/wip-cap-rationale.md` → "Why a solo run"）。上限の数字の変え方は `docs/maintainers/wip-cap-rationale.md` → "Changing the cap itself"、分割判定・レビュー上限と一緒に動く理由は `docs/maintainers/wip-cap-rationale.md` → "The three move together" と `docs/maintainers/wip-cap-rationale.md` → "Why the three landed in one commit"。

package/prompts/collaboration-workflow.md

@@ -1,32 +1,31 @@
 # Issue-Driven Collaboration Workflow
 
-<!-- cspell:words coderabbit -->
-
-このドキュメントは、Claude / Cursor / Gemini を含む複数の AI ツールで共通に使う Issue 駆動の共同作業ワークフローの**索引**である。
+複数の AI ツール（Claude / Cursor / Gemini）で共通に使う Issue 駆動ワークフローの**索引**。
 
 ## この索引の使い方
 
-**これは人間が読むための索引であり、規則を定める場所ではない。** 常駐の引き金は `CLAUDE.md` に、実行中の操作手順は `.claude/skills/workflow-commands/` に、各話題の規則は下の表のファイルにあり、それぞれが自分の規則の一次情報である。この索引はそれらを言い直さない。
+人間が読むための索引であり、規則を定める場所ではない。常駐の引き金は `CLAUDE.md`、実行中の手順は `.claude/skills/workflow-commands/`、各話題の規則は下表のファイルが一次情報である。
 
-**必要な 1 本だけを開くこと。この索引を入口に、下の表から選ぶ。** 他の文書からこれらの話題を指すときは、索引を経由せず**本文があるファイルを直接指す**（[`residency.md`](./collaboration-workflow/residency.md)）。
+- 下表から必要な 1 本だけを開く。
+- 他の文書から話題を指すときは、索引でなく**本文があるファイルを直接指す**（[`residency.md`](./collaboration-workflow/residency.md)）。
 
-| 話題                                                                                              | ファイル                                                                  |
-| ------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------- |
-| Overview                                                                                          | [`overview.md`](./collaboration-workflow/overview.md)                     |
-| Step 1: Issue 作成テンプレ                                                                        | [`issue-template.md`](./collaboration-workflow/issue-template.md)         |
-| Step 2: 提案依頼（AI 共通）                                                                       | [`proposal-request.md`](./collaboration-workflow/proposal-request.md)     |
-| Step 3: 計画コメントを記録して通知する                                                            | [`plan-comment.md`](./collaboration-workflow/plan-comment.md)             |
-| 報告フォーマット（平易な概要 ＋ 技術詳細）                                                        | [`report-format.md`](./collaboration-workflow/report-format.md)           |
-| セッション向け出力で Issue はリンク＋セッション言語の短い要約で参照する                           | [`issue-citation.md`](./collaboration-workflow/issue-citation.md)         |
-| オープン Issue の WIP 上限                                                                        | [`wip-cap.md`](./collaboration-workflow/wip-cap.md)                       |
-| 別パッケージ起因の問題は割り込み Issue で対応する                                                 | [`upstream-interrupt.md`](./collaboration-workflow/upstream-interrupt.md) |
-| 原則 — クローン禁止・シンプル第一・相談と実行の区別・最新優先・恒久ルールと配布物と規則の置き場所 | [`principles.md`](./collaboration-workflow/principles.md)                 |
-| ファイル編集はコマンド本文に本文を載せない                                                        | [`file-edits.md`](./collaboration-workflow/file-edits.md)                 |
-| 本文をシェルの二重引用符に載せない                                                                | [`shell-body.md`](./collaboration-workflow/shell-body.md)                 |
-| 独立した呼び出しは同じターンに載せる                                                              | [`turn-batching.md`](./collaboration-workflow/turn-batching.md)           |
-| `gh` は REST（`gh api`）で書く — 散文の指示も含む                                                 | [`gh-rest.md`](./collaboration-workflow/gh-rest.md)                       |
-| 常駐ドキュメントと skill の分担（何を常駐に残すか）                                               | [`residency.md`](./collaboration-workflow/residency.md)                   |
-| 引き金つき配送 — 規則を効く瞬間に届ける                                                           | [`rule-delivery.md`](./collaboration-workflow/rule-delivery.md)           |
-| コマンド出力が文脈へ持ち込む量の上限                                                              | [`output-bounds.md`](./collaboration-workflow/output-bounds.md)           |
-| 運用ルール                                                                                        | [`operating-rules.md`](./collaboration-workflow/operating-rules.md)       |
-| 用語集 — lane・cut・hold・park などの定義と単一ソース                                             | [`glossary.md`](./collaboration-workflow/glossary.md)                     |
+| 話題                                                       | ファイル                                                                  |
+| ---------------------------------------------------------- | ------------------------------------------------------------------------- |
+| Overview                                                   | [`overview.md`](./collaboration-workflow/overview.md)                     |
+| Step 1: Issue 作成テンプレ                                 | [`issue-template.md`](./collaboration-workflow/issue-template.md)         |
+| Step 2: 提案依頼（AI 共通）                                | [`proposal-request.md`](./collaboration-workflow/proposal-request.md)     |
+| Step 3: 計画コメントの記録と通知                           | [`plan-comment.md`](./collaboration-workflow/plan-comment.md)             |
+| 報告フォーマット（平易な概要 ＋ 技術詳細）                 | [`report-format.md`](./collaboration-workflow/report-format.md)           |
+| Issue はリンク＋セッション言語の短い要約で参照する         | [`issue-citation.md`](./collaboration-workflow/issue-citation.md)         |
+| オープン Issue の WIP 上限                                 | [`wip-cap.md`](./collaboration-workflow/wip-cap.md)                       |
+| 別パッケージ起因の問題は割り込み Issue                     | [`upstream-interrupt.md`](./collaboration-workflow/upstream-interrupt.md) |
+| 原則 — クローン禁止・シンプル第一・相談と実行・最新優先 等 | [`principles.md`](./collaboration-workflow/principles.md)                 |
+| ファイル編集はコマンド本文に本文を載せない                 | [`file-edits.md`](./collaboration-workflow/file-edits.md)                 |
+| 本文をシェルの二重引用符に載せない                         | [`shell-body.md`](./collaboration-workflow/shell-body.md)                 |
+| 独立した呼び出しは同じターンに載せる                       | [`turn-batching.md`](./collaboration-workflow/turn-batching.md)           |
+| `gh` は REST（`gh api`）で書く                             | [`gh-rest.md`](./collaboration-workflow/gh-rest.md)                       |
+| 常駐ドキュメントと skill の分担                            | [`residency.md`](./collaboration-workflow/residency.md)                   |
+| 引き金つき配送 — 規則を効く瞬間に届ける                    | [`rule-delivery.md`](./collaboration-workflow/rule-delivery.md)           |
+| コマンド出力が文脈へ持ち込む量の上限                       | [`output-bounds.md`](./collaboration-workflow/output-bounds.md)           |
+| 運用ルール                                                 | [`operating-rules.md`](./collaboration-workflow/operating-rules.md)       |
+| 用語集 — lane・cut・hold・park など                        | [`glossary.md`](./collaboration-workflow/glossary.md)                     |

package/prompts/refactoring.md

@@ -1,103 +1,93 @@
 # リファクタリング支援プロンプト
 
-このプロンプトは AI へのリファクタリング指示書です。
-
-- **「リファクタリングを提案して」** → 分析・提案のみ行い、実装はユーザーに委ねる
-- **「リファクタリングして」** → 優先度高・中を自動実施し、同一セッション内で収束するまで繰り返す
+- 「リファクタリングを提案して」→ 分析・提案のみ。実装はユーザーに委ねる
+- 「リファクタリングして」→ 優先度高・中を自動実施し、同一セッション内で収束するまで繰り返す
 
 ---
 
 ## 対象と候補の算出（`pnpm josh refactor:scan`）
 
-対象ファイルの特定・スコープ拡張・lint で決まる候補の集計・収束判定は、すべて `pnpm josh refactor:scan` が計算する。手作業で grep せず、まずこのコマンドを実行する（joshuafolkken/kit#2180）。詳細は `docs/josh-commands.md` の `josh refactor:scan`。
+対象ファイル・スコープ拡張・lint 候補の集計・収束判定は `pnpm josh refactor:scan` が計算する。手作業で grep せず、まずこれを実行する（joshuafolkken/kit#2180、詳細は `docs/josh-commands.md` の `josh refactor:scan`）。
 
 ```bash
 pnpm josh refactor:scan
 ```
 
-コマンドが行うこと：
-
-- **対象ファイルの特定**: 作業ツリーの変更＋main との差分＋未追跡ファイルを起点とし、いずれも無ければ `scripts/` 配下。`demo`・`src/routes/stories`・先頭に `/* @refactor-ignore */` を持つファイルは除外する。
-- **スコープ拡張**: 起点ファイルから import グラフを双方向（import 元・import 先）に最大3段階たどり、新規0件で止める。拡張後のファイル集合を印字する。
-- **候補の集計**: プロジェクト自身の eslint に JSON で問い合わせ、次を件数と file:line で印字する — 行数・複雑度（`max-lines` / `max-lines-per-function` / `complexity` / `sonarjs/cognitive-complexity`）、型の安全性（`@typescript-eslint/no-explicit-any`）、名前空間エクスポート（`local/namespace-object-export`）、重複コード（`sonarjs/no-identical-functions`）、変数名の書式（`@typescript-eslint/naming-convention`）、重複文字列（`sonarjs/no-duplicate-string`）、マジックナンバー（`@typescript-eslint/no-magic-numbers`）、未使用コード（低優先度: `@typescript-eslint/no-unused-vars`）。件数は gate の eslint と同一なので `pnpm josh gate` と食い違わない。
-- **収束判定**: 高・中優先度の候補が0件なら `verdict: clear`、残っていれば `verdict: candidates`。これが「優先度高・中が0件」の判定である。低優先度（未使用コード）は報告のみで収束判定には数えない。
+- 対象ファイル: 作業ツリーの変更＋main との差分＋未追跡ファイル。いずれも無ければ `scripts/` 配下。`demo`・`src/routes/stories`・先頭に `/* @refactor-ignore */` を持つファイルは除外。
+- スコープ拡張: import グラフを双方向に最大3段階たどり、新規0件で止める。拡張後の集合を印字する。
+- **候補の集計**: eslint の件数と file:line — 行数・複雑度（`max-lines` / `max-lines-per-function` / `complexity` / `sonarjs/cognitive-complexity`）、型の安全性（`@typescript-eslint/no-explicit-any`）、名前空間エクスポート（`local/namespace-object-export`）、重複コード（`sonarjs/no-identical-functions`）、変数名の書式（`@typescript-eslint/naming-convention`）、重複文字列（`sonarjs/no-duplicate-string`）、マジックナンバー（`@typescript-eslint/no-magic-numbers`）、未使用コード（低優先度: `@typescript-eslint/no-unused-vars`）。件数は `pnpm josh gate` の eslint と同一。
+- 収束判定: 高・中優先度の候補が0件なら `verdict: clear`、残れば `verdict: candidates`。低優先度は報告のみで数えない。
 
-行数はコード行数であり物理行数ではない — `max-lines` / `max-lines-per-function` は `skipBlankLines` と `skipComments` を有効にして数えるので、`wc -l` ではなくこのコマンド（gate と同じ eslint）の報告で判断する。
+行数はコード行数（`max-lines` / `max-lines-per-function` は `skipBlankLines` と `skipComments` 有効）。`wc -l` ではなくこのコマンドの報告で判断する。
 
 ---
 
 ## コマンドが見ない、目視で残すもの
 
-`refactor:scan` は決定的に読める入力（lint と import グラフ）だけを扱う。次の2つは機械的に判定できないため、コマンドの結果に加えて必ず目視で確認する：
+次の2つは機械判定できないため、コマンドの結果に加えて必ず目視で確認する：
 
-- **副作用の冪等性**: intersection observer・イベントハンドラ・コールバックなど、一度だけ実行すべき副作用に、状態チェックによる早期 return のガード節があるか確認する。
-- **似た UI 構造**: 同じ UI パターン・振る舞いが複数箇所にあり、props で差を吸収する共通コンポーネントにまとめられないか確認する。
+- **副作用の冪等性**: 一度だけ実行すべき副作用（intersection observer・イベントハンドラ・コールバック）に、状態チェックで早期 return するガード節があるか。
+- **似た UI 構造**: 複数箇所の同じ UI パターンを、props で差を吸収する共通コンポーネントにまとめられないか。
 
 ---
 
 ## 「リファクタリングを提案して」の動作
 
-1. `pnpm josh refactor:scan` を実行して候補を網羅的に洗い出し、コマンドが見ない2項目（副作用の冪等性・似た UI 構造）を目視で補う
-2. 高・中優先度の候補 → すべて提案（件数制限なし）／すべて低優先度の場合のみ → 最大3つまで提案
-3. 提案のみ行い、実装はユーザーに委ねる
-4. コメント提案は不要。実装可能なサンプルコードを提供する
-5. このプロンプトの内容説明は不要。直接提案に移る
+1. `refactor:scan` で候補を洗い出し、目視2項目で補う
+2. 高・中優先度 → すべて提案（件数制限なし）／すべて低優先度なら最大3つ
+3. 実装はせず、コメントでなく実装可能なサンプルコードを示す
+4. このプロンプトの説明はせず、直接提案に移る
 
 ---
 
 ## 「リファクタリングして」の動作
 
-**対象範囲**は「対象ファイルの特定」と同一（変更しない）。
+対象範囲は「対象ファイル」と同一。
 
 ```text
-[対象の特定] `pnpm josh refactor:scan` が対象範囲を決める
-[テスト準備] 対象のふるまいを検証する unit/E2E テストを先に実装し、すべてグリーンを確認してから構造変更を始める
-[1回目]    refactor:scan の候補 + 目視2項目で網羅的分析 → 優先度高・中をすべて実施
+[テスト準備] 対象のふるまいを検証する unit/E2E テストを先に実装し、グリーンを確認してから構造変更を始める
+[1回目]    refactor:scan の候補 + 目視2項目 → 優先度高・中をすべて実施
 [2回目以降] refactor:scan を再実行 → 漏れがあれば実施
-[収束判定]  refactor:scan が `verdict: clear` を返す（優先度高・中が0件）
-[完了]     verdict: clear かつ目視2項目も0件 → 低優先度のみ報告して完了
+[完了]     `verdict: clear` かつ目視2項目も0件 → 低優先度のみ報告して完了
 ```
 
-- 優先度高・中が **0件になるまで**、同一セッション内で繰り返す（ユーザー再依頼不要）
-- 低優先度は自動実施せず、ユーザーへの報告のみ
-- 繰り返しのたびに「N回目の分析」「残り候補: X件」など進捗を簡潔に示す
-
----
+- 高・中が0件になるまで、ユーザーの再依頼なしに繰り返す
+- 低優先度は自動実施せず報告のみ
+- 毎回「N回目の分析」「残り候補: X件」と進捗を示す
 
 ## 部分的に lint が当たる項目（目視で補う）
 
-lint が完全に検出できる項目は `pnpm josh refactor:scan` が件数と file:line で報告する（上記「候補の集計」）。ここに挙げるのは、**規則が一部の面しか当たらず、残る面を人が判断する項目**だけである。コーディング規約・命名規則は `CLAUDE.md` を参照（規則の単一ソース。`AGENTS.md` / `GEMINI.md` はそこへの導線でしかない）。
+lint が一部の面しか見ない項目だけを挙げる。コーディング規約・命名規則は `CLAUDE.md` を参照。
 
 ### 高優先度
 
-- **責務の分離**: 再利用可能・独立した責任を持つ機能を別ファイルに分離する。`max-lines` は大きさだけを見るので、行数が収まっていても複数責任が混在していないかは目視で判断する。
-- **リテラル型の保持**: データ配列はリテラル型を保つために `as const satisfies T` を使っているか確認する（型注釈のみでは `string` に widen される）。`prefer-as-const` は別の場面の規則で、この判断は肩代わりしない。
+- **責務の分離**: 行数が収まっていても複数責任が混在していれば、再利用可能・独立した機能を別ファイルに分ける（`max-lines` は大きさだけを見る）。
+- **リテラル型の保持**: データ配列は `as const satisfies T` でリテラル型を保つ（型注釈のみでは `string` に widen される。`prefer-as-const` は肩代わりしない）。
 
 ### 中優先度
 
-- **変数名の意味**: `@typescript-eslint/naming-convention` は書式（snake_case など）だけを見る。意味が不明確な名前・実態と合わない名前は目視で見直す。
-- **類似コードの共通化**: `sonarjs/no-identical-functions` は完全一致だけを検出する。似ているが同一でないコードの共通化は目視で判断する。
+- **変数名の意味**: `@typescript-eslint/naming-convention` は書式だけを見る。意味が不明確・実態と合わない名前は見直す。
+- **類似コードの共通化**: `sonarjs/no-identical-functions` は完全一致だけを検出する。似ているが同一でないコードは目視で共通化を判断する。
 
 ### 低優先度
 
-- **不要コメントの整理**: 冗長・陳腐化したコメントを削除する。未使用の変数・関数は `@typescript-eslint/no-unused-vars` が検出し、`refactor:scan` が低優先度として報告する。
+- **不要コメントの整理**: 冗長・陳腐化したコメントを削除する。
 
 ---
 
 ## 基本方針
 
-- **構造変更の前にテストを書く**: リファクタリング実施前に、対象のふるまいを検証する unit/E2E テストを先に実装し、グリーンを確認する。デグレを防ぐための安全網として機能する
-- **可読性・保守性・パフォーマンス・AI コストは同列で、どれも悪化させない**（`prompts/collaboration-workflow/principles.md` → "quality-priority"）
+- 可読性・保守性・パフォーマンス・AI コストは同列で、どれも悪化させない（`prompts/collaboration-workflow/principles.md` → "quality-priority"）
 - コードクローンの排除・メソッド抽出・共通コンポーネント化は必ず分析・提案に含める
-- **提案しないパターン**: `async () => await fn()` → `() => fn()` への簡素化は行わない
-- 提案が特にない場合は、無理に提案しない
+- `async () => await fn()` → `() => fn()` の簡素化は提案しない
+- 提案が無ければ無理に提案しない
 
 ---
 
 ## 提案の形式
 
-各提案: **優先度** / **問題点** / **改善案と効果** / **サンプルコード**（プロジェクト規約準拠、lint エラーなし）/ **影響ファイル**
+各提案: 優先度 / 問題点 / 改善案と効果 / サンプルコード（プロジェクト規約準拠、lint エラーなし）/ 影響ファイル
 
 ## 実装後の品質保証（絶対遵守）
 
-実装後は `read_lints` → `pnpm run lint` の順で全関与ファイルを確認し、エラーが0件になるまで修正する。エラーが残った状態での完了報告は禁止。
+実装後は `read_lints` → `pnpm run lint` の順で全関与ファイルを確認し、エラー0件になるまで修正する。エラーが残ったまま完了報告しない。