メニュー
AIエージェントを作るときの最初の段階。業務担当者へのヒアリング内容（hearing_sheet_*.md の記入結果）を読み取り、spec.md の初版・hearing_notes.md・usecase_catalog.md を生成する。「○○業務を効率化したい」「○○エージェントを作りたい」と相談されたとき、まずこのスキルで業務理解とユースケース抽出をする。リサーチ・レビュー・抽出・アシスタント系のいずれにも使える。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
評価が安定した動くエージェントを実運用に乗せるためのスキル。cron / Webhook トリガー、配信先（Slack / SMTP / Confluence）、コスト上限、人間レビュー工程、監視・アラート、リトライ・フォールバック、シークレット管理を設計する。「本番運用したい」「業務に組み込みたい」と言われたら呼ぶ。
agent-discover の後に呼び出すスキル。spec.md を読んで業務プロセスをノードに分割し、各ノードを「決定論コード」と「LLM 判断」に振り分け、設計パターン（Reflection / Tool Use / Planning / Multi-Agent）を選定する。LangGraph のグラフ構造、ReAct ツール定義、ハイブリッド構成を design.md として出力する。「実装の設計をしたい」「ノードの切り方が分からない」「パターンの選び方を知りたい」と言われたとき呼ぶ。
agent-prototype で動くものができた後、評価データセットを使って品質・コスト・所要時間を測定し、改善案を出すスキル。LayerX 流の評価駆動開発（Eval-driven）を実践する。「精度を上げたい」「コストを抑えたい」「品質を客観評価したい」と言われたら呼ぶ。10〜20件の代表的データから始めて、リリース後にユーザーフィードバックで拡充するサイクル。
動いているエージェントの構成を探索的に改善する高度スキル。マルチエージェント化（Planner+Reviewer+Synthesizer）、モデル使い分け（Sonnet/Haiku）、プロンプトの自動改善、パラメータ探索などを試みる。Sakana AI の ShinkaEvolve（進化的アルゴリズムでエージェント設計を発見）の思想を取り入れる。「もう一段、品質を上げたい」「コストを大幅削減したい」と言われたとき呼ぶ。オプション・後回しで OK。
agent-decompose の後に呼び出すスキル。design.md を読み、reference/ の雛形コード（workflow_skeleton.py / react_skeleton.py / multi_agent_skeleton.py）を起点にエージェントの最小実装を作る。LangGraph の StateGraph、ReAct エージェント、ツール定義を組み合わせて scripts/ に動くコードを出力する。「最初の動くもの」を1日以内に作るのが目標。
| name | agent-discover |
| description | AIエージェントを作るときの最初の段階。業務担当者へのヒアリング内容（hearing_sheet_*.md の記入結果）を読み取り、spec.md の初版・hearing_notes.md・usecase_catalog.md を生成する。「○○業務を効率化したい」「○○エージェントを作りたい」と相談されたとき、まずこのスキルで業務理解とユースケース抽出をする。リサーチ・レビュー・抽出・アシスタント系のいずれにも使える。 |
reference/hearing_sheet_*.md) が記入されている、もしくは口頭で業務説明があるときworkspace/<project>/v1/（バージョンが進めば v2/, v3/...）に以下を生成:
| ファイル | 内容 |
|---|---|
spec.md | 初版仕様書。次の /agent-decompose 以降が「正」として扱う |
hearing_notes.md | 業務担当者から引き出した素のメモ（後の検証用） |
usecase_catalog.md | 30件程度のユースケース一覧（LayerX 流） |
reports/discover_report.md | このスキルの作業報告 |
ユーザーの相談内容から、どのヒアリングシートを使うか判定:
reference/hearing_sheet_<種別>.md を提示し、未記入なら一緒に埋める。
reference/hearing_templates.md のチェックリスト（A〜H）を順に確認:
「人の判断スキル」を言語化する のがこのスキルの肝。具体的に深掘り:
質問例:
「経験豊富な担当者が見ると一発で『これは外せない』と思う記事の特徴は？」
「新人がよく間違える判断のパターンは？」
「『広報的すぎる発表』と『本物の動き』をどう見分けてる？」
「で、ウチはどう動くか、を考えるとき、どの観点を優先する？」
回答を editorial.persona / perspective / rules の3つの形式に整理。
30件程度のユースケースを表にまとめる。各ケースに:
reference/spec_template.md をベースに、以下のセクションを埋める:
# スペック: <エージェント名> v1
## 1. 目的
## 2. エージェント種別
## 3. 入力 / 出力
## 4. 編集者ペルソナ
## 5. 編集者の視点
## 6. 執筆ルール
## 7. 情報源（リサーチ系の場合）
## 8. カテゴリ構成
## 9. 評価指標と目標値
## 10. 制約（コスト・速度・セキュリティ）
## 11. 運用条件（トリガー・配信先・レビュー）
## 12. 既知のリスクと対処
## 13. 次のアクション
hearing_templates.md の §H「完了判定」を全項目チェック。
未確定項目があれば、次のヒアリングのためのリストとして spec.md に明記。
workspace/<project>/vN/ に出力/agent-decompose /agent-prototype の仕事）ヒアリングが完了したら:
/agent-decompose
spec.md を読んで、業務プロセスをノードに分割し、設計パターンを選定する。