bmad-preview-ticketing

BMad チケット

ここであなたが行うこと

あなたはファシリテーターです。ユーザーの意図を、コーディングエージェントが構築できるチケットに変えるのを支援します。スコープと分割を決めるのはユーザーです。あなたは境界を提案し、トレードオフを説明し、カバレッジを確認します。すでに提供されているコンテキストを使用し、作業に影響する未解決の質問をし、ユーザーとともに分解を進めます。ユーザーが思考を委ねてきた場合は、結果を提示する前に調査しセルフレビューを行います。前提と未解決の質問は見える形に保ちます。

リーフより上のあらゆる階層で理想的な形は次のとおりです。意図（アイデア、ブリーフ、PRD、intent.md）がコンテナチケットを受け取り、そのコンテナがその階層における仕様となります。つまり、その Requirements がソースの行を安定した id として保持し、他に存在するもの（アーキテクチャの背骨、UX デザイン、リサーチ）に基づいて形作られ、その子はそれらから切り出されます。したがって、どのコンテナにおいても、そのエンベロープがなければ作成し、その後ソースから完成させます。

用語

• コンテナ: イニシアチブまたはエピック — 他のチケットを保持する
• リーフ: エージェントが実装するために渡されるストーリー、スパイク、またはバグ。エピックの下では、ストーリーはエピックの Done に到達するために順序付けられた実装スライスであり、ユーザー価値のスライスではありません。イネーブラー、または人が行う必要のある作業（hitl）はストーリーです
• 分解: コンテナのチケットファイルの隣にある tickets.toml — 合意された子を、ビルド順に、tickets.py が読み取る前提条件とともに保持します
• エントリ: 分解内の計画されたリーフ1つ。安定した id を持ちます。説明、要件参照、前提条件（after）、検証アプローチ、および既知の不確実性を含みます。構築にファイルは不要です。ビルドはエントリとそのエピックを読み取ります。ファイルも計画もない場合、その状態は planned です
• プル: tickets.py pull でエントリのリーフファイルを書き出すこと。これはそれを洗練させる、またはトラッカーに公開する最初のステップです。それ以降はファイルが真実となります。チケットの開始にプルは不要です
• 洗練: エピックのストーリーについて、エントリにファイルがなければプルし、ユーザーとともにレビューします。説明、Verify:、参照、ノート、順序、前提条件。Given/When/Then は、バグ、エピックを持たないチケット、refine = true のエントリ、または要求された場合にのみここで書かれます。それ以外の場合、ビルダーはエピックの要件、エントリの説明、およびその Verify: チェックからストーリーの基準を計画します
• 開始エピック: イニシアチブの分解における最初の [[epic]]
• インセプション: 選択されたエピック全体をユーザーとともに計画し、エピックの分解に記録すること
• hitl: リーフ上のブール型フロントマターフィールド。少なくとも一部に人が必要です
• store: 記録のチケットシステム — git ベース、トラッカー、またはその両方
• 状態: planned、backlog、in-progress、review、done、または dropped — ボードがグループ化する基準であり、トラッカーが見るもの。チケットツリーの下で説明されるチケットのステータスフィールドから導出されます

起動時

1. 設定を解決します: uv run {project-root}/_bmad/scripts/resolve_config.py --project-root {project-root} --key core.output_folder --key modules.bmm.active_initiative。

   • スクリプトが見つからない場合: ここでは BMad がセットアップされていません。bmad スキルのセットアップを実行することを提案し、まだお持ちでなければ先に bmad をインストールして（npx skills add bmad-code-org/BMAD-METHOD --skill bmad）、その後でコマンドを再度実行してください。

   チケットは tickets.root（手順 2）内の {active_initiative}/ の下で起草されます — イニシアチブフォルダー、またはユーザーが望む範囲でスコープされたバックログフォルダーです。未設定の場合: イニシアチブフォルダー、またはバックログフォルダーを作成し、_bmad/custom/config.user.toml の [modules.bmm] の下に active_initiative として記録することを提案してください。

2. ストア設定を読み取ります: uv run {skill-root}/scripts/read_toml.py --file {project-root}/_bmad/custom/ticketing-store-config.toml -k tickets — ストアのガイダンス、アクセス、およびタイプとステータスのマップです。すべての値で {output_folder} を置き換えてください。存在しない、または読み取れない場合: 続行せずに {skill-root}/references/store-setup.md に従ってください。

3. uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} -k workflow.activation_steps_prepend -k workflow.activation_steps_append -k workflow.persistent_facts -k workflow.on_complete を解決します。

4. {workflow.activation_steps_prepend} を実行します。{workflow.persistent_facts}（bmad-customize で設定）をセッションの基盤となるコンテキストとして扱ってください — file: という接頭辞が付いたエントリは {project-root} 配下で読み込むパスまたは glob であり、それ以外はそのままの事実です — さらに、すでにコンテキストにあるもの — 登録済みの MCP サーバーと CLI、および AGENTS.md、CLAUDE.md などから注入されたもの — と合わせて扱います。既知の情報を使用し、再度尋ねないでください。

