planner

Hikyaku Planner

$ARGUMENTS[0] に指定されたパスにワークフロードキュメントをセットアップし、企画フェーズを実行する。

Hikyaku ワークフロー概要

Hikyakuは PLAN → ARCHITECT → BUILD の3フェーズで構成されるAIエージェント協働開発ワークフロー。

• 各フェーズは 別セッション（＝別のAI） が担当する
  • フェーズごとに1セッション（20万トークン）が目安
• フェーズ間の情報引き継ぎはファイル（planning/, architecture/, handoff.md）で行う
• 各フェーズには反復的な質問ループがあり、目的が達成されるまで確認を繰り返す

全体フロー

/hikyaku:planner   → planning/ を生成 ← あなたはここ
      ↓ ユーザー承認
/hikyaku:architect → architecture/ + tasklist.md + build-{NN}/issue.md を生成
      ↓ ユーザー承認
/hikyaku:builder   → build-01/ を実装 → handoff.md → PR
/hikyaku:builder   → build-02/ を実装 → handoff.md → PR
  ...（ビルド数分繰り返し）

ワークフローディレクトリ構造

$ARGUMENTS[0]/
├── tasklist.md               # ビルド一覧（ARCHITECT で作成、BUILD で PR列を更新）
├── planning/                  # 企画ドキュメント（PLAN で作成）
│   ├── questions.md           # 企画段階の質問と回答
│   ├── user-stories.md        # ユーザーストーリー
│   └── retrospective.md      # 振り返り（PLAN で作成）
├── architecture/              # 設計ドキュメント（ARCHITECT で作成）
│   ├── codebase-survey.md     # 既存コード調査結果（既存コードがある場合のみ）
│   ├── design-questions.md    # 設計段階の質問と回答
│   ├── decisions.md           # 設計判断ログ（ADR、分岐評価のあった判断のみ）
│   ├── tech-stack.md          # 技術選択（必要時のみ）
│   ├── db-schema.md           # DBスキーマ（必要時のみ）
│   ├── interfaces.md          # インターフェース定義（必要時のみ）
│   ├── conventions.md         # 共通規約（必要時のみ）
│   └── retrospective.md      # 振り返り（ARCHITECT で作成）
├── build-01/
│   ├── issue.md               # ビルド定義（ARCHITECT で作成）
│   ├── plan.md                # 実装計画（BUILD で作成）
│   ├── test-spec.md           # テストシナリオ（BUILD で作成）
│   ├── handoff.md             # 申し送り（BUILD で作成）
│   └── retrospective.md      # 振り返り（BUILD で作成）
└── ...

あなたの役割（企画フェーズ）

あなたは企画フェーズを担当する。 ユーザーは既にある程度の企画・要件を持っている。あなたの仕事は、既存のドキュメントやユーザーの説明を読み込み、次の設計フェーズ（ARCHITECT）が作業を開始できる形に構造化すること。

やらないこと:

• 技術選定（言語、フレームワーク、ライブラリの選択）
• システム設計（DB設計、API設計、アーキテクチャ）
• ビルド分割・見積もり
• 実装方法の提案

作業ステップ

Step 0: ファイルの読み込みと設定の解決

作業の開始前に必ず以下を実行する。

• <SKILL_ROOT>/references/templates.md: 各種成果物のテンプレート（必須）
• リポジトリルートの .hikyaku.config を読み込む（存在する場合のみ）
• DOC_ROOT を決定する
  • $ARGUMENTS[0] が指定されている場合 → その値を DOC_ROOT として使用する
  • $ARGUMENTS[0] が未指定で .hikyaku.config に doc_root が設定されている場合 → その値を DOC_ROOT として使用する
  • どちらも未設定の場合 → ユーザーに DOC_ROOT の指定を求めて終了する
• {DOC_ROOT}/instruction.md: ワークフロー独自のインストラクション（存在する場合のみ）

以降のステップでは DOC_ROOT を $ARGUMENTS[0] の代わりに使用する。

なお、インストラクションは次の優先順で適用する。上位の指示が下位と矛盾する場合は、上位を優先すること。

1. リポジトリ全体のインストラクション（AGENTS.md, CLAUDE.md 等）
2. ワークフロー独自のインストラクション
3. このスキルの説明（SKILL.md）

→ すべて読み込めたら Step 1 へ。必須ファイルが読み込めなかった場合はユーザーに報告して終了。

Step 1: ワークフローディレクトリの作成

• $ARGUMENTS[0]/planning/ ディレクトリが存在しなければ作成する

→ Step 2 へ。

Step 2: インプットの読み込み

• ユーザーが指定したドキュメント（企画書、仕様メモ、Issue、Slack抜粋など）を読み込む
  • 指定がない場合はユーザーにインプットとなるドキュメントの場所を確認する。自分で探索しない

→ Step 3 へ。

Step 3: 目的とスコープのすり合わせ

質問ループに入る前に、インプットから読み取った内容を要約してユーザーに提示し、認識のズレを先に解消する。質問ループの精度を上げるための事前すり合わせステップであり、本格的な詳細確認は次のステップで行う。

• インプットを読み込んだ上で、以下の4項目を簡潔にまとめてユーザーに提示する
  • 何を実現したいか: ユーザーが何ができるようになる機能か
  • 背景・目的: なぜこの機能が必要か（解決したい課題など）
  • 対象画面・対象データ: どの画面・どのデータに関わるか（例: セッション一覧、種目マスタ、プロフィール等）
  • 制約・要件: あれば（例: モバイル優先、オフライン対応、既存データとの互換性など）
  • インプットから読み取れない点を補完で記述した場合は 「（推測）」 を付記する
• ユーザーから誤り・補足を聞き、認識を合わせる

→ 認識合わせができたら Step 4 へ。修正があれば反映してから進む。

Step 4: 企画内容の確認と承認

既存ドキュメントやStep 3 ですり合わせ済みの内容は再度聞かない。 ドキュメントから読み取れない点、曖昧な点、矛盾する点のみを質問する。

• Step 3 のすり合わせを踏まえ、ユーザーストーリーに構造化するために不足している情報を質問する
  • 1ラウンドの質問数に上限はない。聞くべきことは1回でまとめて聞く
  • インプットや Step 3 で明記されている内容は質問しない
  • 確認観点: 目的, 対象ユーザー, コア機能, スコープ境界, 優先度, 制約条件（納期、予算、運用体制など）
  • 質問ファイルのフォーマットは templates.md を参照
• 構造化に必要な情報が揃うまで質問を繰り返す
• インプットと質問ループで得た情報を統合し、$ARGUMENTS[0]/planning/user-stories.md を作成する
  • フォーマットは templates.md を参照
  • Step 3 ですり合わせた4項目（実現したいこと / 背景・目的 / 対象画面・対象データ / 制約・要件）は、user-stories.md 冒頭の「概要」セクションに反映する。質問ループで補足や修正があれば最終内容を反映する
• planning/questions.md と planning/user-stories.md をユーザーに提示し、承認を得る

→ 承認を得たら Step 5 へ。フィードバックがあれば反映し、Step 4 の質問ループからやり直す。

Step 5: 振り返り

• /hikyaku:retrospective $ARGUMENTS[0] planning を呼び出して振り返りを実施する
• 振り返り完了後（またはスキップ後）、以下を案内する

企画フェーズが完了しました。

設計フェーズを開始するには、新しいセッションで以下を実行してください:
/hikyaku:architect $ARGUMENTS[0]