tool-fit-for-projects

プロジェクトに適したツール

勝者ではなく、適合性を見つけます。

現在のリポジトリと現時点の根拠に基づき、読み取り専用で作業してください。外部ツールを、現在のベースライン（既存のツール、ローカル実装、手作業、または意図的にツールを使わないこと）と比較します。変更しないという結果も、成功です。

英語での出力

英語の文章を作成または修正する前に、インストール済みの simple-english スキルを使用してください。スキル名で読み込むか、SKILL.md と該当するリファレンスを読んでください。 このコンテキストですでに読み込まれている指示は再利用してください。 この規約を読んだら、英語で進捗報告、草稿、最終回答を送る前に、依存関係を読み込んでください。

スタイル規則と衝突する場合は、意味、不確実性、要件の強さ、専門用語、およびタスクで指定された形式を維持してください。指定された言語を使ってください。 コード、識別子、コマンド、原文の引用、過去の根拠を維持してください。

必要な指示を利用できない場合は、不足していることを一度だけ報告し、独立して行える作業を続けてください。影響を受ける英語の出力は、依存関係が利用可能になるか、ユーザーが例外を明示的に許可するまで草稿として扱ってください。依存関係を自動でインストールしたり、確認していない草稿が要件を満たしていると主張したりしないでください。

モードを1つ選択

ツールの選定

ユーザーがニーズ、判断、現在のツール、または候補のシードを指定した場合は、このモードを使用してください。判断のワークフローを完了し、ツール選択チェックポイントで終了してください。

リポジトリのツール監査

ユーザーがリポジトリを調べ、ツール導入の機会を探すよう求めた場合に限り、このモードを使用してください。広範囲にスキャンし、重要なツール導入の機会を最大5件まで報告して終了してください。本格的なツール選定に進む前に、ユーザーに機会を選んでもらいます。

完了条件： 実行モードがちょうど1つであること。監査が候補の調査へ暗黙のうちに拡大していないこと。

ツール選定ワークフロー

1. 判断の枠組みを定める

ツール選定のコンテキストを明らかにしてください。

• 改善対象となる具体的なリポジトリ作業
• 影響を受けるユーザー
• 望ましい結果と、観測可能な成功条件
• 既知の技術面、組織面、予算面、セキュリティ面、データ面、時間面の制約

リポジトリと現在の情報源から事実を確認してください。ユーザーが定める制約の不足が候補の適格性や結果を大きく左右する場合に限り、焦点を絞った質問を1つしてください。リポジトリの根拠にアクセスできない場合は、その制約を明示し、一般的な製品比較を行うのではなく、必要最小限のプロジェクト情報を得てください。

判断の深度を分類してください。

• クイック — ローカルで元に戻せる、コードと責任範囲が限定的な変更で、永続データや外部サービスに影響しない
• 標準 — ワークフロー、複数のモジュール、または重要な互換性の範囲に影響する
• 高リスク — アーキテクチャ、永続データ、ID、セキュリティ、インフラ、デプロイ、または重要な外部サービスを変更する

完了条件： 判断が抽象的な製品ではなく、リポジトリ上の作業を対象としており、その深度が観測可能な変更範囲と可逆性に合っていること。

2. ベースラインを確立する

リポジトリが現在その作業をどう処理しているか、何がうまく機能しているか、観測可能な問題やリスク、現状維持のコストを説明してください。実行可能な場合は、自前で実装する方法や、ツールを使わない方法も含めてください。

重大な問題がない場合、または妥当な調査と導入のコストが得られるメリットをすでに上回っている場合は、外部ツールを調べる前に、変更しないという結果を示してください。代替案を捏造せず、根拠を示してください。

完了条件： すべての外部候補を具体的な現在のベースラインと比較でき、変更しない選択肢も引き続き有効であること。

3. カテゴリプロファイルを選択する

判断に伴う重要なリスクをカバーする、最小限のプロファイルを読みます。

