Handoff（工作交接块）是做什么的？

一个全新的会话比执行会话能做出更好的 QA 和审查——上下文更少，对代码没有依恋。这是一种刻意的实践，而其成败取决于交接块。此技能让每一次交接都达到这个水准。

操作原则

事实由命令验证，而非记忆。 块中的每一个计数、路径和 ID 都来自当前运行的命令：git rev-list --count origin/<branch>..HEAD、git worktree list、ls QA-<slug>.md、以及从 QA 文件中 grep 出的 fixture ID。如果说“3 个提交可能未推送”，但实际计数是 5，就会把下一个会话引向错误的方向。
读者只有这个块。 没有“como vimos”，没有对当前聊天的引用。直接命名要调用的技能、要读取的文件、要运行的命令。
默认在聊天中呈现。 块在聊天内以围栏代码块形式呈现，便于复制粘贴。只有当用户要求写入文件或块超过约 60 行时，才创建 HANDOFF-<slug>.md 文件（临时根目录文件，profile.ephemeral_patterns：受 .gitignore 保护，永不提交）。
影响生产的步骤需命名并说明原因。 不是“注意第 8 步”，而是写明它向何处写入什么、为何不可撤销。
PII 处理原则与处处一致： 显示 ID 和名字；邮件作为工作标识可能显示；绝不显示身份证号、电话或地址。

何时使用

cdv-finalize 封底（它使用此模板自动打印 QA 交接块）。
用户要求提供提示以在另一个会话中继续调查、运行审查或 QA。
会话因上下文增长（即将压缩，“这个会话越来越长”）而即将被放弃。

工作流程

第 0 步——加载配置文件和扩展

读取 .claude/harness/profile.yaml，如果存在 .claude/harness/profile.local.yaml，也读取它（其键值优先级更高）。如果 profile.yaml 缺失，则停止并告知：此技能需要仓库的 cdv-harness 配置文件，切勿猜测值。
当 <profile.extension_dir>/cdv-handoff.md 存在时读取它。扩展只能添加或限制；当此技能与扩展有冲突时，扩展规则优先于该仓库。以下，profile.<key> 是配置文件中的值。如果某个键缺失或为 none，表示仓库没有该项：跳过需要该键的步骤。

第 1 步——确定类型并收集事实（全部只读）

类型 ∈ qa | review | investigation | continue-implementation。然后运行以下命令，并保留原始输出：

git branch --show-current
git worktree list --porcelain
git rev-list --count origin/<branch>..HEAD 2>/dev/null   # 未推送的提交（如果没有远程则显示 '?'）
git rev-list --count HEAD..origin/<profile.default_branch> # 落后默认分支的提交数
git status --porcelain | grep -v '^??'                   # 已跟踪的未提交变更
ls QA-<slug>.md STATE-<slug>.md <slug>-pr.md decisions-<slug>.md 2>/dev/null
grep -n 'PRODUCTION-AFFECTING' QA-<slug>.md 2>/dev/null

对于 qa 类型：直接从 QA 文件的步骤中提取 fixture（ID + 显示标签，格式如 cdv-interactive-qa 所需）。对于 review 类型：通过 cdv-code-review/scripts/resolve-ticket-id.sh 获取工单 ID，并检查 <profile.pr_review_dir_prefix><TICKET>/ 是否已存在。对于 investigation 类型：从 cdv-debug 报告中逐字获取假设块和证据表。对于 continue-implementation 类型：读取 STATE-<slug>.md 的阶段状态、## Finalize seed 部分以及 ## Verificação 是否存在。

第 2 步——渲染交接块

围栏代码块，使用 profile.language_ui（以下 PT-BR 章节标题保持原样），按以下顺序排列；仅当某个部分确实为空时删除它，并明确说明（Sem fixtures pré-consultadas.）：

<VERBO> da branch <branch> (<uma frase do que ela entrega>).

ONDE ESTÁ O CÓDIGO
- <worktree 路径 | 主要结账 `profile.main_checkout`>
- <N> commits à frente de origin/<profile.default_branch>; <M> commits NÃO pushados (confira: git rev-list --count origin/<branch>..HEAD)
- <未提交的已跟踪文件，或 "árvore limpa">

