---
name: context-handoff-subagent-continuation
description: Use when a zhctprompt task is long-running, the current thread context is close to full, or the user says to open a new thread or subagent to continue work. Preserve queue state, evidence, and recovery instructions before delegating or continuing elsewhere.
version: 0.1.0
---

# Context Handoff and Subagent Continuation

## Purpose

Prevent long `zhctprompt` work from depending on one saturated chat context. When context is close to full, or when a task naturally needs parallel intake, move work through durable project assets before opening a new thread or spawning subagents.

## Triggers

Use this skill when any of the following is true:

- The user says "当前线程上下文撑满了", "新开一个线程", "用 subagent 来干", "写进规则内并实践", or similar.
- The remaining work spans multiple independent queue items or target projects.
- The current thread is approaching context saturation, has already compacted, or recovery risk is rising.
- A subagent can do a bounded, independent slice without blocking the main thread.
- Work needs to continue in a new Codex thread while preserving the same task state.

## Required Handoff Assets

Before moving work to a new thread or subagent, write or refresh:

- `tasks/QUEUE.md`: current Ready, Blocked, Done, and the exact next executable action.
- `HEARTBEAT.md`: current stage, latest evidence, target repos/worktrees, blockers, and next action.
- `control/task-index/tasks.tsv`: completed or materially progressed task rows.
- A task evidence folder under `work*/.../` with `summary.md` and any subagent reports.
- Thread archive when the run materially progressed:

```bash
python3 /Users/jack/code/099-github/notebooklm-mcp/codex-thread-archiver/scripts/build_codex_thread_archives.py --limit 0
```

## Subagent Practice

Use subagents deliberately:

- Spawn only when the user explicitly permits subagents or the active project rule requires them for batch work.
- Give each subagent a bounded, self-contained task and an explicit no-write or write-scope instruction.
- Do not delegate the immediate critical-path blocker if the main thread needs the result before it can proceed.
- For code-writing subagents, assign disjoint file ownership and remind them not to revert others' edits.
- For review/intake subagents, ask for concrete output paths, risks, and missing rules instead of broad analysis.
- Record the subagent ID/name, task, and result in the evidence folder.

## New Thread Handoff

When opening a new thread is safer than continuing:

1. Finish the current small atomic step if safe.
2. Write a concise recovery note into `HEARTBEAT.md`.
3. Keep `tasks/QUEUE.md` ordered so the new thread can take the first Ready item.
4. Add a `summary.md` under the current evidence folder with:
   - goal
   - completed work
   - current files changed
   - validation already run
   - exact next command/action
   - blockers
5. If the task has a stable ticket ID, apply `task-thread-title-ticket-prefix`.
6. Tell the next thread to start by reading `AGENTS.md`, `HEARTBEAT.md`, `tasks/QUEUE.md`, and the evidence summary.

## Stop Rules

Stop and ask only when:

- The next thread/subagent would need credentials, production access, or hidden local state not captured in project files.
- The next action is high-risk and irreversible.
- Shared API/DB/auth/permission/menu contracts are not locked and parallel execution would create conflicting edits.
- There is no safe way to summarize current state without exposing secrets or personal data.

## Validation

Before claiming the handoff rule is active:

- Confirm this skill is referenced from `AGENTS.md` and `standards-stack/agent-skills/README.md`.
- Confirm long-horizon governance mentions context saturation/new-thread/subagent handoff.
- Run `git diff --check`.
- Record any subagent practice result or blocker in the task evidence.