improve

# improve — 強いモデルで監査し、安いモデルで実行する `improve` は、任意のコードベースを監査し、他のエージェントが実行するための実装計画を書くエージェントスキル（Agent Skills 形式）です。前提はシンプルです。最も高性能なモデルは、知性が複利で効く部分——コードベースの理解、やる価値の判断、仕様の作成——に使い、実行はより安価なモデルに任せます。このスキル自体は何も実装しません。計画が成果物です。 you → /improve (高価なモデル、助言) plans/ → 001-fix-n-plus-one.md (自己完結した仕様) other agent → 実装・テスト・出荷 (安価なモデル、実行) ## インストール npx skills add shadcn/improve Agent Skills 形式に対応したエージェントであれば、どれでも動作します。計画はプレーンなマークダウンなので、どのエージェントでも人間でも扱えます。 ## コマンド - `/improve` — 完全監査 → 優先順位付けされた所見 → 計画 - `/improve quick` — 低コストなパス: ホットスポットと主要な所見のみ - `/improve deep` — 網羅的: すべてのパッケージ、すべてのカテゴリ - `/improve security` — 対象を絞った監査（perf、tests、bugs なども同様） - `/improve branch` — 現在のブランチが変更した部分だけを監査 - `/improve next` — 機能提案、プロジェクトを次にどこへ進めるか - `/improve plan (説明)` — 監査をスキップして、1件だけ仕様化する - `/improve review-plan (ファイル)` — 既存の計画を批評し、引き締める - `/improve execute (計画)` — より安価な実行役を派遣し、その作業をレビューする - `/improve reconcile` — バックログを更新: 検証、ブロック解除、退役 - `--issues` — 計画を GitHub イシューとしても公開する ## 最初の実行例 1. リポジトリでエージェントを開き、`/improve` を実行します（安く済ませたい場合は `/improve quick`）。 2. リポジトリをマップし、監査し、所見の表を返します。計画化したいものを選んで返信します。例: 「1、3、5 を計画して」。 3. 計画は `plans/` に置かれます。1件につき1ファイル、推奨順のインデックス付きです。これらはレビューされることを想定しています。 4. 計画を任意のエージェントに渡すか（「implement plans/001-*.md」）、スキルに実行させます: `/improve execute 001` は、隔離されたワークツリーでより安価なモデルを起動し、計画に対して diff をレビューし、判定を報告します。マージはあなたの判断に委ねられます。 5. 次回のセッションでは `/improve reconcile` でバックログを整理します。実際に反映されたものを検証し、ズレたものを更新し、詰まったものをブロック解除します。 PR の前には、`/improve branch` で同じプロセスをブランチの変更範囲だけに絞ります。 ## 仕組み - **偵察（Recon）**. リポジトリをマップします。スタック、規約、正確な build/test/lint コマンドを把握し、それらはすべての計画の検証ゲートになります。意図や設計のドキュメントがあれば取り込みます（`docs/adr/` の ADR、PRD、`CONTEXT.md`、`DESIGN.md`、`PRODUCT.md`）。これにより、決定済みのトレードオフを再び指摘せず、方向性の提案は明示されたプロダクト意図に基づき、計画はリポジトリ自身の語彙を使います。 - **監査（Audit）**. 9つのカテゴリに並列サブエージェントを展開します: 正確性、セキュリティ、パフォーマンス、テストカバレッジ、技術負債、依存関係と移行、DX、ドキュメント、方向性（機能提案はリポジトリ自身からのエビデンスを引用する必要があります）。すべての所見には `file:line` のエビデンス、影響度、工数、信頼度が付きます。 - **精査（Vet）**. サブエージェントは過剰報告するため、アドバイザーは何かを示す前に引用されたすべての箇所を再読します。誤検知は除外し、誤った帰属は修正し、却下理由は記録します。 - **優先順位付け（Prioritize）**. 所見はレバレッジ（影響度÷工数、信頼度で重み付け）順の表になります。何を計画にするかはあなたが選びます。 - **計画（Plan）**. 選択された所見ごとに `plans/` に1ファイル作成します。インデックス、優先順位、依存関係グラフ付きです。 ## 計画を実行可能にするもの 計画は、最も弱いと想定される実行役——アドバイザーのセッションを見たことがなく、はるかに小さいかもしれないモデル——を対象としています。それを支える3つの特性: - **自己完結**. すべての文脈がインライン化されています: 正確なファイルパス、現状のコード抜粋、リポジトリ規約と事例ファイル、検証済みコマンド。「前述のとおり」はありません。 - **検証ゲート**. すべてのステップはコマンドと期待出力で終わります。完了条件は機械で確認できるため、実行役が成功を判断する必要がありません。 - **明確な境界**. 明示的な対象外リストと STOP 条件（「X なら停止して報告」）を置き、現実が計画と一致しないときに小さなモデルが即興で対応するのを防ぎます。 各計画は、それを作成した git コミットを記録しているため、実行役は何かに触れる前に機械的なドリフトチェックを実行できます。 ## ループを閉じる - **`execute (計画)`** は、隔離された git ワークツリーで安価な実行役サブエージェントを起動し、計画を渡し、テックリードのように結果をレビューします。すべての完了条件を再実行し、スコープ遵守を確認し、意図に照らして diff を読みます。判定: 承認（マージはあなたの判断）、修正を返送（最大2ラウンド）、またはブロックして計画を改善。 - **`reconcile`** はその後の変化を処理します。DONE になった計画が今も成立するか検証し、BLOCKED の計画を調査して障害を回避する形に書き直し、ズレた計画を更新し、独立に修正済みの所見を退役させます。 - **`--issues`** は計画を同じ自己完結ボディの GitHub イシューとして公開します。作業がすでに存在する場所で、どのエージェントでも人間でも拾えます。 ## 厳格なルール - ソースコード自体を変更しない。書き込みは `plans/` だけ。実行役は使い捨てワークツリー内でのみ編集し、マージは常にあなたの判断。 - ワーキングツリーを変更するコマンドを実行しない。読み取り、検索、読み取り専用の分析のみ。 - 秘密の値を再現しない。場所と資格情報の種類のみ。ローテーションを常に推奨。 - 実装を頼まれても断り、計画を指し示す（または `execute` を提案する）。 ## ライセンス MIT © shadcn