edda 0.2.1

Decision memory for coding agents — CLI and TUI
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93

---
name: coord-request
description: Detect changes affecting peers and send coordination requests
---

# Coordination Request


You are a coordination specialist. Your role is to help the agent identify changes that affect other agents and send appropriate cross-agent requests.

## When to Use


- After making public API changes (new/modified types, functions, traits)
- After changing shared configuration, schema, or data structures
- When you need something from another agent's scope (a type export, an API endpoint, etc.)

## Workflow


### Step 1: Identify Changes


See what files have been modified:

```bash
git diff --name-only
```

For files with API changes (public types, function signatures), inspect the diff:

```bash
git diff <file>
```

Look for:
- New or modified `pub fn`, `pub struct`, `pub enum`, `pub trait`
- Changed function signatures (parameters, return types)
- Removed or renamed public items
- New dependencies in `Cargo.toml`

### Step 2: Check Peer Claims


Run `edda peers` to see who owns what scope.

Cross-reference your changed files with peer claim paths:
- If you modified `crates/edda-store/src/lib.rs` and a peer claims `crates/edda-store/*`, they are affected
- If you added a new public type that a peer's crate depends on, they may need to update imports

### Step 3: Determine Impact


For each affected peer, classify the impact:
- **Breaking**: You changed an API they depend on — they must update their code
- **Additive**: You added something they might want to use — informational
- **Request**: You need them to export/create something in their scope

### Step 4: Draft and Send


For each affected peer, compose a clear request:

```bash
edda request "<peer-label>" "<message>"
```

Message guidelines:
- Start with the action type: `[breaking]`, `[info]`, or `[need]`
- State what changed or what you need
- Be specific about files/types/functions

Examples:
- `edda request "auth" "[breaking]: Changed AuthToken fields in edda-core — update your imports"`
- `edda request "billing" "[need]: Export BillingPlan type from your crate so I can reference it"`
- `edda request "api" "[info]: Added new error variant ApiError::RateLimit — you may want to handle it"`

### Step 5: Verify


Run `edda peers` again to confirm your requests appear in the board state.

## Output Format


Present findings:

```
## Coordination Request


### Changes Detected

- <file>: <what changed (added/modified/removed public API)>

### Affected Peers

- [<label>]: <why affected, what they need to do>

### Requests Sent

- To <label>: <message>

### No Action Needed

- <peers whose scope is not affected by your changes>
```