handoff-ticket git:20261104.b533aaeA

Immutable. This exact content never changes and is served at /api/v1/blob/3833ce9ed33f10be.

---
name: handoff-ticket
description: "Use when handing the next ticket to a fresh Orca worktree card — \"핸드오프\", \"다음 티켓 진행해줘\", \"남은 작업 있어?\", \"머지하고 다음 진행해줘\", \"handoff\" — and when this session's ticket is done, to decide what runs next. Another repo, or this session keeps working, is dispatch-card."
---

# Orca handoff

Finish here, and start each follow-up ticket that stands on its own in its own worktree card
(§0 "Who runs it" keeps a small defect in what this session just shipped here).
`orca worktree create` is the only way work leaves this session. Ticket operations go through
`use-tracker`; the worklog goes through `use-notes`.

A handoff always means an Orca worktree card — no other dispatch mechanism. "병렬로 진행" and "동시에 진행" mean this skill
only when they name same-repo ticket cards; they can also mean sub-agents or work dispatched
while this session continues (dispatch-card), so settle which before creating cards.

Not a handoff: the target is another repo, or this session still has its own work to finish
after spawning. That is `dispatch-card` — it never closes this session.

## 0. At "done", decide what happens next

Done means every acceptance criterion on the ticket is met (`deliver-ticket` §6) — usually the merge
plus whatever the ticket asks for after it, such as a release or a verification on main. That
last criterion, not the merge commit, is the decision point.

**Inside a program.** If this session's brief or prompt has a `PROGRAM: <slug>` line
(`orchestrate` `references/brief.md`), it does not pick or spawn the next ticket: after
`worker_done` it closes itself or idles per `end-session` §7, and the orchestrator or lead that dispatched it decides what
runs next. Nothing else makes a session a program worker. The rest of this skill is for sessions without that line.

**Loose ends.** A review comment, or a fix that lands right here, is just work: do it. A thing
that needs its own investigation, decision or diff is classified against the exit condition
first (`deliver-ticket` §2 "Findings outside the ticket"): only NOW becomes a ticket
(`write-ticket`), and then it is the next ticket, not this one. LATER goes on the deferred
list, DROP gets its reason.

**Feedback on in-flight work is a new ticket.** When the user says "이거 더 낫게" about a card
or PR that is already running, file it as its own ticket and hand it off (or queue it). Never
append it to the running card's prompt or scope.

**Dependent tickets.** When ticket B can only start after A, record it in the tracker (A
blocks B) and, when both will be PRs, plan them as a GitHub stack: B's card starts from A's
branch (§3 `--base-branch`), and the two land in one merge from the top (`deliver-ticket` §5,
`orchestrate` `references/landing.md` "GitHub stacks").

**Who runs it.** A small defect in the code this session just shipped stays here, on its own
branch and its own PR. A session can ship N PRs this way — one ticket each, one at a time — so
no count ends a session; compaction is the brake. Anything that stands on its own is handed
off. If this session has already compacted, hand off the small ones too — a fresh card with a
well-written `--prompt` beats a session that lost its own first half.

