propose-tech-updates

今いるリポジトリに実際に役立つ改善だけを提案します。「新しいものの紹介」ではなく、このコードベースのどこがどう変わるかまで書けたものだけを出します。

依存の更新だけを見るスキルではありません。 提案の多くは、外の新しさではなく内側の課題から出てきます。

該当が無ければ「今回は無し」と答えて終わります。 無理に絞り出すと、本当に役立つ提案が埋もれます。

進め方

1. 現状を読む（推測で書かない）

バージョンも件数も、必ず実物から取る。 記憶にある値は古くなっています。

gh repo view --json name -q .name        # どのリポジトリにいるか
cat package.json                          # 依存とスクリプト
ls apps packages 2>/dev/null              # モノレポなら構成

見るもの	なぜ
各 package.json の依存	提案の可否がここで決まる
ビルド・テスト・lint の設定	何をどう検査しているか
CI のワークフロー	どの検査が CI に入っていて、何が入っていないか
規約ドキュメント	`docs/` や `CLAUDE.md`。技術方針が書かれていることがある
既存の Issue / PR	`gh issue list --state all` / `gh pr list --state all`

規約に反する提案をしない。 「このアプリではキャッシュライブラリを使わない」のような方針があれば、それに反する提案は最初から候補外です。

2. 4つの観点を並列で調べる

調べ方は mattpocock-skills の research に従う（公式のドキュメント・ソース・仕様に当たり、主張ごとに出典を添える）。research はメモをリポジトリへ書き出すが、ここでは書き出さず、出典は各観点の結果に添える。

引数で観点が指定されていればそれだけを、無ければ全部を見ます。

surveyor を使えるなら、観点ごとに1つずつ起動して並列に走らせる。 読む量が多く結論が短い作業なので、直列だと待ち時間が積み上がります。使えない環境では自分で順に見ます。

他のサブエージェントは自律起動しない。 surveyor だけが探し方とコマンドと件数を返す契約を持っており、返ってきた結論を検算できます。検算できない相手に投げると、出てきたものを信じるしかなくなります。

観点	引数	何を探すか
依存	`deps`	破壊的変更・非推奨化・使っていない新機能
CI	`ci`	所要時間・失敗の傾向・検査されていない領域
記法	`style`	同じ目的を達する複数の書き方・規約と実態の乖離
テスト	`test`	検証されていない分岐・壊れやすいテスト・実行時間

依存を調べる

一次情報を優先し、二次記事は裏取りにだけ使います。

情報源	引き方
GitHub Releases	`gh release list --repo <owner>/<repo> --limit 10`
リリースの本文	`gh api repos/<owner>/<repo>/releases/tags/<tag> --jq .body`
Issue / Discussion / RFC	破壊的変更はリリースノートより先にここで議論される
公式ドキュメント・移行ガイド	`/context7-mcp`。ライブラリ名から最新の文書を引く
公式ブログ・リリースのページ	`/ax` で開く。本文が描画を待つページは、`verify_the_check_worked.md` の手順で Playwright から読む
補助	`WebSearch`。気になった話題の裏を取る

「メジャーが上がれば速くなる」と思い込まない。 性能改善が入っているかは、リリースノートを perf / faster / speed で引いて確かめます。謳われていないなら速くなりません。

調べる先は手順1で読んだ依存から決める。 使っていないものを調べても意味がありません。

CI を調べる

履歴は実データで引けます。 体感ではなく数字で見ます。

gh run list --workflow "<name>" --limit 20 --json databaseId,conclusion,createdAt,updatedAt

見るもの	何が分かるか
所要時間の分布	どのワークフローが律速か。平均ではなく最遅を見る
失敗の傾向	同じジョブが繰り返し落ちていないか。不安定なテストが無いか
検査の穴	ローカルで走るのに CI に無いもの。その逆も
キャッシュが当たっているか	`Cached: N cached` が出ているか

記法を調べる

同じ目的を達する書き方が複数あると、次に書く人が迷います。

探すもの	例
同義の別表記	同じ処理に2つの名前・2つの書き方が併存している
規約と実態の乖離	規約に書いてあるのに守られていない。逆に、実態が規約より進んでいる
lint で拾えるのに拾っていない	手で直している違反が、ルール1行で防げないか

件数を数えてから提案する。 1箇所だけなら規約にする価値はありません。

テストを調べる

見るもの	何が分かるか
実行時間の内訳	セットアップと本体のどちらが重いか
落ちやすいテスト	CI の履歴で繰り返し落ちているもの
検証の薄い領域	分岐はあるがテストが無いところ

3. 測る（速さを提案するなら必須）

「遅い」「速くなる」は測らずに書かない。

測るもの	どう測るか
CI	`gh run list` の `createdAt` と `updatedAt` の差。3件以上の平均
手元のビルド・テスト	実際に走らせる。キャッシュを捨てて3回、平均を取る

改善案を出すなら、前後を比べる（ base_records_on_measurements.md の「改善を主張するなら、前と後を並べる」）。

4. 3つの型に当てはまるものだけを残す

型	中身
1. 活かせていない	今あるもの（ライブラリ・ツール・設定）に、使っていない機能がある
2. 先回りできる	破壊的変更・非推奨化が来ている。今なら安く対応できる
3. 課題を解く	手順2で見つけた実際の課題を、別の選択肢が解く

主な対象は3番目です。 手順2で課題を見つけていないなら、この型の提案は出せません。

5. 落とすもの

規約・技術方針に反するもの
実際に困っていない問題への対処
既に Issue や PR になっているもの
流行っているだけで、このリポジトリでは役に立たないもの
測っていない速度の主張

6. 出す

1提案につき、次の4点を書く。 どれか1つでも書けないなら、その提案は落とします。

項目	中身
何が問題か / 何が変わったか	課題なら実測値、更新なら一次情報へのリンク
どこに影響するか	ファイルパスと現在の値を実際に読んで書く
コスト	入れる場合の作業量。入れない場合に何が起きるか
推奨	入れる / 見送る / 様子を見ると、その理由

3件を超えて出さない。 多いと読まれません。

最後に調べた範囲（観点ごとに見た情報源と本数）と、提案しなかった理由を簡潔に添えます。何を見ていないかが分かると、次に自分で調べる場所が決まります。

出力の目安

該当なし: 観点ごとに1行 + 調べた範囲。3〜5行
該当あり: 1提案につき表1つか5行程度。3件まで
Issue にするかはユーザーが決める。勝手に作らない

やってはいけないこと

依存の更新だけを見て終えること。提案の多くは内側の課題から出る
バージョンや件数を記憶で書くこと。必ず実物を読む
測らずに速度を語ること。「速くなるはず」は提案ではない
メジャー更新を性能改善と思い込むこと。リリースノートで確かめる
規約ドキュメントを読まずに提案すること
既存の Issue / PR を確認せずに出すこと。同じ提案が毎回積み上がる
無理に提案を作ること。該当が無ければ「無し」でよい
3件を超えて出すこと
Issue や PR を勝手に作ること。提案までが責務
コードを変更すること。検証のための一時的な変更も、必ず元へ戻す