handoff

Handoff Skill

A skill that manages handoff and workflow transitions between the PM and implementer.

Feature Details

Feature	Details
PM→Implementer	See references/handoff-to-impl.md
Implementer→PM	See references/handoff-to-pm.md
Automatic fixing of review feedback	See references/auto-fixing.md
Commit execution	See references/execute-commit.md

Quick Reference

• "Write a completion report to Cursor" → /handoff cursor
• "Handoff to OpenCode" → /handoff opencode
• "Automatically fix review feedback" → /handoff auto-fix
• "Include the changes and test results" → Includes git diff and test results

Prerequisites

This command should only run after harness-review APPROVE

Condition	Required	Check Method
harness-review completed	Yes	Review result is APPROVE
No Critical/High issues	Yes	All fixed
Implementation complete	Yes	Plans.md tasks completed

Why handoff requires review approval:

• PM receives unreviewed changes otherwise
• Quality not assured
• Breaks /work flow (implement → review → fix → OK → handoff)

Usage

/handoff cursor     # Handoff to Cursor
/handoff opencode   # Handoff to OpenCode

---

Execution Flow

Step 1: Identify Completed Tasks

• Check Plans.md checkboxes
• Summarize work done

Step 2: Update Plans.md

# Before
- [ ] Task name `pm:依頼中`

# After
- [x] Task name `cc:完了` (YYYY-MM-DD)

Step 3: Gather Changes

git status -sb
git diff --stat

Step 4: Check CI/CD (if applicable)

gh run list --limit 3

Step 4.5: Unified Memory Finalize (Required)

Before the completion report, finalize the final state in the shared memory:

harness_mem_record_checkpoint(session_id, title, content, tags?, privacy_tags?)
harness_mem_finalize_session(session_id, summary_mode="standard")

This allows the same session to be resumed from Claude Code / Codex / OpenCode. session_id は $CLAUDE_SESSION_ID → .claude/state/session.json の .session_id , retrieve in this order. harness_mem_sessions_list(project, limit=1) The first use of is limited to read-only (resume confirmation), and at handoff time record_checkpoint / finalize_session if there is no explicit session_id , treat it as a failure. harness_mem_finalize_session If has failed, do not finalize the handoff.

Step 5: Generate Report

Output Format

## Completion Report

### Summary
- (1-3 lines describing what was done)

### Completed Tasks
- **Task Name**: [Task description]

### Changed Files
| File | Changes |
|------|---------|
| `path/to/file1` | [Summary] |
| `path/to/file2` | [Summary] |

### Verification Results
- [x] Build success
- [x] Tests passed
- [x] Manual verification complete

### Risks / Notes
- (If any)

### Next Actions (for PM)
1. [ ] [What PM should do next]
2. [ ] [Optional items]

---

/work Integration Flow

/work execution
    ↓
Phase 1: Parallel implementation
    ↓
Phase 2: harness-review loop
    ├── NG (Critical/High) → Fix → Re-review
    └── OK (APPROVE) → Phase 3
    ↓
Phase 3: Auto-commit (if configured)
    ↓
Phase 4: This skill runs ← First time handoff happens

/work automatically calls this skill in Phase 4. When running manually, always do so after harness-review APPROVE.

---

Target-Specific Notes

Handoff to Cursor

• Plans.md markers use cc:完了 (Japanese)
• Report format optimized for Cursor PM workflow
• Includes context for /review-cc-work command

Handoff to OpenCode

• Similar format to Cursor
• Compatible with OpenCode's command structure
• Works with multi-LLM development workflow

Related Skills

• work - Main implementation workflow
• harness-review - Code review
• setup - Project setup (includes 2-Agent workflow)