agile-intake

インテーク

曖昧な問題、初期アイデア、構造化されていない依頼を、明確で実行可能なインテーク文書にまとめるために、このスキルを使用します。

スラッシュ経由で受け取った初期コンテキスト：$ARGUMENTS

$ARGUMENTS に値がある場合（例：ファイルパス、テキスト、課題の参照、URL）は、それをインテークの出発点として使用します。 空の場合は、問題の簡単な説明を尋ねることから始めます。

言語

成果物はユーザーの言語で作成します。正しい文法と、必要な発音区別符号や各文字体系固有の文字を使用してください。ユーザーの言語が明確でない場合は、出力を生成する前に確認します。テンプレートは英語です。見出しと内容をユーザーの言語に合わせて翻訳してください。

プロジェクトのルート

このスキルは、エージェントの現在の作業ディレクトリではなく、プロジェクトのルート（作業対象のリポジトリ）を基準とするパスに成果物を書き込みます。

• プロジェクト内から実行する場合は、このスキルに示されている相対パス（例：planning/<initiative>/intake.md）を使用します。
• 別のディレクトリから実行する場合（例：隣接するリポジトリ、またはプロジェクトが別の場所にある場合）は、すべての成果物パスの先頭に<project-root>/を付けます。
• プロジェクトのルートが曖昧な場合は、書き込む前にハーネスの質問ツールを使ってユーザーに確認します。

プロンプト

CLAUDE.md / AGENTS.md にあるプロジェクト全体の規約（「Skill Prompting Conventions」）に従います。以下の判断ポイントでは、ハーネスの構造化質問ツール（Claude Code のAskUserQuestion、Codex のask_user_question、または OpenCode のquestion）を使用します。

判断ポイント	構造化質問にする理由	推奨される選択肢
フロー内の次の成果物	後続の流れを分岐させます	/agile-roadmap · /agile-epic · /agile-story
インテークの保存	元に戻しにくい書き込みです	保存 · インラインでのみ提示

自由形式のプロンプト（構造化ツールなし）：

• イニシアチブ名（kebab-case のスラッグ）
• 問題の説明と制約

一時停止なしモード：ユーザーがスキルの途中での確認を明示的に無効にしている場合は、すべての構造化質問を「未解決の質問」（または同等の項目）として記録し、処理を中断せずに続行します。

目的

• 計画を立てる前に、問題や機会を明確にする
• 制約、前提、未解決の質問を特定する
• フロー内の次のステップを定義する：/agile-roadmap、/agile-epic、または/agile-story
• 解決対象が明確でないまま作業が始まるのを防ぐ

使用する場合

• スコープが定義されていないアイデア、ニーズ、問題が提示された場合
• 依頼が曖昧すぎて、そのままエピックやタスクにできない場合
• 規模、優先度、進め方に不確実性がある場合
• 新しい問題について初めて話し合う場合

使用しない場合

• 問題がすでに明確で、スコープも定義されている場合 — /agile-epic または/agile-storyを直接使用します
• 作業がすでに分解されている場合 — /agile-epic または/agile-storyに進みます
• 些細な修正の場合 — /agile-storyを直接使用します

インテークのプロセス

1. 話を聞いて記録する

ユーザーに次のことを尋ねます。

• 問題または機会は何ですか？
• 誰に影響し、どのような影響がありますか？
• 緊急性や期限はありますか？
• すでにわかっている制約はありますか？

回答を推測しないでください。ユーザーがわからない場合は、未解決の質問として記録します。

2. インテークを構成する

収集した情報をテンプレートに記入します。

• コンテキスト：問題、当初の目的、価値の指標、制約
• 初期スコープ：対象に含めるものと含めないもの（暫定的なものも含む）
• 入力と参考資料：ステークホルダー、ドキュメント、技術的なコンテキスト
• 未解決の質問：まだ答えが出ていないすべての項目