**What is next.** Rank the unstarted tickets in the same tracker project or parent that serve
an open exit item (the parent's `✅ 완료 조건`) by priority, dependency (blocked tickets wait),
and file collision with cards already running. When every exit item is met, close the parent
and report it instead of starting more, even with lines left on `⏸️ 보류`. Spawn it
yourself when the user said to keep going, or when one candidate is clearly next. Ask when the
ranking is genuinely contested — then give the ranking, a recommendation, and any
parallel-safe combination.

A standing instruction is that permission, already given: "작업 끝나면 다음 티켓 진행해줘",
"알아서 다음 작업 진행해줘", "남은 것 진행해줘". Act on it, do not re-ask.

**What may be asked.** The one question this section allows is *which* ticket comes next, and
only when the ranking is genuinely contested. Whether to file a loose-end ticket, whether to
spawn a card, and whether to close this session are already decided above — never ask them.
File the NOW loose-end tickets before asking about the ranking, so the findings survive a stalled
answer; `write-ticket` skips its approval gate for exactly this case.

## 1. Confirm this work is actually done

Done is defined in `deliver-ticket` §6 and nowhere else — walk it there, and if anything is still open,
finish it there first. The exception is work the user asked to hold: the ticket stays in review
(`started`) and this session keeps its worktree (see §5).

## 2. Resolve the tickets to hand off

Take the identifiers from the user's message. If none was given, take the next unstarted ticket
in the same tracker project or parent. Never guess a ticket number; ask with `AskUserQuestion`
if unsure.

Parallel requests ("병렬로", "동시에") still mean one card per ticket — repeat step 3 per ticket,
never two tickets in one prompt. Hold back a ticket that would edit the same files as one already
running until the first lands, and say what you held — unless it is a dependent layer, which
starts now as a stack on the lower one's branch.

## 3. Spawn the worktree with its agent

```bash
skills-sync handoff <TICKET-ID> \
  --title "<short title>" \
  --reference "<ticket URL, or a Jira key>" \
  --note "<what the ticket does not say: decisions, gotchas, approvals>" \
  --base-branch "<branch this ticket must stack on, else omit>"
```

It runs `orca worktree create` with `--name <ticket-id-lowercase>`, the parent below, `--agent
claude` and the prompt `/goal <TICKET-ID>. <note>` plus the `CLOSE` line on a line of its own;
names the card `<TICKET-ID> <short title>` (not Orca's automatic title: the tab title is the
agent's, a rename does not stick); logs it with `orch sent add`; starts `skills-sync close-setup`
in the background (the setup terminal stays a shell, so `terminal wait --for exit` never fires);
and reads the start (§4). It stops with exit 2 when a live card already holds the ticket (or a
`--reference`) in the same `--role`; `--supersede` replaces it as `dispatch-card` §3 says. Exit 5
means the card exists but its start, link or name is not confirmed: look at it, do not create it
again.

- `--reference` is the card's link to its ticket in Orca (`linkedItems`): `orca reference find
  <TICKET-ID>` then finds the card, and the new session's `orca linear attach --current` works.
  Linear and GitHub take the full URL; a bare key is read as Jira. Do not add the legacy
  `--linear-issue` or `--issue` flags beside it: Orca refuses the mix. If the reference is
  rejected, create the card without it and put the ticket URL in the prompt; the new session
  moves the ticket itself.
- This is a handoff, not supervised work: it has no REPORT line and stays a `/goal` card, not an
  Orca worker (Orca's roles: a handoff creates no Run, Task or Dispatch).
- The parent keeps the next card in the same Orca lineage: the helper passes this card's own
  parent (`orca worktree show`'s `parentWorktreeId`), so it stays under the lead or orchestrator
  after this card closes, or this card when it has none. `--no-parent` only for a ticket
  unrelated to this session's work.
- The name, the ticket id in lowercase, becomes the branch name (with the user's branch prefix,
  if Orca adds one).
- Stacked work: pass the lower ticket's branch as `--base-branch` and say in `--note`
  "stack on <lower ticket> (`gh stack link <lower PR> <this PR> --base main`)".
- Do not use `orca terminal create`: that adds a tab to this worktree instead of a new card.
- The prompt is the whole context the new session gets. It knows nothing from here, so put
  anything non-derivable from the ticket (decisions, base branch, gotchas) in `--note`.
  When the user approved acts beyond the ticket's normal flow (a deploy, a restart, a settings
  change), put them there too, with the Human only and Model calls lines (`dispatch-card` §2).
  The first prompt is the only place an approval reaches the card; one sent later by message is
  refused as not the human's.

## 4. Verify it started

`skills-sync handoff` waits for `tui-idle` and reads the new agent's screen: exit 0 and
`card.start` `started: …` only when a turn runs or the `/goal` prompt was taken. `tui-idle` also
fires on a permission or question prompt, which it reports as `trust` or `dialog` with exit 5;
read `orca terminal read --terminal <card.handle> --screen` then. Report the worktree path,
branch and handle.

## 5. Close this session

Only after step 4 is verified. Read and follow the `end-session`
skill for the state check, the command and the order inside
the final turn. Which ending applies comes from `orca worktree current`, never from an
assumption that this session is a card — `isMainWorktree: true` rules out `worktree rm`.
In addition to what that skill asks for, the report names the cards you spawned (path,
branch, handle) and any tickets you filed, and the same content must already be in the
ticket's completion comment and the worklog before the command runs.