ARMADILHA DO AMBIENTE  （仅当代码在工作树中且 `profile.worktree_runner` 不为 `none` 时）
- O worktree não tem o ambiente do checkout principal (dependências, `.env`); `profile.cmd_container_exec` testa o checkout principal, não este.
- Todo gate por: <profile.worktree_runner> <worktree> <comando de teste> <filtro>
- Para QA na tela: trazer a branch com <profile.bring_branch_script> --check <branch> e depois sem --check. Se recusar, PARE e pergunte — é WIP de outra sessão. Nunca git stash.
- Baseline atual: <N passed (M assertions)>, formatador <PASS>, análise estática <OK>.

O QUE FAZER
- Invoque a skill <cdv-interactive-qa | cdv-code-review | cdv-debug | cdv-plan-feature>.
- <roteiro/arquivo a ler, with path> | <ticket id> | <report to start from>

FIXTURES REAIS (validadas em <data>)
- <entidade> <id> (<label como a tela mostra>) — <estado que interessa>
- ...

PASSOS QUE ESCREVEM FORA DO LOCAL  [PRODUCTION-AFFECTING]
- Passo <n>: escreve <o quê> em <sistema externo, de `profile.production_writing_integrations`>; irreversível porque <motivo>. Só o usuário roda, depois de confirmar <o quê>.
- (or) Nenhum — tudo é leitura ou escrita só no banco local.

CONTEXTO QUE MUDA A EXPECTATIVA
- <the one or two facts that would otherwise look like bugs: "o comando de exportação sai com exit 0 por decisão", "o export roda só de madrugada — testar com o comando manual é o esperado">

NÃO FAÇA
- Não troque a branch do checkout principal por cima de WIP alheio; não use git stash.
- <anything the user excluded: "não investigar os dois registros duplicados">

<VERBO> 是 Rode o QA interativo、Faça o code review、Continue a investigação 或 Continue a implementação 之一。

第 3 步——打印前自检

每个数字都来自第 1 步中的命令（如果树发生了变化，重新运行）。
每个路径都存在（ls）。
没有一个句子需要借助此聊天才能理解。
PRODUCTION-AFFECTING 部分已存在（带有内容或 “Nenhum”）。

组合

cdv-finalize — 在其封底时使用此模板打印 qa 类型的交接块；如果在 finalize 之后独立调用此技能，则重用状态报告中的数字，而非重新推导。
cdv-interactive-qa、cdv-code-review、cdv-debug、cdv-plan-feature — 接收方。交接块指明要调用哪一个。
cdv-code-review 第三方模式 — 针对同事 PR 的审查交接块会明确说明（branch de terceiro: sem apply-review）。

示例（qa 类型，缩写）

Rode o QA interativo da branch fix/export-stale-file (o export escrevia o arquivo de ontem
depois de uma nova execução manual; agora grava o arquivo do dia e remove o anterior).

ONDE ESTÁ O CÓDIGO
- worktree .claude-worktrees/export-stale-file
- 5 commits à frente de origin/<branch padrão>; 2 NÃO pushados (git rev-list --count origin/fix/export-stale-file..HEAD)
- árvore limpa

ARMADILHA DO AMBIENTE
- Worktree sem o ambiente do checkout principal: gates pelo executor de worktree; para a tela, o script de trazer a branch com --check primeiro.
- Baseline: suíte de testes verde, formatador PASS, análise estática OK.

O QUE FAZER
- Invoque cdv-interactive-qa; roteiro em QA-export-stale-file.md (6 passos).

FIXTURES REAIS (validadas na data do handoff)
- relatório 7 (Vendas — semana) — exportado ontem, o arquivo antigo ainda existe (o caso a reparar)
- relatório 8 (Estoque — semana) — nunca exportado (o caso limpo)

PASSOS QUE ESCREVEM FORA DO LOCAL
- Passo 4: o one-off LÊ a API externa real (uma chamada por item) para conferir os totais; nunca escreve nela. Se algo sugerir escrita, pare.
- Nenhum outro — o export grava só no disco local.

CONTEXTO QUE MUDA A EXPECTATIVA
- O export roda só de madrugada — testar com o comando manual é o esperado.

NÃO FAÇA
- Não troque a branch do checkout principal por cima de WIP alheio; não use git stash.

Handoff（工作交接块）