backlog-subtasks

name	backlog-subtasks
description	Backlog の親チケットから子チケット群を規約に沿って起票する。「子チケット作って」「チケット分割して」「Backlog に起票」「サブタスク切って」等で発火。AITENCHO_PRD の実チケットから抽出した命名・本文構造・粒度・属性の規約に従う。起票前に必ず分割案をユーザーに提示して承認を得る。

Backlog 子チケット起票

AITENCHO_PRD の実運用から抽出した規約。他プロジェクトでも同じ型を既定とし、そのプロジェクトの既存チケットに別の慣習があればそちらを優先する。

ワークフロー（順守）

1. 親チケットを読む: get_issue で親の本文・既存の子 (get_issues + parentIssueId) を取得。親に「想定サブタスク」チェックリストがあればそれがたたき台。
2. 重複検索: get_issues + keyword で類似チケットを検索。重複起票は 【重複/無効 →】 で潰される文化なので起票前に必ず確認。
3. 分割案をユーザーに提示して承認を得る（タイトル一覧 + 各1行概要 + 依存順序）。承認前に add_issue を呼ばない。
4. 承認後に起票。子には parentIssueId を設定。起票後、親の本文のチェックリストに子チケットの URL を追記する（update_issue）か、追記案を提示。

タイトル規約

• 形: [scope] 対象: 内容/症状 — 対応 (env)。体言止め。実装系 30〜60字。
• [scope] は [edge] [backend] [ci] [infra依頼] [Edge/FE] 等。カテゴリ属性は使わずタイトルで表す。
• 親は 【親】、子は 【子】 【子2】〜連番を [scope] の前に付ける（親の既存の子の命名に合わせる）。
• 環境や Phase は末尾括弧: (staging / develop) (Phase1)。
• バグ例: [backend] device heartbeat / resources が 500 INTERNAL_ERROR（tenant_id NOT NULL 未追従）→ 端末がダッシュボードでオフライン誤表示

本文規約（## 見出し、markdown）

子チケットの型:

親: AITENCHO_PRD-639 / 依存: 子3・子4 完了後
（依存が無ければ「依存: なし」ごと省略）

## 背景 / 目的
1〜3行。親の要約コピペではなく、この子が何を解決するかだけ。

## 実装方針
- 対象ファイル・resource 名・API 名を具体的に書く（例: `modules/iot/main.tf` の `edge_s3_upload` と同じ書き方で）
- 既存コードの雛形アンカーを必ず1つ入れる（例: 既存 `detect-qc-menu-inconsistency` を雛形に）
- 既知の制約を明記（例: IoT policy 2048 byte 上限）

## 完了条件
- [ ] 検証可能な条件（「clippy / test green」「staging で Slack 通知が届く」等）
- [ ] 動作確認の具体手順が書けるレベルまで落とす

## 非対象（Out of Scope）
- 別チケットに逃がすものを明示（無ければ節ごと省略）

親チケットを新規に作る場合の型: ## 背景 / 目的 → ## スコープ → ## 想定サブタスク（子チケットのたたき台）(チェックリスト) → ## 補足。親は実装詳細を確定させず「たたき台。確定は子チケットで」と明示。

禁止: 本文ゼロ・スクショだけの起票 / 対象ファイルも受け入れ条件も無い網羅的箇条書きだけの本文 / 親本文の丸写し。

粒度

• 子1個 = 1人が1〜2日で完結する単位。
• 分割軸は工程×レイヤーの混合が慣習: SQL設計 / batch 実装 / notifier / infra デプロイ / 動作確認、または BE / モックUI / 繋ぎ込み（担当者別）。
• 動作確認・デプロイも独立した子にする。
• 5個を超える分割になりそうなら、まず統合子1個（全工程チェックリスト入り）を置いて後から展開する案も提示。

属性

属性	既定
種別	タスク（障害のみ バグ）
優先度	中（障害・ブロッカーのみ 高。「低」は使わない）
カテゴリ	未設定（タイトルの [scope] が代替）
マイルストーン	未設定（PM の計画チケットのみ設定するので勝手に付けない）
期日	未設定
担当	ユーザーに確認して個人アサイン（不明なら未設定で起票し、その旨報告）

文体

チケットは外向き発信。ギャル口調・絵文字は使わず、簡潔な業務文体で書く。