From ai-dev-harness
エンジニアの技術選定・比較調査を、要件の言語化から根拠ある推奨まで導くスキル。Claude Code 環境での利用を前提とし、各候補の調査をサブエージェント(candidate-researcher)に委譲して本線のコンテキストを汚さず進め、公式ドキュメント等の原文引用つき図解HTMLレポートにまとめる。生成後の「なぜ/もっと調べて」は該当候補の深掘りに、「修正したい」は report-revision に振り分ける。ライブラリ・フレームワーク・クラウドサービス・DB・認証方式・アーキテクチャパターンなどの選定に使う。「技術選定」「ライブラリ比較」「どれを採用すべき」「AとBどっちがいい」「〜の選び方」といった語が出たとき、また明示的に「比較して」と言われなくても複数の技術的選択肢から1つを選ぶ判断が絡む相談では必ずこのスキルを使うこと。
How this skill is triggered — by the user, by Claude, or both
Slash command
/ai-dev-harness:tech-selection-researchThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
技術選定は「情報を集める」作業ではなく「判断可能な形に情報を整理する」作業である。**Claude Code での実行を前提**とし、本線(オーケストレーター)は段取りと統合に徹し、重い調査はサブエージェントへ委譲して本線コンテキストを汚さない。
技術選定は「情報を集める」作業ではなく「判断可能な形に情報を整理する」作業である。Claude Code での実行を前提とし、本線(オーケストレーター)は段取りと統合に徹し、重い調査はサブエージェントへ委譲して本線コンテキストを汚さない。
関連スキル/エージェント:
./agents/candidate-researcher.md)assets/render.py)何のための選定かを言語化する。要件が出ていなければ先に確認する:目的、制約(性能・スケール・予算・既存スタック・習熟度・運用・法規制)、must と want の区別、時間軸。要件が曖昧なまま候補調査に進まない。
must 条件で足切りし 2〜4 個に絞る。何を残し何を落としたかを記録する。
既定軸を土台に案件へ合わせ、must 由来の軸に重み(◎/○/△)を付ける。既定軸:機能適合性 / 性能 / コスト(初期・運用) / 学習コスト・開発体験 / エコシステム / 保守性・将来性 / ライセンス / セキュリティ。
候補ごとに candidate-researcher を Task で起動する。本線の全文脈は渡さない。 渡すのは:候補名 / 評価軸(重み) / must・want / JSON断片の出力パス。各サブエージェントは独立コンテキストで一次情報を原文引用しながら裏取りし、findings 用のJSON断片(主張+原文引用+バッジ+任意のscores)を書き出し、本線には要約だけを返す。独立候補は並列、相互依存があれば逐次。
各サブエージェントが書いた断片を集約し、research-writeup の data.json を組み立てる:
findings = 各候補の断片を連結comparison = 各断片の主要所見から要点表を作成(セルに inline 出典URL)positioning(任意)= scores がそろった2軸があれば設定
生の検索結果は本線に貼らない。詳細が要る候補は、その断片/HTMLを参照する。候補間の「何を取ると何を諦めるか」を言語化。must を落とす候補は理由を添えて除外。
data.json を作り、assets/render.py で生成する。原文引用(非日本語は日本語訳併記)は解説の直後にインライン表示され、末尾一括にはしない。事実と解釈は視覚分離。レーダーチャートは使わない。ファイルは調査ごとに新規作成。
生成後のレポートに対する依頼を次に振り分ける。
items を既存 findings にマージし、render.py で再生成する。複数箇所なら候補ごとに分けて委譲する。各サブエージェントは独立コンテキストを持ち、本線には要約とJSON断片だけを返す。調査の中間情報がサブエージェント側に閉じるため、複数候補を調べても・深掘りを重ねても本線は判断に必要な情報だけで保たれる。
npx claudepluginhub otomatty/ai-dev-harness --plugin ai-dev-harnessGuides collaborative design exploration before implementation: explores context, asks clarifying questions, proposes approaches, and writes a design doc for user approval.
Creates structured, bite-sized implementation plans from specs or requirements before writing code. Useful for breaking down multi-step tasks into testable steps with file structure and task boundaries.
Synthesizes the current conversation into a structured spec (PRD) and publishes it to the project issue tracker with a ready-for-agent label, without interviewing the user.