handover-process

takemo101's avatarfrom takemo101

バックエンド/フロントエンド間などの領域を跨ぐ変更依頼や情報共有（申し送り）のプロセスをGitHub Issue中心で定義

⭐0stars🔀0forks📁View on GitHub🕐Updated Jan 11, 2026
[SOPs and Playbooks]

When & Why to Use This Skill

This Claude skill establishes a standardized handover process between backend and frontend teams, utilizing GitHub Issues as the central communication hub. It streamlines change requests, API updates, and information sharing through structured templates and mandatory task tracking to ensure seamless cross-domain collaboration.

Use Cases

  • Coordinating API specification changes: Backend developers can use the handover template to notify frontend teams of response format updates, ensuring type definitions are synchronized.
  • Requesting new features: Frontend developers can formally request missing API endpoints or data fields by posting a handover comment in the relevant GitHub Issue.
  • Synchronizing design and implementation: The process ensures that any deviations from original designs are documented and reflected in the design specs before code changes are finalized.
  • Visual task tracking: Using mandatory checkboxes within Issue comments to track the status of cross-team dependencies and prevent premature closing of tasks.
namehandover-process
descriptionバックエンド/フロントエンド間などの領域を跨ぐ変更依頼や情報共有（申し送り）のプロセスをGitHub Issue中心で定義

申し送り処理ガイド (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

2.2 申し送りの検知と対応（受取手）

  1. 実装開始前: Issueのコメントを「Handover」や「申し送り」で検索し、未完了のチェックボックス（- [ ]）があるか確認します。
  2. 対応:
    • 依頼内容を実装します。
    • 完了したらチェックボックスを埋めます（- [x]）。
  3. 疑問点: そのコメントへの返信（Reply）で確認します。

2.3 設計書への反映（重要）

申し送り内容が「設計書」と乖離する場合、実装より先に設計書の修正が必要です。

  1. コメントに spec_update_required と明記します。
  2. /request-design-fix コマンドを使用して設計書の修正を依頼するか、軽微な場合は自分で修正PRを含めます。

3. シナリオ別対応

Case A: バックエンド実装中にAPIレスポンスが変わった

  1. BE担当: 実装修正。
  2. BE担当: Issueに「BE→FE申し送り」コメント投稿。
    • レスポンスのDiffを貼る。
    • 「FEの型定義更新をお願い」とチェックボックスを作成。
  3. FE担当: 実装開始時にコメント確認。型定義を更新し、チェックボックスをOnにする。

Case B: フロントエンド実装中にAPI不足に気づいた

  1. FE担当: 実装の手を止める（またはモックで進める）。
  2. FE担当: Issueに「FE→BE申し送り」コメント投稿。
    • 「この画面でこのデータが必要」と具体的に記述。
  3. BE担当: 通知を受け取り（または翌日確認し）、APIを追加実装。完了報告。
  4. FE担当: API結合実装。

4. ルール

  1. チェックボックス必須: タスクは必ずチェックボックス形式にし、完了状態を可視化する。
  2. Issueを分けすぎない: 密結合な機能の場合、同じIssue内で会話する方が効率的。
  3. 解決しないとClose禁止: IssueをCloseする際、未消化の申し送り（未チェックの箱）がないか必ず確認する。