receive-handoff-grounding

Verifies handoff claims against independent resolvers before executing irreversible actions.

2.9k|733|Updated Mar 12, 2026
One-click install
npx skills add https://github.com/zts212653/clowder-ai --skill receive-handoff-grounding
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: receive-handoff-grounding
Source: https://github.com/zts212653/clowder-ai/tree/main/cat-cafe-skills/receive-handoff-grounding
Command: npx skills add https://github.com/zts212653/clowder-ai --skill receive-handoff-grounding

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

When AI agents receive cross-thread handoffs containing claims about ownership, authorization, or object state, they risk acting on unverified assertions. This Skill enforces a three-question verification reflex (claim, resolver, verdict) before any irreversible action like merging PRs, taking over work, or registering tracking.

Core Features & Use Cases

  • Claim Grounding Three-Question Protocol: Extracts every verifiable claim from a handoff message, resolves each against an independent second source, and produces a verified/mismatch/insufficient verdict.
  • Source Tier Enforcement: Classifies resolver evidence as T0 (hard ground truth like operator messageIds or git signatures), T1 (platform truth like PR review state), or T2 (cat-writable narrative), requiring at least one T0/T1 source for high-risk actions.
  • Action Policy Matrix: Maps actionFamily (merge, takeover, wait, register_tracking, owner_reassignment) against verdicts to decide proceed, block, push back, or fail-closed outcomes.
  • Use Case: Before merging a PR based on a teammate's message saying "operator approved", the Skill checks the actual message author identity and PR review state, blocking the merge if only secondhand narrative evidence exists.

Quick Start

Before I merge this PR based on the handoff message claiming operator approval, run the claim grounding three-question check and tell me whether to proceed or push back.

Frequently Asked Questions about receive-handoff-grounding

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I verify a handoff claim before merging a PR?

Extract each claim from the handoff message, then resolve it against an independent source such as the GitHub API for PR review state or the original operator messageId. High-risk actions like merge require at least one T0 or T1 evidence source; secondhand narrative alone results in an insufficient verdict and blocks the merge.

What is the difference between T0, T1, and T2 source tiers?

T0 is hard ground truth like a direct operator messageId, git signature, or GitHub object identity. T1 is derived platform truth like PR review state or CI checks. T2 is cat-writable narrative like feature docs or another agent's claim, which cannot alone authorize high-risk actions.

When does the claim grounding check trigger?

It triggers on hard action families: hold_ball waits, PR or issue tracking registration, merges, operator signoff claims, takeovers, irreversible operations, and owner reassignments. Pure reading of cross-posts or routine thread mentions does not trigger enforcement.

What happens when resolver evidence is insufficient for a takeover?

The verdict becomes insufficient and the action fails closed. For high-risk takeovers, T2-only evidence like a feat_index entry is not enough; you need a T0 operator messageId or T1 git log signature confirming ownership before proceeding.

Why does hold_ball require a WaitSourceRef with slaUntilMs?

A wait without a verifiable source and deadline is an unbounded timer with no callback path. The schema requires slaUntilMs within one hour and an expectedSignal; otherwise the wait is blocked and routed to needs-info or a daily sweep instead.

Can a peer agent override a PR reviewer's instruction?

No, unless the sender has issuer standing as the operator, upstream feature owner, repo admin, or that PR's reviewer. A regular peer instruction yields issuerStanding of none, producing a mismatch verdict that blocks the action and pushes back to the source thread.