タスクを作成・紐づけ・開始する。コーディング前に必ずこのコマンドを実行すること。
ユーザーの入力 $ARGUMENTS をもとに、以下の手順を 順番通り・省略なし で実行してください。
入力内容を分析し、該当するワークフローを1つ選択する:
| # | 条件 | ワークフロー |
|---|---|---|
| 1 | 機能追加/変更/削除で DR が必要 | DR作成 → タスク作成 → リンク → 開始 |
| 2 | バグ・問題対応で Issue が関連 | Issue作成(必要なら) → タスク作成 → リンク → 開始 |
| 3 | リスク緩和で既存 Risk が関連 | タスク作成 → リンク → 開始 |
| 4 | 既存タスクID が指定されている | そのタスクで開始 |
| 5 | DR 改訂（既存 DR の supersede） | DR作成(supersedes) → タスク作成 → リンク → 開始 |
| 6 | 設計ドキュメント作成（スキーマ設計・API仕様・画面設計など） | 設計Doc作成 → タスク作成 → リンク → 開始 |
DR vs 設計ドキュメントの判定基準:
判定に迷う場合はユーザーに確認する。
upsert_dr(projectId, title, context, decision, alternatives, consequences, ...) を実行
supersedes パラメータを指定id と number を記録add_design_doc(projectId, title, body, status?) を実行
body にフル Markdown で設計仕様を記述（必須）status は省略で accepted（デフォルト）supersedes パラメータを指定id と number を記録upsert_issue(projectId, title, category, severity, description) を実行
## 問題 / ## 影響 / ## 対応箇所 を含めるlist_issues で特定id と number を記録list_risks で対象リスクを特定id と number を記録start_work(taskId) を実行して Step 1.5 へ進む（Step 4 ではない）タスクの内容が既存の設計ドキュメントに影響するかを確認する。
list_drs(projectId, type='design') で設計ドキュメント一覧を取得| 変更の規模 | 方法 | 手順 |
|---|---|---|
| 小規模（typo修正、数値更新、小さな追記） | upsert_dr(body) | get_dr → body 修正 → upsert_dr(drId, body) |
| 大規模（セクション追加/削除、構造変更） | add_design_doc(supersedes) | 新版を作成、旧版は自動で superseded |
| 設計方針の根本変更 | 新 DR + add_design_doc(supersedes) | 意思決定を DR に記録してから設計Doc を新版作成 |
id を記録（Step 3 でタスクとリンクする）ワークフロー #4（既存タスク）の場合: Step 1.5 完了後、Step 4 へスキップする。 ワークフロー #6（設計Doc新規作成）の場合: 新規作成なので通常スキップ。ただし他の既存設計Docへの影響があれば確認する。
list_deliverables(projectId) で紐付け先の成果物を確認list_phases(projectId) で active Phase を確認。active Phase があればその id を phaseId として使用するupsert_task(projectId, title, deliverableId, description, phaseId?) を実行
## 背景 — なぜこのタスクが必要か## 対応内容 — 何をするか（箇条書き）## 完了条件 — チェックリスト形式id を記録作成したタスクの description を以下の観点でセルフチェックし、不足があればユーザーに提案する。 強制ブロックではなくガイド形式（ユーザーが「不要」と判断すればスキップ可能）。
| チェック観点 | 確認内容 | 不足時の提案例 |
|---|---|---|
| 背景 | ## 背景 セクションがあり、「なぜやるか」が書かれているか | 「背景が未記入です。このタスクが必要な理由を追記しますか？」 |
| 対応内容の具体性 | ## 対応内容 が箇条書きで具体的か。「〜を改善する」「〜を対応する」のような曖昧表現のみになっていないか | 「対応内容が抽象的です。具体的な変更箇所・操作を追記しますか？」 |
| 完了条件 | ## 完了条件 がチェックリスト形式で、検証可能（Yes/No で判定できる）か | 「完了条件が未記入です。どうなったら完了かを追記しますか？」 |
| 制約 | やらないこと・スコープ外が明記されているか（任意だが推奨） | 「制約（やらないこと）の明記を推奨します。スコープの膨張を防げます。追記しますか？」 |
upsert_task(taskId, description) で更新前提エンティティとタスクを紐づける:
| ワークフロー | create_link パラメータ |
|---|---|
| #1 / #5 | sourceType: "dr", sourceId: <drId>, targetType: "task", targetId: <taskId>, linkType: "implements" |
| #2 | sourceType: "issue", sourceId: <issueId>, targetType: "task", targetId: <taskId>, linkType: "resolves" |
| #3 | sourceType: "risk", sourceId: <riskId>, targetType: "task", targetId: <taskId>, linkType: "mitigates" |
| #6 | sourceType: "dr", sourceId: <designDocId>, targetType: "task", targetId: <taskId>, linkType: "implements" |
Step 1.5 で設計ドキュメントを更新した場合は、そのドキュメントもタスクにリンクする:
| 条件 | create_link パラメータ |
|---|---|
| 設計Doc を更新/新版作成した | sourceType: "dr", sourceId: <designDocId>, targetType: "task", targetId: <taskId>, linkType: "implements" |
create_link(projectId, sourceType, sourceId, targetType, targetId, linkType) を実行。
start_work(taskId) を実行。返却されるプロジェクトコンテキスト（counts, alerts）を確認し、重要なアラートがあればユーザーに報告する。relatedDeliverable.status が draft の場合 → upsert_deliverable(deliverableId, status: 'in_progress') を実行して成果物を着手状態にする。get_issue(issueId) で現在の状態を確認するownerId が既に設定されていて自分以外の場合 → ユーザーに「既に {ownerName} が担当しています。上書きしますか？」と確認。承認されなければスキップstatus が in_progress の場合 → ユーザーに「既に対応中です。続行しますか？」と確認。承認されなければスキップupsert_issue(issueId, ownerId: <auth.userId>) で担当者を設定status が open の場合のみ → upsert_issue(issueId, status: 'in_progress') で着手状態にするget_risk(riskId) で現在の状態を確認するownerId が既に設定されていて自分以外の場合 → ユーザーに「既に {ownerName} が担当しています。上書きしますか？」と確認。承認されなければスキップupsert_risk(riskId, ownerId: <auth.userId>) で担当者を設定以下がすべて満たされていること:
すべて完了したら以下を報告する:
セットアップ完了。ブランチを作成してコーディングを開始してください。
ブランチ名: task/<number>-<slug>
※ /start-task 内で git 操作（ブランチ作成・push 等）は行わない。ポータビリティ維持のため、ブランチ作成はエンジニアまたはプロジェクト固有のルール（CLAUDE.md）に委ねる。