/shipyard-handoff
Captures session context into .shipyard/HANDOFF.md so the next session can resume without losing progress.
$ npx -y skills add lgbarn/shipyard --skill shipyard-handoff --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/shipyard-handoff
Context preview
The summary Claude sees to decide when to auto-load this skill.
Captures session context into .shipyard/HANDOFF.md so the next session can resume without losing progress.
SKILL.md
shipyard-handoff.SKILL.mdname: shipyard-handoff
description: Captures session context into .shipyard/HANDOFF.md so the next session can resume without losing progress.
<!-- TOKEN BUDGET: 80 lines / ~240 tokens -->
Session Handoff
<activation>
When to Use
- User says "handoff", "hand off", "transfer session", "save context", or "I'm done for now"
- User is ending a session and wants context preserved for the next session
- A long work session is wrapping up and state should be recorded
Natural Language Triggers
- "handoff", "hand off", "transfer session", "save context", "I'm done for now"
</activation>
Overview
Capture the current session's progress into `.shipyard/HANDOFF.md` so the next session can resume immediately with full context. The orchestrator writes the file directly — this is never delegated to a sub-agent.
I'm using the handoff skill to capture session context.
<instructions>
The Process
Write `.shipyard/HANDOFF.md` with exactly these five sections in order:
1. Current Task
What was being worked on at handoff time. Be specific: which file, which feature, which plan task.
2. Approach
The strategy or design being followed. Include key decisions already made so the next session doesn't re-litigate them.
3. Tried
What has been attempted and the outcomes — both successes and failures. Include error messages or unexpected behaviors observed.
4. Remaining
Concrete next steps not yet done. List as actionable items, ordered by priority.
5. Open Questions
Unresolved decisions or blockers that need human input or further investigation.
File Format
## Current Task
[What was being worked on]
## Approach
[Strategy and key decisions]
## Tried
[What was attempted and results]
## Remaining
[Concrete next steps]
## Open Questions
[Unresolved decisions or blockers]
</instructions>
<rules>
Key Principles
- **Orchestrator writes the file** — never delegate to a sub-agent; sub-agents frequently fail to write output files
- **File path is always** `.shipyard/HANDOFF.md` relative to the project root
- **All five sections are required** — do not omit any section, even if the content is "none"
- **Be concrete** — vague handoffs are useless; include file paths, line numbers, error text where relevant
- **After writing**, confirm to the user: "HANDOFF.md is ready. The next session will automatically pick it up when it starts."
</rules>
Read more
name: shipyard-handoff description: Captures session context into .shipyard/HANDOFF.md so the next session can resume without losing progress.
<!-- TOKEN BUDGET: 80 lines / ~240 tokens -->
Session Handoff
<activation>
When to Use
- User says "handoff", "hand off", "transfer session", "save context", or "I'm done for now"
- User is ending a session and wants context preserved for the next session
- A long work session is wrapping up and state should be recorded
Natural Language Triggers
- "handoff", "hand off", "transfer session", "save context", "I'm done for now"
</activation>
Overview
Capture the current session's progress into `.shipyard/HANDOFF.md` so the next session can resume immediately with full context. The orchestrator writes the file directly — this is never delegated to a sub-agent.
I'm using the handoff skill to capture session context.
<instructions>
The Process
Write `.shipyard/HANDOFF.md` with exactly these five sections in order:
1. Current Task
What was being worked on at handoff time. Be specific: which file, which feature, which plan task.
2. Approach
The strategy or design being followed. Include key decisions already made so the next session doesn't re-litigate them.
3. Tried
What has been attempted and the outcomes — both successes and failures. Include error messages or unexpected behaviors observed.
4. Remaining
Concrete next steps not yet done. List as actionable items, ordered by priority.
5. Open Questions
Unresolved decisions or blockers that need human input or further investigation.
File Format
## Current Task [What was being worked on] ## Approach [Strategy and key decisions] ## Tried [What was attempted and results] ## Remaining [Concrete next steps] ## Open Questions [Unresolved decisions or blockers]
</instructions>
<rules>
Key Principles
- **Orchestrator writes the file** — never delegate to a sub-agent; sub-agents frequently fail to write output files
- **File path is always** `.shipyard/HANDOFF.md` relative to the project root
- **All five sections are required** — do not omit any section, even if the content is "none"
- **Be concrete** — vague handoffs are useless; include file paths, line numbers, error text where relevant
- **After writing**, confirm to the user: "HANDOFF.md is ready. The next session will automatically pick it up when it starts."
</rules>
A Claude Code plugin for structured project execution. Plan work in phases, build with parallel agents and TDD, review with security audits and quality gates, and ship with confidence.
Repo: lgbarn/shipyard
Other skills on shipyard.
- /code-simplification
Use after implementing features, before claiming a phase is complete, when reviewing AI-generated code, or when code feels overly complex. Also use when you notice repeated patterns across files, a function exceeds 40 lines, nesting exceeds 3 levels, or an abstraction has only
Open skill - /documentation
Use when shipping features with public interfaces that lack docs, generating documentation, updating README files, writing API docs, creating architecture documentation, or when documentation is incomplete or outdated. Also use when adding breaking changes, implementing complex
Open skill - /git-workflow
Use when starting feature work that needs a branch, creating worktrees for isolation, making atomic commits during development, or completing a development branch via merge, PR, preserve, or discard. Also use when the user says "set up worktree", "create PR", "finish this
Open skill - /import-spec-file
Import a handwritten spec document into Shipyard, replacing brainstorming. Use when a freeform spec, requirements, or design document exists.
Open skill - /import-spec
Import a spec-kit feature spec into Shipyard, replacing brainstorming. Use when a spec-kit feature directory exists with spec.md.
Open skill - /infrastructure-validation
Use when working with Terraform (.tf, .tfvars), Ansible (playbooks, roles, inventory), Docker (Dockerfile, docker-compose.yml), Kubernetes (manifests, Helm charts), CloudFormation, or any infrastructure-as-code files. Also use when running terraform plan/apply, building Docker
Open skill

