# Cursor Handoff

> implementation-gate 通過後の情報を、施工AI（Cursor 等）が実行可能な指示書形式に変換する。ゲート通過前には使わない。

- Skill: `thinkyou0714/cursor-handoff` (Agent Skill)
- Install (CLI): `npx skillmds@latest add thinkyou0714/cursor-handoff`
- Raw SKILL.md: https://api.skillmd.com/api/skills/thinkyou0714/cursor-handoff/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: thinkyou0714 (https://skillmd.com/u/thinkyou0714)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/thinkyou0714/cursor-handoff

---


## Purpose

`implementation-gate` が「着手可」を宣言した後、人間が手動で施工AIへの指示を組み立てる工程を構造化する。
指示の抜け・粒度不足・コンテキスト不足を防ぎ、施工AIへの handoff 品質を標準化する。

## Use When

- `implementation-gate` が「着手可」または「条件付き着手」を宣言した直後
- 施工AI（Cursor / GitHub Copilot / 他 AI コーディングアシスタント）にタスクを委譲する前
- 過去に「施工AIが意図と違う実装をした」経験があるタスクの開始前

## Use When NOT

- `implementation-gate` を通過していない場合 → `implementation-gate` を先に使う
- 要件・設計がまだ確定していない場合 → `implementation-gate` または `scope-design` を先に使う
- ロールバック方針が未定義の場合 → `rollback-plan` を先に使う

## Inputs

以下を準備すること。不足している場合は推測せず、不足を明示する。

- **implementation-gate の出力**: ゲートチェック結果（着手可判定と条件の記録）
- **タスク概要**: 実装する機能・修正の説明（1〜3文）
- **対象ファイル・関数**: 実装範囲の具体的なパスとシグネチャ
- **禁止範囲**: 触ってはいけないファイル・DB・機能のリスト
- **完了条件**: 何がどの状態になれば完了か（テスト可能な形で）
- **ロールバック手順**: 実装が失敗した場合の戻し方

## Output Contract

以下の順で出力すること。順序を変えない。

1. **論点**: この handoff で最も注意が必要なポイント（施工AI が誤解しやすい箇所）
2. **根拠**: その論点をそう判断した理由
3. **ゲート確認**: implementation-gate の結果を要約（通過・条件付き・ブロックのどれか）
4. **含意**: 指示書の不備が引き起こすリスク
5. **指示書本文**: 施工AI向けの実行可能な指示書（後述フォーマット）
6. **代替スコープ**: 全条件が揃わない場合に着手できる限定スコープ案
7. **判断材料**: 「この指示書で委譲する / 修正してから委譲する / 委譲しない」を選ぶための情報

### 指示書本文 フォーマット

```text
## タスク概要
（1〜3文。何を、なぜ、どの状態にするか）

## 実行範囲
（触ってよいファイル・関数・DB テーブルのリスト）

## 禁止範囲
（触ってはいけないファイル・関数・DB・インフラのリスト）

## 完了条件
（何がどの状態になれば完了か。テストで確認できる形で書く）

## 失敗条件
（何が起きたら実装を中断すべきか）

## テスト手順
（完了条件の確認方法。コマンドまたは手動確認ステップ）

## ロールバック手順
（失敗時の戻し方。git コマンドまたは手動手順）

## 注意事項
（設計上の制約・既存コードとの整合・依存関係など）
```

## Review Lens

- **目的妥当性**: 指示書の粒度が施工AI が単独で実行できる水準に達しているか
- **範囲の過不足**: 実行範囲と禁止範囲の両方が明示されているか
- **中長期リスク**: 指示書の曖昧さが施工AI の過剰実装や誤実装につながらないか
- **LAB全体との整合性**: 実行範囲が `implementation-gate` のチェック結果と一致しているか
- **非エンジニア理解可能性**: 完了条件・失敗条件が技術者以外にも確認できる形か
- **他LLM移植耐性**: 指示書フォーマットが特定の AI ツールに依存した記法を含んでいないか

## Instructions

1. `implementation-gate` の出力を読み込み、着手可・条件付き・ブロックのいずれかを確認する
2. ブロック状態の場合は指示書生成を中止し、gate へ差し戻す
3. タスク概要を「何を / どのファイルで / どの状態にする」の形式に整理する
4. 実行範囲は具体的なファイルパス・関数名レベルで列挙する
5. 禁止範囲は「不明」を許容しない。不明な場合は「不明（確認が必要）」と明示する
6. 完了条件はテストコマンドまたは手動確認ステップとして書く（「動けばOK」は不可）
7. 最終判断（委譲するかどうか）は人間に委ねる

## Guardrails

- `implementation-gate` の結果を確認せずに指示書を生成しない
- 「たぶんこうすればよい」という推測を指示書に含めない
- 実行範囲外のファイルを指示書に含めない
- 禁止範囲を省略しない（不明な場合は「不明」と明示する）
- 施工AI の具体的な実装手法（アルゴリズム選択等）を指示書で決定しない
- 最終判断（委譲するかどうか）は人間に委ねる

## Failure Modes

| Failure Mode | 対応 |
|---|---|
| `implementation-gate` を通過していない | gate を先に実行するよう求める。指示書は生成しない |
| 対象ファイルが具体的なパスレベルで不明 | 指示書生成不可を宣言し、対象特定を先行タスクにする |
| ロールバック方針が未定義 | `rollback-plan` を先に実行するよう求める |
| 禁止範囲が指定されていない | 「禁止範囲不明」として指示書に明記し、人間の確認を求める |
| 完了条件がテスト不可能な形で記述されている | テスト可能な形に書き直すよう求める |

## LAB Cross-Check

| 観点 | 状態 | 備考 |
|---|---|---|
| 自動化フロー | — | 自動化タスクの handoff 時は禁止範囲に本番フロー定義が含まれているか |
| データ / 認証 / ログ | — | DB・RLS 変更を含む場合は `auth-boundary-check` との連携が推奨されているか |
| 実装 / 運用フロー | — | `implementation-gate` 通過が前提として確認されているか |
| 非エンジニア理解可能性 | — | 施工AI向け指示書は技術的記述が主。非エンジニアへの説明には `stakeholder-translation` が別途必要 |
| 会員共有 / 再利用耐性 | — | 指示書テンプレートからプロジェクト固有の名称が分離されているか |
| 他LLM移植耐性 | — | 指示書フォーマットが Cursor 固有の記法（@参照等）に依存していないか |

状態は OK / 注意 / NG / 対象外 で記入すること。

## Handoff Notes

施工AIへの委譲後、以下を記録しておくこと。

- **委譲日時**: いつ委譲したか
- **委譲先**: どの AI・セッションに委譲したか
- **指示書バージョン**: この handoff で使用した指示書の内容（git 管理推奨）
- **確認タイミング**: 完了確認をいつ行うか
- **エスカレーション条件**: 施工AIが判断できない状況が起きた場合の連絡方法

## Further Reading

- `implementation-gate` skill — handoff 前のゲートチェック（本 Skill の前提）
- `rollback-plan` skill — ロールバック手順の詳細設計
- `change-impact-scan` skill — 影響範囲の深掘り
- `test-scope-definition` skill — テスト手順の設計
- プロジェクトの TASKS.md — タスク状態との照合（該当ファイルに置き換えること）