beads-create

Beads の作成

このスキルを使って、計画や仕様から Beads を作成し、レビューを行います。これにより、実装担当者は課題に着手して成果を出すだけでよくなります。このスキルは、従来の Beads（bd）と beads_rust（br）のどちらでも動作する必要があります。

ワークフロー

1. まずトラッカーを特定する

   • ユーザーが bd、br、beads、beads_rust のいずれかを明示した場合は、その指定に従います。
   • それ以外の場合は、実際にインストールされているものを検出します。
     • br だけがインストールされている場合は、br を使います。
     • bd だけがインストールされている場合は、bd を使います。
     • 両方がインストールされている場合は、現在のワークスペースや履歴をすでに管理しているトラッカーを優先します。推測で決める前に、ローカルの .beads/ の状態と既存のワークフローのドキュメントを確認します。
     • 両方がインストールされていてもワークスペースを特定できない場合は、見当で決めず、要点を絞った質問を1つします。
   • 1回の実行で両方のトラッカーのコマンドを混在させないでください。

2. 必要に応じて適切なローカルガイダンスを読み込む

   • ユーザーのマシンに、選択したトラッカーを扱うローカルスキルが読み込まれている場合は、まずそれを使います。
   • bd の場合、利用可能であればローカルの beads スキルを優先します。
   • br の場合、利用可能であれば、読み込まれているローカルの br、beads_rust、または同等のトラッカースキルを優先します。
   • ローカルスキルがない場合は、ローカルの CLI ヘルプとインストール済みツールを参照します。
     • bd --help、bd create --help、bd update --help
     • br --help、br create --help、br update --help
   • このスキルからユーザーを公開ウェブドキュメントに案内しないでください。
   • br の場合は、エージェント向けのコマンドで利用可能なら、常に --json を使います。

3. 作業モードを決める

   • ユーザーが確定済みの計画や仕様を持っていて、Beads の登録を希望している場合は、作成モードにします。
   • すでに Beads があり、その改善を希望している場合は、レビュー モードにします（手順6に進みます）。

4. 計画の準備が整っていることを確認する（作成モード）

   • Beads の外部に確定済みの計画または仕様があることを確認します。
   • 計画がまだ曖昧な場合は、まず修正を依頼し、登録前に最大5回までやり取りを繰り返します。

5. 計画をトラッカーの構造に反映する（作成モード）

   • 主要なマイルストーンや成果物に対応するエピックを作成します。
   • 具体的で実装可能なタスクを課題として作成します。
   • bd の場合：
     • エピックに子のマイルストーンやタスクがある場合は、独立したトップレベルの課題ではなく、EPIC.1、EPIC.2 のようなドット区切り ID を持つ階層型の子として作成します。
     • bd create ... --parent <epic-id> の手順に従い、bd が EPIC.N ID を自動割り当てするようにします。
     • 返された ID を確認します。bd がドット区切り ID を割り当てない場合は、作業を止め、次の進め方をユーザーに確認します。
   • br の場合：
     • エピック／親子関係を使いますが、ドット区切りの子 ID は必須ではありません。br は従来の bd のドット区切り ID の仕様に依存せず、親子構造をサポートします。
     • まずエピックを作成し、その後、--parent <epic-id> を指定して子課題を作成または更新します。
     • 順序が重要な箇所には明示的な依存関係を追加し、br dep cycles --json で依存関係グラフに循環がないことを確認します。
   • 依存関係、順序の制約、並行して進められる作業を追加します。

6. レビューして仕上げる（作成モード＋レビュー モード）

   • 曖昧なタイトル、欠けている受け入れ条件、不明確な範囲を修正します。
   • 各課題が、1人のエージェントが単一のタスクとして実行できる内容であることを確認します。
   • 依存関係、作業順序、並行して進められる作業を確認します。
   • 設計上の注記や判断の背景に不足があれば追加します。
   • 規模が大きすぎる課題は分割し、重複は統合し、不要な内容は削除します。
   • br の場合は、自由記述による曖昧さを避け、構造化された更新を優先します。
     • br update ... --description
     • br update ... --design
     • br update ... --acceptance-criteria
     • br update ... --notes
   • bd の場合は、インストールされているバージョンで利用可能な bd のフィールドやワークフローを使って、説明、設計、注記、受け入れ条件を記述します。

7. 実装の詳細を追加する

   • 各課題に、設計上の注記、前提条件、受け入れ条件を含めます。
   • 新しいエージェントが単一の課題に取り組めるよう、タスクを小さく明確にします。

8. 終了前にトラッカーの状態を検証する

   • br の場合は、br dep cycles --json を実行し、結果が空であることを確認してください。
   • br の同期は明示的に行う必要があることを覚えておいてください。トラッカーの状態を変更し、JSONL エクスポートを更新する必要がある場合は、br sync --flush-only を実行してください。
   • bd の場合は、インストールされているバージョンでサポートされているローカルの同期／エクスポートのワークフローに従ってください。

9. 1 回のパスで行う

   • 現在のコンテキストで、対象を絞って 1 回のパスを実行してください。
   • もう 1 回パスが必要な場合は、その旨を明示し、別のフォローアップ実行を推奨してください。

10. エージェントを再起動する

• このタスクを完了したら、そこで終了してください。セッションを小規模に保つため、次のタスクには新しいエージェントを推奨してください。

出力に関する要件

• 作成したエピックとイシューの簡潔な対応関係を示してください。
• 使用したトラッカーが bd と br のどちらかを明記してください。
• ユーザーの確認が必要な依存関係やブロッカーがあれば、明示してください。
• 計画の修正を 5 回以上求められた場合は、これ以上改善できるとは考えていないと伝えてください。