• コードおよび開発者向けツール — フレームワーク、ライブラリ、ランタイム、ビルド、テスト、リンティング、フォーマット、コード生成、および開発者のワークフロー向けツール。
• データおよびインフラストラクチャ — データベース、キャッシュ、キュー、検索、ストレージ、およびステートフルなインフラストラクチャ。
• クラウドおよびデプロイ — コンピューティング、ホスティング、デプロイプラットフォーム、ネットワーク、およびマネージドクラウドサービス。
• ホスティング型サービスおよび商用サービス — 外部の SaaS、API、ID プロバイダー、可観測性製品、およびその他のベンダー運営サービス。

候補によっては、複数のプロファイルが必要になる場合があります。カテゴリが隣接しているという理由だけで、プロファイルを読み込まないでください。

完了条件： 重要な Candidate Gate と比較上の懸念事項が、すべて読み込んだプロファイルに含まれていること。

4. 根拠を収集する

複数の候補に関する問いを個別に調査できる場合は、候補の根拠割り当てを使用します。まず、現在のベースライン、ゲート、比較に関する問いを確定します。比較と推奨はメインの担当者が行います。単純な判断や密接に関連する判断は、インラインで扱います。

ツールの根拠に関する優先順位に従います。

1. リポジトリのコード、マニフェスト、設定、履歴、イシュー、および既存の読み取り専用検証。
2. 最新の公式ドキュメント、ソース、サポートマトリックス、リリースおよび非推奨化の告知、セキュリティ勧告、ライセンス、料金、サービス条件。
3. 最初の 2 つのレベルでは立証できない主張について、再現可能な独立ベンチマーク、下流のイシュー、信頼できる採用実績。

重要な主張はすべて根拠をたどれるようにします。検証済みの事実、リポジトリ固有の推論、ユーザーの制約、未確認事項を区別します。人気、スター数、ダウンロード数、機能数は、適合性の証明ではなく、候補を見つけるための手掛かりとして扱います。

読み取り専用検証では、依存関係、ソース、設定、サービスの変更を伴わない既存のテスト、ベンチマーク、診断コマンドを実行できます。新たな試行を計画し、実行はしないでください。

完了条件： すべての Candidate Gate に必要な根拠が検証済みであるか、ユーザーが所有しているか、未解決事項として明示されていること。

5. 飽和するまで候補を探す

ユーザーが名前を挙げたツールはすべて候補の種として扱い、検索の境界や、最終候補に選ばれる保証とは見なさないでください。ベースラインを維持する、シンプルにする、組み込み機能を使う、範囲を限定して自作する、外部ツールを導入するといった、独立したさまざまな解決方法を探します。

Evidence Saturation に達したら探索を終了します。つまり、独立した探索経路を追加しても、要件を満たす候補に実質的な違いが生じなくなった時点です。詳細な Tool Candidate Card を作成する最終候補は、最大 5 件にします。ユーザーが挙げた種は、最終候補にならない場合も含め、すべて判断結果と理由を明示します。

完了条件： 報告書で、調査した経路、終了条件、最終候補の範囲、およびユーザーが挙げた各種の判断結果を示せること。

6. ゲートを適用してから比較する

比較の前に、読み込んだプロファイルの候補ゲートを適用します。必須ゲートに不合格の場合、機能、人気、その他の利点で補うことはできません。

合格した候補、または解決可能な不明点がある候補について、次の項目を定性的に比較します。

• リポジトリの作業と成功条件に対する利点；
• 将来のユーザーやメンテナーがツールの目的を把握し、適切な利用方法を見つけるための発見コスト。エージェントの検索時間ではありません；
• 学習、価格、導入、統合、拡張、移行、保守のコスト；
• カテゴリー固有の運用上およびライフサイクル上のリスク；
• 段階的な適合性：範囲を限定した導入、共存、任意の機能拡張、移行の中間段階、ロールバック、終了。

合計スコアは算出しません。ツール候補の処遇を、次のうち必ず1つ割り当てます。

• 推奨 — ゲートに合格し、根拠が第一候補を支持しています；
• 有力な代替候補 — ゲートに合格し、異なるトレードオフがユーザーに適している可能性があります；
• 試行 — 重要な適合性の主張を検証するため、低コストのリポジトリ実験が必要です；
• 根拠が必要 — 不足している事実、またはユーザーが決定すべき制約により、判断できません；
• 却下 — ゲートに不合格であるか、コストやリスクが利点を上回ります。

