task-prd-creator

タスクと PRD の作成

明確で実行可能な PRD またはタスクを作成します。出力先は、ユーザーが作業を管理する場所によって異なります。

契約

入力：

• 機能、バグ、改善、または計画に関する依頼
• 出力先の希望：GitHub issue、ローカルの PRD／タスクファイル、または両方
• 任意の親 issue、ラベル、担当者、優先度

出力：

• PRD またはタスクのドラフト本文
• 出力先に応じた作成コマンドまたはファイルパス
• 承認後に作成した issue／ファイルの URL またはパス

作成／変更するもの：

• ドラフトの承認後に限り、ローカルの .agents/memory/<kebab-name>.md PRD ファイル
• ドラフトの承認後に限り、GitHub の issue／サブ issue

外部への副作用：

• GitHub issue の状態を読み取ります
• GitHub issue、サブ issue、または issue ブランチを作成することがあります

確認が必要な操作：

• ファイルまたは GitHub issue を作成する前に、必ずドラフトを提示します
• サブ issue のリンク付けや issue ブランチの作成前に確認します

委任先：

• 実装上の制約がまだ不明な場合は spec-first
• テスト先行で作業を進めるべき場合は tdd
• 実装後に CI が失敗した場合は gh-fix-ci
• ロードマップレベルの計画には strategy-expert

ステップ 1：ワークフローの希望を確認する

次の順に確認します。

1. ユーザーが「GitHub issue」、「ローカルファイル」、または両方を明示しているか
2. gh auth status が成功し、GitHub のリモートが存在するかを確認します → GitHub を利用可能
3. 希望が曖昧な場合は、「GitHub issue、.agents/memory/ 内のローカル PRD ファイル、または両方のどれにしますか？」と尋ねます

ステップ 2：依頼内容を把握する

不足していることだけを尋ねます。文脈が明らかな場合に、質問攻めにしないでください。

• どのような問題を解決しますか？
• 誰に影響しますか？（ユーザー向け、内部向け、インフラ）
• 厳守すべき制約や依存関係はありますか？
• より大きなエピックの一部ですか？（→ サブ issue）
• 優先度：critical / high / medium / low

ステップ 3：作成前に調査する

• 関連するアーキテクチャ文書があれば読みます（.agents/memory/ 内で architecture、summary、context の各ファイルを探します）
• コードベース内で関連するパターンを検索します
• 同じトピックの既存 issue を確認します：gh issue list --search "[keyword]"

ステップ 4：PRD を作成する

PRD の完全な構成については、references/full-guide.md を参照してください。

優れた PRD には、次の内容が含まれます。

• 問題 — なぜこれが必要なのか、対応しないと何が壊れるのか
• 目標 — 測定可能な成果を一文で記述
• スコープ — 対象と、明示的に対象外とする内容
• 受け入れ条件 — 曖昧ではなく、テスト可能であること
• 技術メモ — アプローチ、リスク、依存関係

簡潔にまとめます。余計な文言は入れません。受け入れ条件は、人が確認できるものでなければなりません。

エージェント向け issue のルール

出力先が自律型エージェントまたは AFK エージェント向けの issue の場合は、思いつくままの計画ではなく、エージェント向けの作業指示として記述します。

• ファイルごとの手順ではなく、動作と契約を説明します。
• 行番号や変更されやすいファイルパスは、そのパス自体が契約である場合を除き、避けます。
• 現在の動作、望ましい動作、受け入れ条件、対象外の範囲を記載します。
• 公開インターフェース、CLI コマンド、API の形式、設定キー、またはデータ契約が判明している場合は明記します。
• 実装メモは制約として記載し、エージェントが従うべき手順書にはしません。

垂直スライスへの分割

エピック、PRD、または計画を issue に分割する場合：

• 検証可能な成果を生み出す、小さな垂直スライスを優先します。
• 人の追加の入力なしでエージェントが完了できる issue には AFK と記載します。
• 人の判断、設計レビュー、認証情報、またはプロダクトに関する判断が必要な issue には HITL と記載します。
• 依存関係から実際の issue ID を参照できるよう、ブロックする issue をブロックされる issue より先に公開します。
• 各サブ issue は、1 つの作業に集中した PR で対応できる規模にします。

ステップ 5：適切な出力先に出力する

GitHub（利用可能な場合は優先）

新規 issue：

gh issue create \
  --title "[type]: clear title" \
  --body "$(cat <<'BODY'
[PRD content here]
BODY
)" \
  --label "type:feature" \
  --assignee "@me"

サブ issue（親 issue にリンク）：

# Create sub-issue
gh issue create --title "..." --body "..." 

# Link as sub-issue to parent #N
gh issue develop N --checkout  # only if needed
# Use: gh api repos/{owner}/{repo}/issues/{parent}/sub_issues --method POST -f sub_issue_id={child_id}

issue からドラフト PR を作成：

gh issue develop [issue-number] --branch "feature/[name]"

ローカルファイル（任意、または GitHub を利用できない場合）

• PRD：.agents/memory/[kebab-name].md

ローカルファイルのテンプレートについては、references/full-guide.md を参照してください。

ステップ 6：作成前に承認を得る

PRD のドラフトを提示します。「よさそうです」という返答、または修正を待ってから作成します。

ルール

• disable-model-invocation: true → ユーザーが明示的に呼び出した場合のみ実行します
• 下書きをユーザーに先に確認してもらわずに、ファイルや GitHub のイシューを作成しないでください
• サブイシューは、1 つの PR で対応できる大きさにしてください
• 要件が不明確な場合は、解決策ではなく、まず問題の説明を書いてください
• 拡張機能をスコープ外として却下する場合、リポジトリでローカルのスコープ外メモリーを使用しているときは、.out-of-scope/<concept>.md に永続的な理由を記録してください

関連項目

• spec-first — コードを書く前に仕様に基づいて開発します
• tdd — 動作が明確なタスクに対するレッド・グリーン・リファクタリングの実行
• gh-fix-ci — 既存の PR の CI を修正します
• strategy-expert — より広範なロードマップとコンテンツの計画