handoff-protocol

Name: handoff-protocol
Author: Chipagosfinest

18stars6forks

How to install handoff-protocol?

chipagosfinest/enterprise-team/handoff-protocol

$npx -y skills add Chipagosfinest/enterprise-team --skill handoff-protocol

Installs into the current project.

Summary

Transport-neutral Interaction Records and risk-class evidence bundles for agent-to-agent communication. Replaces ad-hoc handoffs with a single canonical artifact that works identically in Agent Teams mode (via SendMessage) and fallback mode (via Task prompts). Triggers: handoff,

Files · 1

View on GitHub

SKILL.md

1	# Handoff Protocol — Interaction Records
2
3	The unified canonical artifact for all consequential agent exchanges. Every handoff,
4	consultation, escalation, review, or capability request produces an Interaction Record.
5
6	Rule: Peer messages that don't produce a record are ephemeral and cannot be relied
7	upon for decisions. If two agents agree on something that affects the system, it MUST
8	be written into an Interaction Record before the change is committed.
9
10	---
11
12	## The Interaction Record (canonical)
13
14	Use the same template regardless of transport (Agent Teams or orchestrator-mediated).
15
16	```markdown
17	## Interaction Record
18	\| Task ID \| [DEPT-NNN, e.g., ENG-042] \|
19	\| Type \| [consultation \\| handoff \\| review \\| escalation \\| capability-request] \|
20	\| From \| [sender agent name] \|
21	\| To \| [receiver agent name or orchestrator] \|
22	\| Transport \| [agent-teams \\| orchestrator-mediated] \|
23	\| Risk Class \| [low \\| medium \\| high] \|
24	\| Timestamp \| [ISO 8601] \|
25
26	### Context
27	[What's been done, relevant files, current state. Be specific — the receiver cold-reads this.]
28
29	### Request
30	[Specific ask — what the sender needs from the receiver. One sentence if possible.]
31
32	### Constraints
33	[Timeline, technical limits, dependencies, files that must not be touched.]
34
35	### Evidence Bundle
36	[Risk-class-appropriate evidence — see Evidence Bundles section below.]
37
38	### Decision
39	[Filled by the receiver: what was decided, rationale, next steps. Left blank when sending.]
40	```
41
42	---
43
44	## Interaction Types
45
46	### 1. `handoff` — transfer of work between agents
47
48	Use when work is being passed forward. Include complete context, deliverable request, and
49	acceptance criteria in the `Context` and `Request` sections.
50
51	### 2. `consultation` — peer asking for input without transferring ownership
52
53	Use when an agent wants a peer's opinion on an approach, API contract, or design choice.
54	Ownership stays with the sender. Peer may propose, not commit.
55
56	```markdown
57	## Interaction Record
58	\| Task ID \| ENG-042 \|
59	\| Type \| consultation \|
60	\| From \| backend-engineer \|
61	\| To \| security-engineer \|
62	\| Transport \| agent-teams \|
63
64	### Context
65	Implementing OAuth2 PKCE flow for the /auth endpoint. JWT session currently in place.
66
67	### Request
68	Is the code_verifier length of 43 chars sufficient, or should I use the 128-char max?
69
70	### My Proposal
71	43 chars (minimum per RFC 7636) — keeps URL shorter, still entropic.
72	```
73
74	### 3. `review` — formal review of completed work
75
76	Use when submitting work for QA or reality-check. Must include Evidence Bundle
77	matching the risk class.
78
79	### 4. `escalation` — agent stuck, needs reroute
80
81	Use when the agent has hit a wall. Must classify the failure type:
82
83	\| Failure Type \| Meaning \| Orchestrator Action \|
84	\|---\|---\|---\|
85	\| `wrong-capability` \| Agent needed different expertise \| Reroute to matching capability \|
86	\| `task-too-large` \| Scope expanded beyond assignment \| Decompose into subtasks \|
87	\| `conflicting-requirements` \| Spec contradicts code or other spec \| Escalate to product/PM for clarity \|
88	\| `environment-issue` \| Infra/tooling broken, not task logic \| Route to devops/sre \|
89	\| `insufficient-context` \| Agent needs info only another agent has \| Route to knowledge holder \|
90	\| `unknown` \| Can't classify — describe symptoms \| Orchestrator investigates \|
91
92	```markdown
93	## Interaction Record
94	\| Task ID \| ENG-042 \|
95	\| Type \| escalation \|
96	\| From \| backend-engineer \|
97	\| To \| enterprise-orchestrator \|
98
99	### Context
100	Attempted OAuth2 PKCE implementation. Blocked on Supabase JWT signing key rotation strategy.
101
102	### Request
103	Failure Type: wrong-capability
104	Need: security-engineer with auth+oauth2+supabase qualifiers
105
106	### Evidence Bundle
107	- Files attempted: src/auth/middleware.ts, src/auth/oauth.ts
108	- Error: "JWT signature verification failed after key rotation"
109	- What I tried: (1) single static key — works but rotates fail (2) kid-based lookup — key not found in JWKS
110	```
111
112	### 5. `capability-request` — agent needs a peer with specific expertise
113
114	Use when the agent doesn't need escalation but does need a specific capability. Lighter
115	weight than an escalation — typically same-priority routing.
116
117	```markdown
118	## Interaction Record
119	\| Task ID \| ENG-042 \|
120	\| Type \| capability-request \|
121	\| From \| backend-engineer \|
122	\| To \| enterprise-orchestrator \|
123
124	### Request
125	Capability needed: design-system + [tokens, dark-theme]
126	Reason: Need hex values for error state background in dark mode to render in email templates.
127	Urgency: non-blocking

People who liked this also viewed

6 picks

Type

handoff-protocol

18stars6forks

View on GitHub

How to install handoff-protocol?

chipagosfinest/enterprise-team/handoff-protocol

$npx -y skills add Chipagosfinest/enterprise-team --skill handoff-protocol

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Handoff Protocol — Interaction Records
2
3	The unified canonical artifact for all consequential agent exchanges. Every handoff,
4	consultation, escalation, review, or capability request produces an Interaction Record.
5
6	Rule: Peer messages that don't produce a record are ephemeral and cannot be relied
7	upon for decisions. If two agents agree on something that affects the system, it MUST
8	be written into an Interaction Record before the change is committed.
9
10	---
11
12	## The Interaction Record (canonical)
13
14	Use the same template regardless of transport (Agent Teams or orchestrator-mediated).
15
16	```markdown
17	## Interaction Record
18	\| Task ID \| [DEPT-NNN, e.g., ENG-042] \|
19	\| Type \| [consultation \\| handoff \\| review \\| escalation \\| capability-request] \|
20	\| From \| [sender agent name] \|
21	\| To \| [receiver agent name or orchestrator] \|
22	\| Transport \| [agent-teams \\| orchestrator-mediated] \|
23	\| Risk Class \| [low \\| medium \\| high] \|
24	\| Timestamp \| [ISO 8601] \|
25
26	### Context
27	[What's been done, relevant files, current state. Be specific — the receiver cold-reads this.]
28
29	### Request
30	[Specific ask — what the sender needs from the receiver. One sentence if possible.]
31
32	### Constraints
33	[Timeline, technical limits, dependencies, files that must not be touched.]
34
35	### Evidence Bundle
36	[Risk-class-appropriate evidence — see Evidence Bundles section below.]
37
38	### Decision
39	[Filled by the receiver: what was decided, rationale, next steps. Left blank when sending.]
40	```
41
42	---
43
44	## Interaction Types
45
46	### 1. `handoff` — transfer of work between agents
47
48	Use when work is being passed forward. Include complete context, deliverable request, and
49	acceptance criteria in the `Context` and `Request` sections.
50
51	### 2. `consultation` — peer asking for input without transferring ownership
52
53	Use when an agent wants a peer's opinion on an approach, API contract, or design choice.
54	Ownership stays with the sender. Peer may propose, not commit.
55
56	```markdown
57	## Interaction Record
58	\| Task ID \| ENG-042 \|
59	\| Type \| consultation \|
60	\| From \| backend-engineer \|
61	\| To \| security-engineer \|
62	\| Transport \| agent-teams \|
63
64	### Context
65	Implementing OAuth2 PKCE flow for the /auth endpoint. JWT session currently in place.
66
67	### Request
68	Is the code_verifier length of 43 chars sufficient, or should I use the 128-char max?
69
70	### My Proposal
71	43 chars (minimum per RFC 7636) — keeps URL shorter, still entropic.
72	```
73
74	### 3. `review` — formal review of completed work
75
76	Use when submitting work for QA or reality-check. Must include Evidence Bundle
77	matching the risk class.
78
79	### 4. `escalation` — agent stuck, needs reroute
80
81	Use when the agent has hit a wall. Must classify the failure type:
82
83	\| Failure Type \| Meaning \| Orchestrator Action \|
84	\|---\|---\|---\|
85	\| `wrong-capability` \| Agent needed different expertise \| Reroute to matching capability \|
86	\| `task-too-large` \| Scope expanded beyond assignment \| Decompose into subtasks \|
87	\| `conflicting-requirements` \| Spec contradicts code or other spec \| Escalate to product/PM for clarity \|
88	\| `environment-issue` \| Infra/tooling broken, not task logic \| Route to devops/sre \|
89	\| `insufficient-context` \| Agent needs info only another agent has \| Route to knowledge holder \|
90	\| `unknown` \| Can't classify — describe symptoms \| Orchestrator investigates \|
91
92	```markdown
93	## Interaction Record
94	\| Task ID \| ENG-042 \|
95	\| Type \| escalation \|
96	\| From \| backend-engineer \|
97	\| To \| enterprise-orchestrator \|
98
99	### Context
100	Attempted OAuth2 PKCE implementation. Blocked on Supabase JWT signing key rotation strategy.
101
102	### Request
103	Failure Type: wrong-capability
104	Need: security-engineer with auth+oauth2+supabase qualifiers
105
106	### Evidence Bundle
107	- Files attempted: src/auth/middleware.ts, src/auth/oauth.ts
108	- Error: "JWT signature verification failed after key rotation"
109	- What I tried: (1) single static key — works but rotates fail (2) kid-based lookup — key not found in JWKS
110	```
111
112	### 5. `capability-request` — agent needs a peer with specific expertise
113
114	Use when the agent doesn't need escalation but does need a specific capability. Lighter
115	weight than an escalation — typically same-priority routing.
116
117	```markdown
118	## Interaction Record
119	\| Task ID \| ENG-042 \|
120	\| Type \| capability-request \|
121	\| From \| backend-engineer \|
122	\| To \| enterprise-orchestrator \|
123
124	### Request
125	Capability needed: design-system + [tokens, dark-theme]
126	Reason: Need hex values for error state background in dark mode to render in email templates.
127	Urgency: non-blocking

People who liked this also viewed

6 picks

Type