新しいソフトウェア/デジタルプロダクトのコンセプトを対話で固め、競合・類似プロダクトを並列調査し、軽量な仕様ドラフトを作るオーケストレーションスキル。/product-spec <一言のプロダクトアイデア> で明示的に呼び出されたときのみ使用する。
インストールする前に、エージェントに与えられる指示の中身を確認できます。
フローは 4 段階: 1. コンセプト固め(grilling)→ 2. 競合・類似プロダクト調査(product-researcher を並列起動)→ 3. 中間確認 → 4. 仕様ドラフト作成。 対象はソフトウェア/デジタルプロダクト(SaaS・アプリ・CLI・API等)に限定する。仕様の実装(コード作成)はこのスキルの範囲外。
/product-spec <一言のプロダクトアイデア> の形で呼び出される想定(引数必須)。引数なしで呼ばれた場合は、まずどんなプロダクトを考えているか一言をユーザーに求めてから 1. に進む。
grilling スキルを呼び出し、渡された一言アイデアを起点に対話でコンセプトの芯を固める。呼び出し時の brief には、少なくとも以下のトピックを必ずカバーすることを明記する:
grilling の対話でユーザーとの合意に達するまで次工程には進まない。合意した内容をメインセッションが「コンセプト要約」として簡潔にまとめ、2. 以降に引き継ぐ(grilling 自体はドキュメントを生成しないため、要約は都度メインセッションが作成する)。
コンセプト要約をもとに、以下の調査角度それぞれについて product-researcher agent を 1 メッセージ内で同時に起動する(直列にしない):
コンセプトの性質上、上記 3 角度だけでは不十分だと判断した場合(例: 規制・法域固有の事情、特定業界の商習慣など)は、角度を追加して agent を増やしてよい。
各 agent の prompt には必ず以下を含める:
調査角度: <角度>
コンセプト要約: <ターゲットユーザー・課題・なぜ今・現状の代替手段・差別化仮説をまとめたもの>
コンセプト要約は全 agent に同一内容で渡す。agent はテキストで結果を返すのみで、ファイルには書かない。全 agent 完了後、メインセッションが結果を 1 つに統合する(重複して見つかった同一プロダクトは 1 件にまとめる)。
統合した調査結果(見つかった競合・類似プロダクトの一覧、重複度、差別化ポイントの所見)をユーザーに提示し、次のいずれに進むかを確認する:
ユーザーの明示的な承認なしに 4. へは進まない。 競合が見つからなかった場合も、その旨を報告した上で必ず一度確認を挟む。
メインセッションが直接、以下のテンプレートで軽量ワンページの仕様ドラフトを作成する。実装詳細(モジュール構成・API契約等)には踏み込まない。
<spec-template>誰の / 何の課題を / なぜ今、を 2〜3 文で。
調査角度ごとの発見を統合した一覧。プロダクト名・何をするか・重複度(高/中/低)。
競合調査を踏まえて、なぜこのプロダクトが成立するか。
コンセプト固めで合意した内容。
含むもの / 含まないもの、の 2 リスト。
仕様として詰め切れていない点、検証が必要な仮説。
</spec-template>保存先は対象プロジェクトの docs/product-spec-<slug>.md。<slug> はプロダクト名を kebab-case にしたもの。対象がリポジトリでない場合や docs/ の配置規約が不明な場合は、保存先をユーザーに確認してから書く。
書いた後は、その場でユーザーと内容を調整する(ファイルを再度開き直す操作はしない)。
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Claude Code の並列エージェント(agent teams・teammate)の後始末と無応答時の打ち切りルール。`name` を付けて Agent を起動するとき、TeamCreate でチームを組むとき、teammate から `idle_notification` が届いたとき、評価ループ等で次のイテレーションのエージェントを起動する前、エージェントの返信が届かないときに参照する。`name` を付けない通常のサブエージェント起動だけなら対象外。
spec.md の REQ-# を入力に、機能一覧・モジュール構成・インターフェース・データフローを持つ docs/dev/<対象>/basic-design.md を作成・改訂するスキル。/basic-design <対象名> で明示的に呼び出されたときのみ使用する。
技術的な内容を、技術用語を排したビジネス職向けの平易な説明文に翻訳する。`/biz-translate` と明示的に呼ばれたときのみ実行する。
`git commit` / `git commit --amend` を実行する前、または「commit」「amend」「コミット」「コミットして」の一語・短文だけを渡された時点で必ず発火する git コミット実施ルール。理由や差分の説明が一切無くても、ファイル全文を読んでメッセージを組み立てる前に先に参照する。主目的は論理的に独立した修正を都度・適切な粒度でコミットすること。メッセージは Conventional Commits 形式、素材は同梱の決定論スクリプト commit-context.sh が出す staged diff のみ。「コミット分けて」と依頼される、独立した複数修正をまとめるか分けるか判断する、レビューコメント対応をコミットする、rebase / squash / cherry-pick 後のメッセージを整える、`gh pr create` の PR タイトルをコミット流儀へ揃える場面でも参照する。plan モードでのコミット計画の立案は commit-plan スキルの領分。
実装計画・リファクタリング計画・レビュー対応計画・並列作業のタスク分解など、計画を成果物として書き出すときに必ず参照するコミット計画ルール。plan モードでは ExitPlanMode で plan を提示する前に必須、計画ドキュメントや job-graph のタスク分解・エージェントへの指示文でも同様に適用する。計画成果物にコミット計画セクション（論理的に独立した修正単位での分割と Conventional Commits 形式のメッセージ）が無ければ実装に入らない。「実装計画を立てて」「planを立てて」「実行計画を作って」「リファクタリング計画を立てて」「コミット計画を立てて」「タスクを分解して」と依頼される、複数の独立した修正をまとめるか分けるか計画段階で判断する等の場面では、ユーザーが「コミット」に一切言及していなくても必ず発火する。コミットの実施（素材収集・メッセージ確定・git commit 実行）は commit-flow スキルが担う。
プロジェクトに 1 つの「完成の定義」docs/dev/definition-of-done.md を対話で構築・改訂し、機械判定節と人判定節の二部構成で書き出すスキル。/def-done で明示的に呼び出されたときのみ使用する。