完了条件： 最終候補とユーザーが挙げた候補のすべてに、根拠に基づく処遇が割り当てられ、推奨は現状のベースラインとの相対的なものになっています。

7. 段階的な導入経路を設計する

推奨または試行とした候補ごとに、段階的な導入経路を設計します。

1. 残っている確認事項のうち、最も低コストで確認できるもの；
2. 隔離された、元に戻せる試行；
3. 共存または移行のチェックポイント；
4. 合格と判断する観察結果、および候補を打ち切るか見直すシグナル；
5. ロールバック、該当する場合はデータの復旧、および終了経路。

経路を説明してください。インストール、プロトタイプ作成、移行、購入、サービスの変更は行わないでください。有力な代替候補については、ユーザーが後から選択しない限り、導入に関する重要な違いだけを示します。

完了条件： 第一候補は、取り消せない決定をする前に試行し、断念できます。

リポジトリのツール監査

リポジトリ全体を調べ、外部ツールまたは組み込みツールによって実質的に改善できる、観察可能な問題、リスク、重複する機能、保守負担がないか確認します。より新しい、または人気のあるツールが存在すること自体は、機会ではありません。

問題の深刻度、見込まれる利点、変更コスト、根拠の確かさに基づいて優先順位を付け、機会カードを最大5件提示します。各カードには次を含めます。

• リポジトリの根拠と影響を受ける範囲；
• 現状のベースライン；
• 改善に関する仮説；
• 想定されるツールカテゴリーのプロファイルと判断の深さ；
• ツールの判断を全面的に行う価値がある理由。

監査の対象範囲と終了条件を明示します。最後はツール選択チェックポイントで締めくくり、ユーザーが機会を1つ選ぶ、より範囲を絞った監査を依頼する、または終了することを選べるようにします。監査中に候補となるツールのエコシステムを調べてはいけません。

完了条件： 報告するすべての機会が、リポジトリの実質的な状況に基づいており、ユーザーの選択なしに全面的な選定を開始していません。

ツール選定レポート

結論を先に示します。構成を一定に保ち、詳細度は意思決定の深さに応じて調整します。

1. 意思決定の背景 — リポジトリの役割、ユーザー、成功条件、制約、意思決定の深さ。
2. 現在のベースライン — 現在の価値、課題、維持コスト、ツールを使わない場合や独自実装する場合の選択肢。
3. 検索範囲 — 候補の種、確認した経路、証拠の飽和度、情報源、証拠の境界。
4. 選定結果一覧 — ユーザーが挙げた候補と最終候補のすべてについて、ツール候補の判定と一行の理由。
5. 候補カード — 最大5件。リポジトリの証拠、ゲート、メリット、総コスト、カテゴリ固有のリスク、段階的な適合性、不確実性を記載します。
6. 推奨事項と選択肢 — 最有力の推奨、実行可能な代替案、該当する場合は変更なしという結論、重要なトレードオフ。
7. 段階的な導入経路 — 推奨候補と試用候補の全経路。
8. ツール選択の確認 — 候補の選択、ベースラインの維持、対象を絞った証拠確認の質問を1つ許可すること、または中止をユーザーに促します。

同じ契約を数段落で説明できる場合は、Quickの意思決定を簡潔にまとめます。重大な意思決定では、ゲート、不確実性、運用リスク、終了条件を詳しく説明します。ユーザーから明示的な保存の依頼がない限り、レポートは会話内に留めます。選択しても、実装が許可されたことにはなりません。

この視点の由来

この独立した非公式のスキルでは、リポジトリのツール選定に Anthony Fu のコストバランスと段階的な導入経路の視点を適用します。Antfu は、ツールの学習・使用コストと自分で作業するコストを比較し、段階的なオンボーディング、統合、機能、互換性を損なう変更を、複雑さを取り入れやすくする階段として説明しています。リポジトリの監査、候補の発見、カテゴリのゲート、選定結果、レポートの契約は、独立した拡張です。Antfu の公式トーク一覧と発表者ノート付きのスライドソースを参照してください。