blueprint-work-order

隔離されたサブエージェント実行用の作業指示書を、任意の GitHub issue 連携とともに生成します。

このスキルを使用するタイミング

このスキルを使用する場合...	代わりに blueprint-prp-create を使用する場合...
PRP を委任可能なサブエージェントのタスクに分割する場合	詳細な調査と検証ゲートを含む PRP 自体を作成する場合
コンテキストを最小限に抑えた、焦点を絞った TDD タスクパケットが必要な場合	包括的なコンテキスト収集済みの実装計画が必要な場合
既存の PRP から作業指示書を生成する場合（--from-prp）	作成済みの PRP を実行する場合は、代わりに blueprint-prp-execute を使用してください
GitHub issue から作業指示書を生成する場合（--from-issue）	委任前に準備状況を評価する場合は、代わりに confidence-scoring を使用してください

フラグ

フラグ	説明
--no-publish	ローカルの作業指示書のみを作成し、GitHub issue の作成をスキップします
--from-issue N	既存の GitHub issue #N から作業指示書を作成します（work-order-draft 提案 issue の場合は、パケットを取り込み、ラベルを work-order に差し替えて昇格させます）
--from-prp NAME	既存の PRP から作業指示書を作成します（コンテキストを自動入力します）

デフォルトの動作：ローカルの作業指示書と、work-order ラベル付きの GitHub issue の両方を作成します。

インタラクションモード

終了時の AskUserQuestion メニューを表示する前に、自動化設定を解決します。

bash "${CLAUDE_SKILL_DIR}/../../scripts/get-automation-config.sh"

EFFECTIVE_INTERACTION_MODE=quiet であり、かつこの呼び出しが自動化によって開始された場合（autopilot、セッションの締めくくり、drift-nudge のフォローアップなど。ユーザーが入力したスラッシュコマンドは除く）、終了時のナビゲーションメニュー（「次に何をしますか？」／「別のものを作成しますか？」など）はスキップし、安全なデフォルトを適用して、1 行の完了通知で終了します。quiet モードでスキップされるのはナビゲーションメニューのみです。書き込みを保護する確認ゲートはスキップされません。ユーザーが直接呼び出した場合は、常に完全な対話モードで動作します（明示的な意図が quiet モードより優先されます。ADR-0020 を参照）。

前提条件

• Blueprint Development が初期化されていること（docs/blueprint/ が存在する）
• 少なくとも 1 つの PRD が存在すること（--from-issue または --from-prp を使用する場合を除く）
• gh CLI が認証済みであること（--no-publish を使用する場合を除く）

---

モード：PRP から作成（--from-prp NAME）

--from-prp NAME が指定された場合：

1. PRP を読み込む：

   cat docs/prps/$NAME.md
   

2. PRP の内容を抽出する：

   • フロントマターから id、confidence score、implements の参照を解析します
   • Objective セクションを抽出します
   • Implementation Blueprint のタスクを抽出します
   • TDD Requirements を抽出します
   • Success Criteria を抽出します
   • curated-rule の参照（.claude/rules/ の項目）を記録します

3. confidence を確認する：

   • confidence が 9 未満の場合、PRP は委任できる状態ではない可能性があることを警告します
   • そのまま進めるか、PRP の改善に戻るかを確認します

4. 作業指示書を生成する：

   • PRP の内容をもとに事前入力します
   • 関連する curated rule を参照ではなく、インラインコンテキストとして含めます
   • TDD 要件をそのまま転記します
   • PRP の Codebase Intelligence セクションにあるファイル一覧を含めます

5. ステップ 6（保存と任意の公開）に進みます

モード：既存の Issue から作成（--from-issue N）

--from-issue N が指定された場合：

1. Issue を取得：

   gh issue view N --json title,body,labels,number
   

2. Issue の内容を解析：

   • タイトル／本文から目的を抽出
   • TDD 要件または成功基準があれば抽出
   • 既存のラベルを確認

2a. work-order-draft の提案を昇格する（ADR-0020 自動ドラフトチャネル）：

Issue に work-order-draft ラベルが付いている場合、これは /blueprint:autopilot による自動ドラフト提案です。本文はすでにワークオーダー一式になっています（タイトル形式は [work-order-draft] PRP-NNN: <title>）。 昇格は、人間がコミットする行為をドラフトチャネルで保持するものです。

• 一式をそのままワークオーダーの内容として使用します（ドラフト本文が手順 3 での再生成に優先します。参照先の PRP が存在し、確信度が最新であることは引き続き確認してください。9 未満に下がっている場合は警告します）
• 手順 4 でラベルも入れ替えます。 gh issue edit N --remove-label "work-order-draft" --add-label "work-order"
• 通常の保存手順（手順 6）に進みます。ローカルの WO ファイル、feature-tracker.json の tasks.pending、およびマニフェストの id_registry は、ドラフト時ではなく、ここでの昇格時に変更されます。

