gds-quick-dev

Quick Dev New Preview Workflow

目標： ユーザーの意図を、強化されレビュー可能な成果物に変換します。

重要： 手順に「すべて読み、step-XX に従う」と記載されている場合は、step-XX をすべて読んで従ってください。例外はありません。

規約

• パスのみの指定（例：template.md）は、スキルのルートを起点に解決します。
• {skill-root} は、このスキルがインストールされているディレクトリ（customize.toml がある場所）に解決されます。
• {project-root} は、プロジェクトの作業ディレクトリから親ディレクトリをたどって最初に見つかる、_bmad/ を含む最も近いフォルダーです。
• {skill-name} は、スキルディレクトリのベース名に解決されます。

有効化時

Step 1: ワークフローブロックを解決する

実行：uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key workflow

スクリプトが失敗した場合は、以下の3つのファイルを基本設定 → チーム設定 → ユーザー設定の順に読み込み、リゾルバーと同じ構造マージのルールを適用して、workflow ブロックを自分で解決します。

1. {skill-root}/customize.toml — デフォルト設定
2. {project-root}/_bmad/custom/{skill-name}.toml — チームによる上書き
3. {project-root}/_bmad/custom/{skill-name}.user.toml — 個人設定による上書き

存在しないファイルはスキップします。スカラー値は上書きし、テーブルはディープマージします。code または id をキーとするテーブル配列では、一致する項目を置き換えて新しい項目を追加します。その他の配列はすべて追加します。

Step 2: 前置ステップを実行する

続行する前に、{workflow.activation_steps_prepend} の各項目を順番に実行します。

Step 3: 永続的な事実を読み込む

{workflow.persistent_facts} の各項目を、ワークフローの残りの実行中に引き継ぐ基礎的なコンテキストとして扱います。file: で始まる項目は、{project-root} 以下のパスまたはグロブです。参照されている内容を事実として読み込みます。それ以外の項目は、記載どおりの事実です。

Step 4: 設定を読み込む

{project-root}/_bmad/gds/config.yaml から設定を読み込み、次の項目を解決します。

• user_name
• communication_language
• implementation_artifacts

Step 5: ユーザーに挨拶する

{communication_language} で {user_name} に挨拶します。

Step 6: 後置ステップを実行する

{workflow.activation_steps_append} の各項目を順番に実行します。

有効化はこれで完了です。activation_steps_prepend または activation_steps_append に項目があった場合は、続行する前に、すべての項目を順番どおりに実行したことを確認します。有効化のすべてのステップが完了するまで、メインワークフローを開始してはいけません。

開発着手可能の基準

仕様が「開発着手可能」である条件：

• 実行可能：すべてのタスクにファイルパスと具体的な作業が記載されている。
• 論理的：タスクが依存関係の順に並んでいる。
• テスト可能：すべての AC が Given／When／Then 形式になっている。
• 完全：プレースホルダーや TBD がない。

スコープの基準

仕様では、単一のユーザー向け目標を対象とし、900～1600 トークンを目安にします。

• 単一の目標：複数のレイヤーやファイルにまたがる場合でも、一貫した1つの機能を対象とします。複数の目標とは、トップレベルで独立してリリース可能な成果物が2つ以上あることを意味します。それぞれが、他方を損なうことなく個別の PR としてレビュー、テスト、マージできるものです。表面的な動詞、「and」という接続詞、名詞句の数で判断してはいけません。1つのユーザー目標に含まれるレイヤー横断の実装詳細を分割してはいけません。
  • 分割する例：「ダークモードの切り替えを追加 AND 認証を JWT にリファクタリング AND 管理者ダッシュボードを構築する」
  • 分割しない例：「入力を検証してエラーを表示する」／「ドラッグアンドドロップ AND 貼り付け AND 再試行をサポートする」
• 900～1600 トークン：LLM が処理するのに最適な範囲です。900 未満では曖昧さが生じやすく、1600 を超えると実装エージェントのコンテキストが劣化するおそれがあります。
• どちらの制限も必須ではありません。 どちらも提案であり、ユーザーによる上書きが可能です。

ワークフローのアーキテクチャ

これは、規律ある実行のためにステップファイル・アーキテクチャを採用しています。

• マイクロファイル設計：各ステップは自己完結しており、記載どおりに実行します。
• ジャストインタイム読み込み：現在のステップファイルのみを読み込みます。
• 順次実行の徹底：ステップを順番に完了し、スキップしません。
• 状態の追跡：仕様のフロントマターとメモリ内の変数を使って進捗を保持します。
• 追記のみの構築：成果物を段階的に構築します。

ステップ処理のルール

1. 最後まで完全に読む：作業を始める前に、ステップファイル全体を読みます
2. 順序に従う：各セクションを順番に実行します
3. 入力を待つ：チェックポイントで停止し、人間からの入力を待ちます
4. 次のファイルを読み込む：指示されたら、次のステップファイルを最後まで読み、指示に従います

重要なルール（例外なし）

• 絶対に複数のステップファイルを同時に読み込まないでください
• 必ず実行前にステップファイル全体を読んでください
• 絶対にステップを省略したり、順序を効率化したりしないでください
• 必ずステップファイルの指示に正確に従ってください
• 必ずチェックポイントで停止し、人間からの入力を待ってください

初期化シーケンス

1. 設定の読み込み

{main_config} から設定全体を読み込み、次の項目を解決します：

• project_name、planning_artifacts、implementation_artifacts、user_name
• communication_language、document_output_language、game_dev_experience
• システムで生成された現在の日時を date とします
• sprint_status = {implementation_artifacts}/sprint-status.yaml
• project_context = **/project-context.md（存在する場合は読み込みます）
• CLAUDE.md／メモリファイル（存在する場合は読み込みます）

必ず、設定の {communication_language} に従ったエージェントのコミュニケーションスタイルで回答してください。

2. 最初のステップの実行

./step-01-clarify-and-route.md を最後まで読み、指示に従ってワークフローを開始します。