Worked example

The receiving-pod handoff

Make the duplicate rule explicit, repair the playbook, and decide what is ready to transfer.

Example handoff record · Receiving pod

The second pod found the missing duplicate rule

Transfer task
Apply the invitation specification and authorization skill to another workspace-owned flow.
Handoff owner
Sending pod’s engineering lead.
Receiving reviewer
Receiving pod’s engineering pair, with Product Manager and QA input.

What travels with the work

The first handoff contains a draft specification, repository setup instructions, authorization skill, review record, and known open questions. Include where to find the actual change and check results. The receiving pair should be able to start from those materials and tell you where they get stuck.

Feedback from the handoff exercise

That early draft says “handle duplicate invitations” but leaves two interpretations: resend a message or return the existing invitation. The receiving pair cannot write an unambiguous acceptance check. They also ask whether a duplicate request should extend the invitation’s expiry.

Initial decision: not ready for wider transfer. The pair can follow the authorization routine, but the duplicate branch still depends on the original author explaining unwritten behavior.

Repair the shared playbook

Record the agreed rule: the same workspace and normalized email return the existing pending invitation, create no additional row, and leave expiry unchanged. Email delivery is outside this increment. An expired invitation requires an explicit replacement action.

Add a concurrent-request acceptance case and name the existing persistence mechanism that enforces uniqueness. The sending pair updates the specification; product confirms the behavior; the receiving pair repeats the exercise using the revised instructions.

The invitation specification shown in these examples is the repaired version, with the duplicate and expiry rules written down.

Next decision

Ready for another bounded transfer when the receiving pair can implement and explain the rule, the review evidence covers permissions and duplicates, and the repaired playbook answers the questions without a live walkthrough. Until those checks are recorded, keep the decision open.

The coach captures what changed in the playbook. The sponsor agrees the next pod, protected time, measurement window, and owner. Carry unresolved work into that plan explicitly.

Return to Scale to review readiness, or use Measure what improved for the delivery comparison.

All worked examples →