3. ワークオーダーを生成：

   • 番号は Issue 番号と一致させます（例：Issue #42 → ワークオーダー 042-...）
   • Issue の内容をあらかじめ反映します
   • コンテキストのセクション（ファイル、PRD 参照など）を追加します

4. リンクを付けて Issue を更新：

   gh issue comment N --body "Work-order created: \`docs/blueprint/work-orders/NNN-task-name.md\`"
   # Ensure the label exists before applying it
   if ! gh label list --search "work-order" --json name | jq -e '.[] | select(.name=="work-order")' >/dev/null 2>&1; then
     gh label create work-order --description "AI-assisted work order" --color "0E8A16"
   fi
   gh issue edit N --add-label "work-order"
   

5. 保存と報告を続行（以下の手順 6 に進みます）

---

モード：新しいワークオーダーを作成（デフォルト）

手順 1：現在の状態を分析する

• docs/blueprint/feature-tracker.json を読み、現在のフェーズとタスクを確認します
• git status を実行して、未コミットの作業を確認します
• git log -5 --oneline を実行して、最近の作業を確認します
• 既存のワークオーダーを探します（番号付けのために数えます）

手順 2：関連する PRD を読む

• PRD ファイルを読み、要件を把握します
• 以下をもとに、次に実施する論理的な作業単位を特定します。
  • 作業概要の進捗
  • PRD のフェーズ／セクションの順序
  • Git の履歴（完了した作業）

手順 3：次の作業単位を決める

以下を満たす必要があります。

• 具体的：単一の機能／コンポーネント／修正
• 独立している：依存関係が最小限
• テスト可能：明確な成功基準
• 焦点が絞られている：作業時間は 1～4 時間

良い例：

• 「JWT トークン生成メソッドを実装する」
• 「登録エンドポイントに入力検証を追加する」
• 「users テーブル用のデータベースマイグレーションを作成する」

悪い例（範囲が広すぎる）：

• 「認証を実装する」
• 「バグを修正する」

手順 4：必要最小限のコンテキストを決める

• 変更／作成するファイル（関連するものだけ）
• PRD のセクション（このタスクに固有の要件だけ）
• 既存のコード（関連する抜粋だけ。ファイル全体ではありません）
• 依存関係（外部ライブラリ、環境変数）

手順 5：ワークオーダーを生成する

• 番号：既存のワークオーダーの最大番号に 1 を加えます（001、002 など）
• 名前：NNN-brief-task-description.md

ワークオーダーの構成：

name: blueprint-work-order
---
id: WO-NNN
created: {YYYY-MM-DD}
status: pending
implements:                    # Source PRP or PRD
  - PRP-NNN
relates-to:                    # Related documents
  - ADR-NNNN
github-issues:
  - N
---

# Work-Order NNN: [Task Name]

**ID**: WO-NNN
**GitHub Issue**: #N
**Status**: pending

## Objective
[One sentence describing what needs to be accomplished]

## Context

### Required Files
[Only files needed - list with purpose]

### PRD Reference
[Link to specific PRD section, not entire PRD]

### Technical Decisions
[Only decisions relevant to this specific task]

### Existing Code
[Only relevant code excerpts needed for integration]

## TDD Requirements

### Test 1: [Test Description]
[Exact test to write, with code template]
**Expected Outcome**: Test should fail

### Test 2: [Test Description]
[Exact test to write]
**Expected Outcome**: Test should fail

[More tests as needed]

## Implementation Steps

1. **Write Test 1** - Run: `[test_command]` - Expected: **FAIL**
2. **Implement Test 1** - Run: `[test_command]` - Expected: **PASS**
3. **Refactor (if needed)** - Run: `[test_command]` - Expected: **STILL PASS**
[Repeat for all tests]

## Success Criteria
- [ ] All specified tests written and passing
- [ ] [Specific functional requirement met]
- [ ] [Performance/security baseline met]
- [ ] No regressions (existing tests pass)

## Notes
[Additional context, gotchas, considerations]

## Related Work-Orders
- **Depends on**: Work-Order NNN (if applicable)
- **Blocks**: Work-Order NNN (if applicable)

手順 6：ワークオーダーを保存する

docs/blueprint/work-orders/NNN-task-name.md に保存します 番号はゼロ埋めにします（001、002、010、100）

手順 7：GitHub Issue を作成する（--no-publish が指定されていない場合）

gh issue create \
  --title "[WO-NNN] [Task Name]" \
  --body "## Work Order: [Task Name]

