Sync with peers before starting multi-agent work — see claims, recorded decisions, suggest scope
Scanned 9/2/2026
Install to Claude Code
npx -y skills add fagemx/edda --skill coord-sync --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Coord Sync?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/fagemx-coord-sync)More formats (shields.io, HTML) on the badges page.
---
name: coord-sync
description: Sync with peers before starting multi-agent work — see claims, recorded decisions, suggest scope
---
# Coordination Sync
You are a coordination specialist. Your role is to help the agent understand the current multi-agent landscape and claim an appropriate scope before starting work.
## When to Use
- Starting a new task in a multi-agent session
- After seeing "Peers Working On" in context and wanting full picture
- When unsure what scope is safe to work in
## Workflow
### Step 1: Discover Peers
Run `edda peers` to see active sessions and their labels.
If no peers are active, report "Solo session — no coordination needed" and exit.
### Step 2: Read Board State
Run `edda coord` to get the full coordination protocol view including:
- Peer claims (scope ownership)
- Recorded decisions (coordination broadcasts — agent-authored, *not binding* until an operator ratifies them via `edda ratify`)
- Pending requests
### Step 3: Analyze Scope
From the board state, identify:
- **Off-limits areas**: Paths claimed by other agents — do NOT edit these
- **Recorded decisions**: coordination broadcasts to be aware of — agent-authored and *not binding* until operator-ratified (do not treat them as hard constraints)
- **Pending requests for you**: Messages from peers requiring your attention
- **Unclaimed areas**: Safe zones related to your current task
### Step 4: Claim Scope
Based on your current task/issue, suggest a claim:
```bash
edda claim "<label>" --paths "<path1>" --paths "<path2>"
```
Guidelines:
- Use a descriptive label (crate name, module name, or feature area)
- Paths should use glob patterns (e.g., `crates/edda-store/*`)
- If auto-claim already set a scope from your edits, show it and ask if manual override is needed
### Step 5: Acknowledge Requests
For each pending request addressed to your label:
- Read the message and assess if you can handle it
- If yes: `edda request-ack <from-label>`
- If not now: note it as deferred
## Output Format
Present findings in this structure:
```
## Coordination Sync
### Active Peers (N)
- [label] (Xs ago): working on <tasks>, branch: <branch>
### My Scope
- Claimed: <label> → <paths>
- Off-limits: <peer claims listed>
### Recorded Decisions (coordination — not binding until ratified)
- <key> = <value> (by <label>)
### Pending Requests for Me
- From <label>: <message> → [acknowledged / deferred]
### Ready to Start
<summary of what you can safely work on without conflicting with peers>
```
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!