**価値の指標 — 探索的なプロジェクト／サンプルプロジェクト：**プロジェクトが探索的なもの、サンプル、または学習演習である場合は、願望的な数値をでっち上げず、Expected value signal を N/A — exploratory と記録します。実際のプロダクト指標は実際のプロダクト開発に適用されるものであり、サンプルプロジェクトに KPI は必要ありません。

前提と未解決の質問： 前提とは、レビューのために記録された決定です（エージェントが決定し、ユーザーは後で変更できます）。未解決の質問とは、解決しなければ次の成果物の作成が妨げられる、保留中の決定です。それぞれに適した項目を使ってください。

3. 次のステップを定義する

所要時間ではなく、進行の複雑さに基づいて判断します。

• 依存関係のある複数フェーズの進行（全体の所要時間を問わない）→ /agile-roadmap → 次に /agile-epic 判断の目安 — 2 つ以上該当する場合はロードマップを使用します。
  • 順序付けが必要な複数の取り組みがある（すべてを並行して進められない）
  • 今日の決定が将来の決定に影響する（局所的な最適化が技術的負債になり得る）
  • ステークホルダーが個別のステップを承認する前に、全体の道筋を把握する必要がある
  • 外部依存関係（他のチーム、ベンダー、期限）がある
  • 全体の複雑さが単一のエピックに収まらない
• スコープの広い、単一の連携した取り組み → /agile-epic
• 妥当なスコープの中程度の問題 → /agile-epic（ストーリーに分解するため）
• 小さく明確な問題 → /agile-story

**重要：**ロードマップは期間（例：「3～12 か月」）で決まるものではありません。4 週間の取り組みでも、明確な 5 つのフェーズと重要な順序があれば、ロードマップが役立ちます。判断基準は所要時間ではなく、進行の複雑さです。

推奨内容をインテークに記録し、ユーザーに確認します。

**フロールール：**大規模または複雑な項目は、実行前に /agile-epic を使って必ず分解します。小規模で局所的な項目のみ、直接 /agile-story に進めます。

4. インテークを保存する

• 取り組みの名前を尋ねます（例：component-tests、auth-refactor、mvp-reserva）。取り組みを表すkebab-case のスラッグを選びます（成果物の名前ではありません）。連番、日付、intake-1 のようなラベルは避け、スコープが変化しても使い続けられる安定したスラッグを選びます。
• planning/<initiative>/intake.md に保存します。
• ユーザーが保存を希望しない場合は、インラインで提示します。

5. 次の成果物につなげる

ユーザーの確認後、公式フローに沿って次の成果物を作成するか尋ねます。

• 複数フェーズの進行 → 「/agile-roadmap を作成しますか？」
• 単一の連携した取り組み → 「ストーリーに分解するために /agile-epic を実行しますか？」
• 小規模／明確な項目 → 「/agile-story を作成しますか？」

6. 検証する

インテークを完了する前に、次の点を確認します。

• 次のステップに進める程度に問題が明確である
• 制約と前提が明示されている
• フローにおける次の成果物が定義されている

ルール

• インテークから実装に直接進んではいけません。インテークで作成するのは次の成果物であり、コードではありません。
• ユーザーが明確化を省いて開始するよう求めた場合は、リスクを記録し、それでも進めるか尋ねます。
• インテークは短く保ちます。会話は最大 10～15 分です。これ以上かかる場合は、問題を /agile-epic で分解する必要があると考えられます。
• 詳細な計画ではなく、発見を促すトーンを保ちます。

テンプレート

このスキルのベースとして templates/intake.md を使用します。

フローとの関係

flowchart LR
    A["/agile-intake"] --> B{next step}
    B --> C["/agile-roadmap"]
    B --> D["/agile-epic"]
    B --> E["/agile-story"]

このスキルはフローの開始点です。問題を把握し、適切なスキルへ導きます。使用するスキルの判断については、/agile-router も利用できます。