**ID**: WO-NNN
**Local Context**: \`docs/blueprint/work-orders/NNN-task-name.md\`

### Related Documents
- **Implements**: {PRP-NNN or PRD-NNN}
- **Related ADRs**: {list of ADR-NNNN}

### Objective
[One-line objective from work order]

### TDD Requirements
- [ ] Test 1: [description]
- [ ] Test 2: [description]

### Success Criteria
- [ ] [Criterion 1]
- [ ] [Criterion 2]

---
*AI-assisted development work order. See linked file for full execution context.*" \
  --label "work-order"

Issue 番号を取得し、ワークオーダーファイルを更新します。

# Extract issue number from gh output
gh issue create ... 2>&1 | grep -oE '#[0-9]+' | head -1

ワークオーダーファイルの **GitHub Issue**: 行を Issue 番号で更新します。

手順 8：docs/blueprint/feature-tracker.json を更新する

新しいワークオーダーを保留中のタスクに追加します。

jq '.tasks.pending += [{"id": "WO-NNN", "description": "[Task name]", "source": "PRP-NNN", "added": "YYYY-MM-DD"}]' \
  docs/blueprint/feature-tracker.json > tmp.json && mv tmp.json docs/blueprint/feature-tracker.json

手順 8.5：マニフェストを更新する

docs/blueprint/manifest.json の ID レジストリを更新します。

{
  "id_registry": {
    "documents": {
      "WO-NNN": {
        "path": "docs/blueprint/work-orders/NNN-task-name.md",
        "title": "[Task Name]",
        "implements": ["PRP-NNN"],
        "github_issues": [N],
        "created": "{date}"
      }
    },
    "github_issues": {
      "N": ["WO-NNN", "PRP-NNN"]
    }
  }
}

ソースの PRP／PRD も更新し、追跡対象にこのワークオーダーを追加します。

手順 9：報告する

Work-order created!

ID: WO-NNN
Work-Order: 003-jwt-token-generation.md
Location: docs/blueprint/work-orders/003-jwt-token-generation.md
GitHub Issue: #42 (or "Local only" if --no-publish)

Traceability:
- Implements: PRP-002 (OAuth Integration)
- Related: ADR-0003 (Session Storage)

Objective: [Brief objective]

Context included:
- Files: [List files]
- Tests: [Number of tests specified]
- Dependencies: [Key dependencies]

Ready for execution:
- Can be executed by subagent with isolated context
- TDD workflow enforced (tests specified first)
- Clear success criteria defined
- PR should use "Fixes #42" to auto-close issue
- Commit messages should use: feat(WO-NNN): description

手順 10：次のアクションを尋ねる

AskUserQuestion を使用します。

question: "Work-order ready. What would you like to do?"
options:
  - label: "Execute this work-order (Recommended)"
    description: "Start working on the task with TDD workflow"
  - label: "Create another work-order"
    description: "Generate the next task from pending items"
  - label: "Delegate to subagent"
    description: "Hand off for isolated execution"
  - label: "I'm done for now"
    description: "Exit - work-order is saved and ready"

選択内容に応じて：

• 「このワークオーダーを実行する」→ ワークオーダーのコンテキストを使って /project:continue を実行します
• 「別のワークオーダーを作成する」→ /blueprint:work-order を再度実行します
• 「サブエージェントに委任する」→ サブエージェントによる実行の引き継ぎ手順を提示します
• 「完了」→ 終了します

主な原則

• コンテキストを最小限に：ファイルや PRD 全体ではなく、必要なものだけを含めます
• 具体的なテスト：曖昧な説明ではなく、正確なテストケースを指定します
• TDD を徹底：実装の前にテストを指定します
• 明確な基準：成功条件を曖昧さのないチェックボックスで示します
• 独立性：タスクは、提供されたコンテキストだけで実行できるようにします
• 透明性：GitHub の issue によって、コラボレーターが状況を把握できます

---

エラー処理

条件	対応
PRD が存在しない	まず PRD を作成するよう案内します
feature-tracker にタスクがない	現在のフェーズやステータスを尋ねます
タスクが不明確	次に何に取り組むかをユーザーに尋ねます
gh が認証されていない	警告し、--no-publish の動作に切り替えます
issue にすでに work-order ラベルが付いている	警告し、更新するか新規作成するか尋ねます

GitHub 連携に関する注意事項

完了までの流れ

1. work-order の作業を完了します
2. 本文またはタイトルに Fixes #N を含めて PR を作成します
3. work-order を completed/ ディレクトリに移動します
4. PR がマージされると issue は自動的にクローズされます

ラベルの規則

work-order ラベルは、このワークフローで作成された issue を識別します。存在しない場合は、リポジトリに作成してください：

gh label create work-order --description "AI-assisted work order" --color "0E8A16"

オフラインモード

次の場合は --no-publish を使用します：

• オフラインで作業している場合
• 非公開で試行している場合
• issue を公開する必要がない場合

後から issue を手動で作成し、work-order ファイルを更新すれば公開できます。