Token导航 LogoToken导航TokenDH.com
开发敏感数据github未标认证来源可访问许可证需确认审计通过

handoff交接

Agent Skill

handoff 用于处理 GitHub 仓库、Issue、Pull Request 和代码协作信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要围绕仓库状态、代码变更或协作事项进行整理时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

380

周安装

16

GitHub Stars

83

下载量

133
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:handoff(交接)
来源仓库:https://github.com/robertguss/claude-code-toolkit
仓库路径:skills/handoff
安装命令:
npx skills add https://github.com/robertguss/claude-code-toolkit --skill handoff
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/robertguss/claude-code-toolkit --skill handoff

简介

handoff 用于处理 GitHub 仓库、Issue、Pull Request 和代码协作信息。

  • 适合在开发流程中围绕仓库状态、代码变更或协作事项进行整理。
  • 支持在 Codex、Claude、Cursor、Gemini CLI 等宿主环境中使用。
  • 安装前应核实维护状态及是否涉及敏感操作如命令执行或文件写入。
  • handoff 属于开发类 Skill,可作为该场景下的辅助能力补充。

SKILL.md

Session Handoff Skill

Create structured documents that enable seamless continuity across Claude sessions.

When to Use

  • Ending a work session for the day
  • Before taking a break mid-task
  • Switching to a different project temporarily
  • When you want to capture state for a future session
  • Before a context reset you know is coming

Handoff Process

Step 1: Assess Session State

Quickly assess:

  1. What phase are we in? (exploration, planning, implementation, debugging, review)
  2. What's the active task? (what we're trying to accomplish)
  3. How far along are we? (just started, mid-way, almost done)

Step 2: Ask What Matters

Ask the user:

"I'll create a handoff document. Is there anything specific you want to make sure I capture? (Key decisions, code snippets, context about the problem, things you'll forget, etc.)"

Step 3: Generate Handoff Document

Create a structured document:

# Session Handoff: [Brief Description]

**Date:** [YYYY-MM-DD] **Project:** [project name/path] **Session Duration:**
[approximate]

## Current State

**Task:** [What we're working on] **Phase:**
[exploration/planning/implementation/debugging/review] **Progress:** [where we
are - percentage or milestone]

## What We Did

[2-3 sentence summary of the session's work]

## Decisions Made

- **[Decision]** — [Rationale]
- **[Decision]** — [Rationale]

## Code Changes

**Files modified:**

- `path/to/file.ts` — [what and why]
- `path/to/other.ts` — [what and why]

**Key code context:** [Critical snippets or patterns to remember]

## Open Questions

- [ ] [Question needing resolution]
- [ ] [Question needing resolution]

## Blockers / Issues

- [Issue] — [current status]

## Context to Remember

[Important background, constraints, user preferences, domain knowledge - things
that would take time to re-establish]

## Next Steps

1. [ ] [First thing to do next session]
2. [ ] [Second thing]
3. [ ] [Third thing]

## Files to Review on Resume

- `path/to/key/file.ts` — [why it matters]

Step 4: Write the File

Write to: .claude/handoffs/[YYYY-MM-DD]-[brief-description].md

Confirm location with user:

"I'll save this to .claude/handoffs/[filename].md. Want a different location?"

What to Capture

Always Include

  1. Decisions with reasoning — The "why" is often more valuable than the "what"
  2. Code changes — File paths, what changed, the intent
  3. Current progress — Where in the task we stopped
  4. Next steps — Clear, actionable items to resume with
  5. User context — Constraints, preferences, domain knowledge they shared

Include When Relevant

  • Errors encountered — And how they were (or weren't) resolved
  • Dead ends — Approaches tried that didn't work (saves re-exploration)
  • Key files — Files to read to get back up to speed
  • External dependencies — APIs, services, tools involved

Skip

  • Verbose tool output (file listings, grep results)
  • Intermediate reasoning that reached conclusions
  • Repeated similar operations
  • Information that's obvious from the code

Format Guidelines

  • Bullet points — Scannable over narrative
  • File pathssrc/foo.ts:42 not "that function"
  • Checkboxes for actions- [] for next steps and open questions
  • Specifics — "Added retry logic to fetchUser()" not "made improvements"

Quality Check

Before saving, verify:

  1. Could a fresh Claude pick up from this? — Enough context to continue?
  2. Are decisions traceable? — Clear why things were decided?
  3. Are next steps actionable? — Know exactly what to do first?
  4. Is code work clear? — Know which files matter?

Using a Handoff Document

When starting a new session, the user can:

  1. Share the handoff file at session start
  2. Say "Resume from this handoff: [paste or path]"
  3. Reference it with @ mention if supported

The handoff should let you hit the ground running without lengthy re-explanation.

Example Handoff

# Session Handoff: Auth System Implementation

**Date:** 2025-01-15 **Project:** /Users/robert/projects/my-api **Session
Duration:** ~2 hours

## Current State

**Task:** Implementing user authentication for the API **Phase:** Implementation
**Progress:** ~60% - basic flow works, need refresh tokens

## What We Did

Built the core JWT authentication flow including token generation, validation
middleware, and login/logout endpoints. Hit an issue with key rotation that we
resolved by moving to config-based key paths.

## Decisions Made

- **JWT with RS256** — Stateless auth, works with distributed setup
- **Redis for refresh tokens** — Need revocation capability
- **15-min access token expiry** — Balance security/UX for mobile app

## Code Changes

**Files modified:**

- `src/auth/jwt.ts` — Token generation and validation logic
- `src/middleware/auth.ts` — Request authentication middleware
- `src/routes/auth.ts` — Login/logout endpoints
- `config/keys/` — RSA key pair storage

**Key code context:** Token validation uses RS256. Keys loaded from
`config/keys/` based on NODE_ENV.

## Open Questions

- [ ] Automatic vs opt-in refresh token rotation?
- [ ] Rate limit for login attempts? (User mentioned 10k DAU)

## Context to Remember

- Client is a mobile app - tokens need offline capability
- User has 10k daily active users - scale matters
- Using PostgreSQL for user storage
- User prefers explicit error messages over generic ones

## Next Steps

1. [ ] Implement `/auth/refresh` endpoint
2. [ ] Add rate limiting to `/auth/login`
3. [ ] Write tests for token expiry edge cases
4. [ ] Update API docs with auth flow

## Files to Review on Resume

- `src/auth/jwt.ts` — Core token logic
- `src/routes/auth.ts` — Current endpoint implementation

Key Reminders

  • Ask what matters to the user before generating
  • Decisions need reasoning — capture the "why"
  • File paths anchor the work — always include them
  • Next steps should be immediately actionable
  • Better slightly longer and useful than short and vague

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Codex

34.43%
按下载量换算46

Claude

28.74%
按下载量换算38

Cursor

19.45%
按下载量换算26

Gemini CLI

9.55%
按下载量换算13

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

敏感数据

该 Skill 可能接触密钥、Token、环境变量或敏感配置,应进入高风险复核队列,默认不自动发布。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills