Cursor handoff
Skill thinkyou0714/claude-lab-skills/lab-implementation-flow/skills/cursor-handoff
THINK YOU LAB thinking-OS skills for Claude Code — reusable judgment/design/automation/communication skill packs (tech-agnostic, MIT)
npx -y skills add thinkyou0714/claude-lab-skills --skill cursor-handoffAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
implementation-gate 通過後の情報を、施工AI(Cursor 等)が実行可能な指示書形式に変換する。ゲート通過前には使わない。
SKILL.md
7.5 KB, ~2.8k tokens by cl100k_base, as published. Nobody here has run it
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
以下の順で出力すること。順序を変えない。
- 論点: この handoff で最も注意が必要なポイント(施工AI が誤解しやすい箇所)
- 根拠: その論点をそう判断した理由
- ゲート確認: implementation-gate の結果を要約(通過・条件付き・ブロックのどれか)
- 含意: 指示書の不備が引き起こすリスク
- 指示書本文: 施工AI向けの実行可能な指示書(後述フォーマット)
- 代替スコープ: 全条件が揃わない場合に着手できる限定スコープ案
- 判断材料: 「この指示書で委譲する / 修正してから委譲する / 委譲しない」を選ぶための情報
指示書本文 フォーマット
## タスク概要
(1〜3文。何を、なぜ、どの状態にするか)
## 実行範囲
(触ってよいファイル・関数・DB テーブルのリスト)
## 禁止範囲
(触ってはいけないファイル・関数・DB・インフラのリスト)
## 完了条件
(何がどの状態になれば完了か。テストで確認できる形で書く)
## 失敗条件
(何が起きたら実装を中断すべきか)
## テスト手順
(完了条件の確認方法。コマンドまたは手動確認ステップ)
## ロールバック手順
(失敗時の戻し方。git コマンドまたは手動手順)
## 注意事項
(設計上の制約・既存コードとの整合・依存関係など)
Review Lens
- 目的妥当性: 指示書の粒度が施工AI が単独で実行できる水準に達しているか
- 範囲の過不足: 実行範囲と禁止範囲の両方が明示されているか
- 中長期リスク: 指示書の曖昧さが施工AI の過剰実装や誤実装につながらないか
- LAB全体との整合性: 実行範囲が
implementation-gateのチェック結果と一致しているか - 非エンジニア理解可能性: 完了条件・失敗条件が技術者以外にも確認できる形か
- 他LLM移植耐性: 指示書フォーマットが特定の AI ツールに依存した記法を含んでいないか
Instructions
implementation-gateの出力を読み込み、着手可・条件付き・ブロックのいずれかを確認する- ブロック状態の場合は指示書生成を中止し、gate へ差し戻す
- タスク概要を「何を / どのファイルで / どの状態にする」の形式に整理する
- 実行範囲は具体的なファイルパス・関数名レベルで列挙する
- 禁止範囲は「不明」を許容しない。不明な場合は「不明(確認が必要)」と明示する
- 完了条件はテストコマンドまたは手動確認ステップとして書く(「動けばOK」は不可)
- 最終判断(委譲するかどうか)は人間に委ねる
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-gateskill — handoff 前のゲートチェック(本 Skill の前提)rollback-planskill — ロールバック手順の詳細設計change-impact-scanskill — 影響範囲の深掘りtest-scope-definitionskill — テスト手順の設計- プロジェクトの TASKS.md — タスク状態との照合(該当ファイルに置き換えること)
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most agent orchestration skills give in ~2.8k tokens
Counted across 742 of the 995 authors here whose files we hold, read 2026-08-07
- reference existing artifacts by path or URLin 53 of 742, across 25 files
- run the full test suite after integrating changesin 51 of 742, across 19 files
- dispatch one agent per independent problem domainin 50 of 742, across 17 files
- verify fixes do not conflictin 45 of 742, across 13 files
- include a suggested skills section in the documentin 45 of 742, across 17 files
- redact sensitive informationin 41 of 742, across 11 files
- save to the temporary directory of the operating systemin 39 of 742, across 10 files
- tailor the document to user-provided focus argumentsin 39 of 742, across 9 files
- spot check agent changes for systematic errorsin 34 of 742, across 7 files
- write a handoff document summarising the current conversationin 31 of 742, across 6 files
- Assign each agent a specific scopein 23 of 742, across 8 files
- provide specific scope and clear goalin 23 of 742, across 5 files
Said here and by no other author read
- verify gate status before generating instructions
- abort and return to gate if status is blocked
- state missing inputs explicitly without assuming
- enumerate execution scope to specific file paths and functions
- write completion criteria as test commands or manual steps
- leave the final decision to delegate to a human
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.