project-handoff

Generate a comprehensive handoff document so someone new can take over a project — current state, key people, essential knowledge, open items, and a first-30-days plan. Use when the user is handing off a project (trigger phrases include "generate a handoff", "hand off this project", "create a handoff doc", "I'm going on PTO / leaving / changing teams and need to document", "help someone take over") rather than a quick status read (use project-awareness for that).

Quality

95%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Project Handoff

Generate a comprehensive handoff document so someone new can take over a project. Gather everything they'd need: current state, the people who matter, tribal knowledge, open items, and a concrete ramp-up plan.

Determine the project from the user's request. If no project is clear, ask which project they mean before proceeding.

This is the heavyweight counterpart to the project-awareness skill (quick status reads). Use that one if the user just wants current status.

Tools

This skill drives the standard Glean MCP tools. If the host exposes the project-synthesizer agent, use it for project research. Otherwise delegate to a suitable research subagent when subagents are available, or gather the same material directly. For the param shape and pitfalls of search, chat, meeting_lookup, and employee_search, see the using-glean reference at using-glean/reference/. If no Glean tools are visible, ask the user to set up Glean by prompting the harness (for example, Set up Glean for me).

Core Principles

Complete context: include everything needed to take over
Actionable items: clear next steps and open items
Tribal knowledge: capture what's not in docs
Be skeptical: not every doc found is relevant to a handoff
Quality over quantity: focus on what the new owner actually needs

Phase 1: Gather current context

Understand the project's current state.

Ask the user for handoff context:
- Their role on the project (Owner/Lead, Contributor, Advisor/Stakeholder)
- What's driving the handoff (new role/team, PTO coverage, reorg, leaving)
Use project-synthesizer when available; otherwise delegate to a suitable research subagent if possible, or gather the material directly. Cover documentation, people and their roles, recent meetings and decisions, and current status / open items.

Phase 2: Gather undocumented knowledge

Capture tribal knowledge not in formal docs. Ask the current owner:

"What's the #1 thing someone taking over needs to know?"
"What are the biggest risks or gotchas?"
"What relationships are critical to maintain?"
"What recurring tasks or ceremonies exist?"
"What access/permissions are needed?"
"What decisions are pending?"

Phase 3: Identify open items

Search for open work: search "[project] TODO OR action item OR blocked OR in progress"
Check recent commitments: meeting_lookup "[project]" over the past ~2 weeks (extract transcript)
Synthesize: chat "What are the open action items, pending decisions, and blockers for [project]?"
Categorize: Immediate (1-2 weeks), Upcoming (next month), Future (backlog).

Phase 4: Vet all content (CRITICAL)

Filter to what's genuinely needed — be skeptical.

Handoff relevance — ✅ essential / 📚 reference / ❌ skip (historical, tangential) Currency — ✅ current / ⚠️ aging (note it) / ❌ stale (exclude) Actionability — ✅ action needed / 📋 awareness only / ❌ FYI

For each person: are they still relevant, what's the real relationship, why would the new owner need them? For each open item: is it actually still open, is it the new owner's responsibility, what's the real urgency?

Phase 5: Generate the handoff document

# Project Handoff: [Project Name]

**Prepared by**: [Current owner]
**Date**: [Today's date]
**Reason for handoff**: [From Phase 1]

## Content Quality
| Category | Items Found | Included | Reason for Filtering |
|----------|-------------|----------|----------------------|
| Documents | [X] | [Y] | [Z] historical/tangential |
| People | [X] | [Y] | [Z] no longer relevant |
| Open Items | [X] | [Y] | [Z] already resolved |

## Executive Summary
[3-4 paragraphs: what the project is, where it stands, critical context for success, most important next steps]

## Project Overview
### What This Project Is
[Purpose and scope]
### Why It Exists
[Business context, problem being solved]
### Current Status
| Attribute | Value |
|-----------|-------|
| **Phase** | [Planning/In Progress/Launch Prep/etc.] |
| **Health** | [Green/Yellow/Red] - [Why] |
| **% Complete** | [Estimate] |
| **Target Date** | [Date] |

## People & Relationships (Vetted)
### Key Contacts (must maintain these relationships)
| Person | Role | Relationship | How to Engage | Why Critical |
|--------|------|--------------|---------------|--------------|
| [Name] | [Role] | [Critical/Important] | [Best approach] | [Specific reason] |
### Stakeholders to Keep Updated
- [Name/Group] - [What they care about] - [How often]
### Not Included
| Person | Reason |
|--------|--------|
| [Name] | Historical involvement only |

## Essential Knowledge
### The #1 Thing to Know
[Critical context from current owner — from Phase 2]
### Key Decisions Made (that still matter)
| Decision | When | Why | Implications |
|----------|------|-----|--------------|
| [Decision] | [Date] | [Rationale] | [What this means for new owner] |
### Risks & Gotchas
| Risk | Likelihood | Impact | Mitigation |
|------|------------|--------|------------|
| [Risk] | H/M/L | H/M/L | [How to handle] |
### What's Not Documented
[Tribal knowledge that only exists in people's heads]

## Documentation Guide (Vetted)
### Must-Read Docs (in order)
1. **[Doc Title]** ([link]) — why essential, ~[X] min, last updated [date]
### Reference When Needed
- **[Doc Title]** — [when you'd need it]
### Skipped Documents
| Doc | Reason |
|-----|--------|
| [Title] | Historical — superseded by [other doc] |
### Where Things Live
| Resource | Location | Access Needed |
|----------|----------|---------------|
| [Code] | [Repo link] | [Permissions] |

## Open Items (Vetted)
### Immediate (Next 2 Weeks)
| Item | Status | Deadline | What To Do | Notes |
|------|--------|----------|------------|-------|
| [Item] | [Status] | [Date] | [Specific action] | [Context] |
### Pending Decisions
| Decision | Options | Who Decides | Deadline |
|----------|---------|-------------|----------|
| [Decision] | [A, B, C] | [Person] | [Date] |
### Blockers
| Blocker | Impact | Who Can Unblock |
|---------|--------|-----------------|
| [Blocker] | [Impact] | [Person] |

## Operations
### Recurring Tasks
| Task | Frequency | When | How |
|------|-----------|------|-----|
| [Task] | [Weekly/etc.] | [Day/time] | [Instructions] |
### Meetings to Attend
| Meeting | Frequency | Purpose | Your Role |
|---------|-----------|---------|-----------|
| [Meeting] | [Frequency] | [Purpose] | [What to do] |
### Access & Permissions Needed
- [ ] [System/tool] — request from [person/team]

## First 30 Days
### Week 1: Orientation
- [ ] Read essential docs (above)
- [ ] Meet with [key contact]
- [ ] Get access to [systems]
### Week 2: Immersion
- [ ] Take ownership of [first item]
- [ ] Attend [key meeting]
### Week 3-4: Transition
- [ ] Lead [responsibility]
- [ ] Make decision on [pending item]

## Questions?
Contact [current owner] until [date]. After that, [backup person].

Troubleshooting

Sparse information: lean on the Phase 2 tribal-knowledge questions, mark gaps clearly, and don't pad with marginally relevant docs.
Owner unavailable: generate from available documentation, mark "Needs Input" on sections requiring owner knowledge, and note limitations at the top.

Related Skills

project-awareness — quick status read (lighter weight)
onboarding — get up to speed on a team or area

Repository: gleanwork/claude-plugins
Path: plugins/glean/skills/project-handoff/SKILL.md
Commit: a549de6

Last updated: 5 days ago
First committed: 2 months ago

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.