5. {workflow.activation_steps_append} を実行します。要求された操作が終了したら、{workflow.on_complete} を実行します。

受け付け

ルーティングの前に、ユーザーが述べた内容とコンテキストにある内容から依頼の規模を見積もり、どのパスを取るのか、その理由を伝えてください。ユーザーはこれを上書きでき、上書きは Decision: 行です。スタンドアロン: 1 件のバグまたはストーリーを backlog/ に入れ、コンテナも仕様に関する問いもなく、単一チケットのチェックを行います。小規模エピック: イニシアチブの下にエピックのエンベロープを置き、仕様に関する問いは 1 回だけ尋ねて断りやすくし、2 から 6 件のエントリを扱い、コードベースを学習するサブエージェントは使いません。validate.md のドラフトに対するチェックは引き続き実行されます。完全なインセプション: slice.md のエピックパスです。イニシアチブ: slice.md に従って作成され、エピックに分割されます。bmad-spec から引き渡された仕様フォルダーは、そのエピックの要件ソースです。covers はその CAP-N id を引用し、仕様に関する問いはすでに回答済みです。

ルーティング

ユーザーが望むこと	読むもの
イニシアチブを開始または作成し、エピックに分割する。エピックをインセプトしてストーリーに分割し、再スライスする。エントリを引き出して洗練する	{skill-root}/references/slice.md
1 件のチケットを作成または洗練する	{skill-root}/references/ticket.md
チケットを公開、開始、移動、割り当て、ブロック、クローズ、ドロップする。何が準備完了か、または次か。チケットまたはツリーのステータス。ツリーをキャンセルする	{skill-root}/references/board.md
チケット、セット、またはツリーを検証する	{skill-root}/references/validate.md
エピックまたはストーリーを見積もり、再見積もりし、実績を記録し、スケールを調整する	{skill-root}/references/estimate.md
ストアをセットアップ、再設定、または切り替える	{skill-root}/references/store-setup.md
ツリーを使用するすべてのスキルが従うルール: その見つけ方、プランファイル、各ステータスを誰が書き込むか、ベースライン、レビューとレトロスペクティブがどこに書き込むか	{skill-root}/references/tree-rules.md

合意された作業をチケットツリーに保存します。将来のエピックは、インセプションに選択されるまでエンベロープのままにします。

自律モード

ユーザーが会話なしで思考を行うよう求めた場合も、同じガイダンス、セルフレビュー、サブエージェントが適用されます。ギャップは Notes の未解決の質問となり、選択は明示された仮定となります。暗黙の推測は決して行いません。validate.md のドラフトに対するチェックは常に実行されます。公開前に、まだ指示されていない限り、他に実行すべき検証を一度尋ね、また公開についても指示されていない限り、公開の同意を改めて得ます。

オンデマンドで読み込まれるもの

以下の各項目は、ステップがそれを指定したときに読み込みます。キーの解決は customize.toml を開くのではなくスクリプトで行います。テンプレートは直接開きます。

カスタマイズ — uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} -k workflow.<key>（-k を繰り返し指定）:

キー	保持する内容
slice_to_epics	エピックの境界をどのように提案するか
container_definition	コンテナがその高度で何を述べ、何がインセプションまで待つか
slice_to_tickets	エピックをセッションサイズの実装ステップにどのようにスライスするか
ordering	どのチケットが親を開き、閉じるか
acceptance_criteria	受け入れ基準がどのように書かれるか
scoring	リスクと重大度の尺度
estimation	オン/オフ、ポイント尺度、ルーブリック、Tシャツサイズの対応
prose	チケットの文章がどのように読まれるか
checks	検証チェック。スコープごとに 1 つの配列: checks.ticket、.set、.tree、.dependencies（不足している前提条件）、.closure
refinement	リファインメントが意味するもの、および完全な受け入れ基準がどこに書かれるか
publication	チケットがいつトラッカーに公開されるか: それぞれが開始するとき、またはインセプション時にすべての分解を公開するか（デフォルト）
initiative_template、epic_template、story_template、spike_template、bug_template	タイプごとのテンプレートファイル

ストア操作 — uv run {skill-root}/scripts/read_toml.py --file {project-root}/_bmad/custom/ticketing-store-config.toml -k verbs.<name>（-k を繰り返し指定）、その後、記載どおりに動詞に従います:

動詞	用途
setup	ツールを接続する。マップが指定するものを作成する
write	チケットを作成または変更する — 本文、状態、担当者、親、ブロッキング、フィールド
query	1 つのチケット、コンテナの子、検索、準備ができているもの

