takemo101 申し送り処理ガイド (Issue Base)
本ドキュメントは、バックエンド/フロントエンド間などの領域を跨ぐ変更依頼や情報共有（申し送り）のプロセスを定義します。
変更点(v2.0): ファイル管理（JSON）を廃止し、GitHub Issueを中心としたコミュニケーションに統合しました。
1. 申し送りとは
開発中にバックエンド(BE)とフロントエンド(FE)、あるいはインフラなどの間で発生する、相互の変更依頼や情報共有のことです。
1.1 申し送りの種類
| 方向 | 種別 | ラベル | 説明 |
|---|---|---|---|
| BE→FE | API変更 | handover:api-change |
API仕様の変更通知 |
| BE→FE | エラーコード | handover:error-code |
新規エラーコードの通知 |
| FE→BE | API要望 | handover:api-request |
必要なAPIの作成依頼 |
| 共通 | 仕様変更 | handover:spec-change |
設計書自体の修正が必要な場合 |
2. 運用フロー（GitHub Issue活用）
2.1 申し送りの作成（起票者）
実装中に他領域への依頼が発生した場合、現在の作業Issueに以下のフォーマットでコメントを投稿します。 可能であれば、相手側の担当者をメンションしてください。
テンプレート:
## :mega: 申し送り事項 (Handover)
**対象領域**: [Frontend / Backend / Infra]
**種別**: [API変更 / 要望 / その他]
**優先度**: [High / Medium / Low]
### 内容
[変更や依頼の概要を簡潔に]
### 詳細・変更点
- **Before**: [変更前]
- **After**: [変更後]
### Action Required
- [ ] [具体的なタスク1]
- [ ] [具体的なタスク2]
cc: `frontend-team` skill
2.2 申し送りの検知と対応（受取手）
- 実装開始前: Issueのコメントを「Handover」や「申し送り」で検索し、未完了のチェックボックス（
- [ ]）があるか確認します。 - 対応:
- 依頼内容を実装します。
- 完了したらチェックボックスを埋めます（
- [x]）。
- 疑問点: そのコメントへの返信（Reply）で確認します。
2.3 設計書への反映（重要）
申し送り内容が「設計書」と乖離する場合、実装より先に設計書の修正が必要です。
- コメントに
spec_update_requiredと明記します。 /request-design-fixコマンドを使用して設計書の修正を依頼するか、軽微な場合は自分で修正PRを含めます。
3. シナリオ別対応
Case A: バックエンド実装中にAPIレスポンスが変わった
- BE担当: 実装修正。
- BE担当: Issueに「BE→FE申し送り」コメント投稿。
- レスポンスのDiffを貼る。
- 「FEの型定義更新をお願い」とチェックボックスを作成。
- FE担当: 実装開始時にコメント確認。型定義を更新し、チェックボックスをOnにする。
Case B: フロントエンド実装中にAPI不足に気づいた
- FE担当: 実装の手を止める（またはモックで進める）。
- FE担当: Issueに「FE→BE申し送り」コメント投稿。
- 「この画面でこのデータが必要」と具体的に記述。
- BE担当: 通知を受け取り（または翌日確認し）、APIを追加実装。完了報告。
- FE担当: API結合実装。
4. ルール
- チェックボックス必須: タスクは必ずチェックボックス形式にし、完了状態を可視化する。
- Issueを分けすぎない: 密結合な機能の場合、同じIssue内で会話する方が効率的。
- 解決しないとClose禁止: IssueをCloseする際、未消化の申し送り（未チェックの箱）がないか必ず確認する。