agentsclimarketplace

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)

Install
npx -y skills add thinkyou0714/claude-lab-skills --skill cursor-handoff

Assembled 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

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

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

指示書本文 フォーマット

## タスク概要
(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 — タスク状態との照合(該当ファイルに置き換えること)

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.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.