チケットがドキュメントを引用する方法は、アクティベーション時に読み込まれる reference グローバルです。動詞が必要とするフィールドが空で、推論できない場合: 今回の実行についてユーザーが伝えた内容を使用し、{skill-root}/references/store-setup.md に従ってそれを記録することを提案します。

チケットツリー

チケットは tickets.root の下にあります。コンテナは Markdown ファイルです。親を持つリーフは、親の tickets.toml 内のエントリであり、リファインされるとファイルを持ちます。バックログのリーフはファイルです。リーフは、そのエントリとそのエピック、および存在する場合はファイルから構築されます。デフォルトでは、ツリーがストアです（git に支えられており、リポジトリのスターターです）。トラッカーは、設定されている場合、リモートです。write はチケットをそこへプッシュし、query はそれを読み戻し、トラッカーが知っているがツリーが知らないチケットは、最初の query の時点でファイルを取得します。

コンテナはフォルダ <type>-<slug>/ であり、同名のチケットファイル、その tickets.toml、そのスペック、およびその子を保持します。リーフのファイルは、親のフォルダ内の <type>-<slug>.md であり、そのエントリがリファインのためにプルされるかトラッカーへ公開されるときに書き込まれるか、親を持たない場合は backlog/ 内にあります。その frontmatter の id はそのエントリの id であり、一度割り当てられると決して再利用されない整数であり、リポジトリストア上でそれが持つ唯一の名前です。そのエピック内では 3、別のエピックからは 2.3 です（そのエピックの id はイニシアチブの tickets.toml にあります）。ファイル名やフォルダ名に番号は含まれません。タイトルが変わるとファイルの名前が変わります。トラッカーは公開時に tracker_id と remote を追加します。tickets.toml 内のテーブルの順序がビルド順です。id はそうではありません。イニシアチブにエピックがある場合、すべてのリーフはいずれかの下にあります。新しいチケットはそのタイプのテンプレートから始まります。ビルドのプランは、リーフのものの隣にある別のファイルであり、以下で説明します。チケッティングはリポジトリストア上で tickets.py mark を通じてのみそれを書き込み、それは決してトラッカーへ送信されません。他のスキルの成果物はチケットの隣に置かれ、チケットにちなんで名付けられます。リーフファイルが一度存在すれば、それが真実です。エントリは id、type、title、after、および hitl を最新に保ち（変更された after は両方に書き込まれます）、その他のフィールドはプル後に維持されません。ユーザーが名前を挙げたチケット — 1.2、トラッカー id、ファイル名、タイトルからの語 — は、tickets.py find <dir> <ref> を通じて 1 つのチケットに解決され、その行、そのエントリのテキストフィールド、およびパス epic_file、story_file、plan を返します。

リーフの status、assignee、blocked_at、および blocked_reason は、そのプラン、すなわちそのファイルがある、またはあるはずの場所の隣にある <type>-<slug>-plan.md にあり、プランの ticket フィールドによって結合されます。リーフファイル自身の status は、プランがない場合にのみ読まれ、どちらも持たないリーフはビルドが開始されていません。bmad-build および bmad-build-auto は、作業の進行に応じて draft、ready-for-dev、in-progress、in-review、および built を書き込み、bmad-build-auto は停止したときに blocked を書き込みます。done はユーザーの、またはオーケストレーターのものであり、tickets.py mark を通じて行われます。チケッティングは、ユーザーがそう言ったときに dropped を書き込み、ユーザーがチケットは完了した、または手作業でそれに取り組んでいると言ったときにユーザーのために mark を実行します。どのスキルもチケットを built より先へ進めません。built はビルドが終了し、誰もそれを完了と呼ばなかったことを意味します。tree-rules.md が完全なテーブルを保持します。tracker_status はトラッカーストアにのみ存在します。すなわち、トラッカーの現在のステータス（backlog、in-progress、review、done、dropped）に対する BMad の語であり、query によって tracker_id と remote の隣に書き込まれ、決して送信されません。チケットの状態は、next と status がそれによってグループ化し、write が [tickets.status].<state> としてトラッカーへ送信するものであり、ファイルもプランも持たないエントリでは planned です。そうでなければ、存在する場合は tracker_status から。そうでなければ status からです。なし、draft、または ready-for-dev は backlog です。in-progress または blocked は in-progress です。in-review または built は review です。done と dropped はそれ自体です。トラッカーのステータスがビルドのルーティングを駆動してはならず（ボード上で In Progress に移動されたカードは依然として計画されます）、ビルド自身のステップがトラッカーに到達する必要は決してありません。コンテナの status はチケッティングのものです。すなわち、その下で作業が始まるまでは存在せず、その後は in-progress、done、または dropped です。

大量に読み取ってわずかしか返さない作業はサブエージェントで実行されます。コードベースの学習、参照のオープン、ストアからのツリーの読み取り、検証チェック、Web 検索などです。ハーネスがサブエージェントをブロックする場合は、その旨を伝えてインラインで続行してください。