Make team handoffs traceable

Start with three responsibilities

Responsibility	Output	Recipient
Research and intake	Sourced facts, gaps, and conflicts	Writing role
Drafting	Draft matching acceptance criteria	Human reviewer
Review and decision	Source checks and decisions on subsequent actions	Named execution owner

These are assignments, not proof of automatic orchestration or permission isolation. Test one handoff before adding roles without clear outputs.

Copy a handoff card

Task: customer meeting preparation / draft v2
Current owner: research and intake
Next owner: meeting preparation
Inputs: fact table v2, source list v1 (sanitized)
Verified: three needs have quotes and dates
Unverified: budget and decision maker; do not guess
Next output: one-page brief and five questions
Reviewer: project owner
Allowed actions: read these files, write a draft; no customer contact
Stop condition: missing sources or unexplained conflicts

Practice a manual handoff with Qinghe Studio. All materials below are fictional. Write drafts only; do not contact the customer. The recipient explicitly fills in the receipt; this does not imply a background state machine in the host.

A | Profile: Qinghe Studio, a 12-person customer service team.
B | Discussion on 2026-10-20: wants a month-end ticket summary; budget and decision maker unconfirmed.
C | Product validation: CSV import verified; real-time sync unverified.
Fact table v1: includes A/B, omits C.
Receipt: return v1; product validation limits C missing; pause brief drafting.
Fact table v2: add C; budget, decision maker, and real-time sync remain unconfirmed.
Old brief: based on v1; mark “review pending” and hold circulation.
Reviewer Lee's receipt: decision to accept fact table v2; recheck the draft brief against v2 before resubmitting.

Stop for missing sources, unclear versions, or unexplained conflicts. Resume after materials are supplied and reviewer Lee names the accepted version. Mark old outputs for review and recheck them before the next handoff. Accepting a fact table does not accept the brief or product.

Shared configuration is not shared memory

Shared configurations transfer definitions and methods, without the creator's conversations, learned memory, accounts, or keys. Supply project context in a versioned sanitized packet with an explicit sharing scope, for use in the recipient's authorized environment.

Keep stable methods in configuration and project facts in a packet.
List exact files and versions rather than assuming shared background.
Confirm materials are readable and review the output before proceeding.

Use gitopsbot as a coordination example

The bilingual gitopsbot playbook covers GitHub-to-Feishu routing, signatures, deduplication, receipts, and recovery. Start with a table of repositories, events, destination groups, sender, and access gaps. Downloading the role does not create a listener, connect accounts, or grant group-send permission.

Sources

Sources checked: 2026-10-25