実装とリリースClaude Code and agents that support the skills CLI
Matt Pocock / improve-codebase-architecture
エージェントはアーキテクチャの痛点を指摘できるか
候補は出せます。どれが重要かの判断は依然として人間側です。
押さえておく点
- 先にレポート、後で変更。この順序が安全に実行できる理由です。
- サブシステムに絞ってください。全体レポートは行動に移すには大きすぎます。
- 指摘は候補であって判定ではありません。チームだけが知る事情で間違っているものもあります。
- 根拠を検証したいときは grill-me と組み合わせます。
01実務で何が変わるか
アーキテクチャの改善は技術的というより社会的な理由で止まります。どこから始めるか合意できず、結果として何も始まりません。理由付きの具体的な候補一覧は、その議論を意思決定に変えます。
レポート形式は、エージェントができる最も危険なこと、つまり目の前で複数モジュールを同時に書き換える行為も防ぎます。
02期待に届かない点
見ているのはコードであって経緯ではありません。不格好な境界の一部は、どこにも書かれていない制約のために存在しており、スキルは自信をもって撤去を提案します。
長いレポートは範囲の膨張も招きます。候補を 1 つに絞る規律は完全に人間側の仕事です。
導入と最初の実行
- mattpocock/skills から skills CLI 経由で MIT ライセンスで導入します。
- リポジトリ全体ではなく 1 領域に対して実行し、レポートをレビュー可能な量に保ちます。
- 候補を 1 つか 2 つ選びます。30 件の一覧は、何も選ばないための方法です。
実際によくある質問
- コードを自動で書き換えますか
- まずレポートを出し、選ばれた候補だけを掘り下げます。見つけ次第の書き換えはしません。
- どのくらいの規模まで扱えますか
- サブシステム単位に絞ってください。リポジトリ全体のレポートは扱いきれないことが多いです。
- 誰が保守していますか
- Matt Pocock が公開する skills リポジトリで、ライセンスは MIT です。
出典
このページの機械可読版