agenticnotetaking/skills/outbox

/eidos:outbox

Find messages you sent to peer repos and report their status. Your sent messages live in the peers' inboxes, not here. So this skill sweeps every registered peer and reads back what became of them.

This is the mirror of [[spec - inbox skill - read and act on your own inbox]].

• The inbox is messages others sent to you. You own and edit it.
• The outbox is messages you sent to others. You only observe it.

Read-only on foreign inboxes. Never write to a peer's inbox here. Replies and amendments go through /eidos:message. See [[c - foreign agents append to an inbox - only the owner edits in place]].

See [[spec - agent communication - cross repo inboxes with append only messages and registry resolution]].

Usage

/eidos:outbox [open | all | <peer>]

• open (default): only messages not yet done in the peer's inbox.
• all: include done.
• <peer>: restrict the sweep to one registered repo.

Instructions

1. Identify yourself

• Determine your sender name: how peers know you in their from: field.
  • Default to this repo's directory basename. Confirm or override.
  • This is the same identity /eidos:message writes as from.
  • It may differ from the directory name. The from value is what counts.

2. Enumerate peers

python3 ${CLAUDE_PLUGIN_ROOT}/scripts/resolve.py --list

• Each line is <name>\t<root> if resolvable, or <name>\t!<reason> if not.
• Collect the resolvable roots. Surface the unresolvable ones as a caveat.
  • !no-entry-for-this-machine: registered, but no path for this machine.
  • !missing:<path>: path registered but absent. Can't sweep it.
  • An unresolvable peer means you cannot see messages you sent there. Say so.
• If <peer> was given, restrict to that one.

3. Sweep each peer's inbox

• For each resolvable peer root, read <root>/agent-inbox/message - *.md.
• Keep only files whose frontmatter from: matches your sender name.
• For each kept message, extract:
  • subject, to, timestamp, status.
  • checkbox tally: count [x] vs [ ] across the body.
  • any => output notes the peer added (their answers and deviations).
  • any message whose amends: points at one of yours (your own amendments).

4. Cross-reference your local flow

• For each sent message, grep this repo for a ::<peer> wikilink to its basename.
  • grep -rn "<message-basename>::<peer>" . (or the basename without extension).
• A hit ties the message to the flow it came from (a plan action, a todo).
• No hit = an unrecorded send. You sent it but left no local handle.
  • Flag it. Offer to record a ::repo link now in the right flow.
  • See [[c - foreign agents append to an inbox - only the owner edits in place]] for why the link is your only handle.

5. Report

Group by peer, then by status. For each message:

• subject, timestamp, status, checkbox tally (2/3 done).
• the originating flow if linked, or (unrecorded send) if not.
• reply signal: peer set status: done, or added => notes, or checked items.
  • Highlight these. They are the answers you were waiting for.

Use the numbered-list convention if the report is actionable. See [[spec - numbered lists - structured selectable output]].

6. Act (locally only)

You do not own these messages. You cannot check them off or change their status. What you can do, all in your own repo:

• Record missing ::repo links into the relevant plan/todo/experiment.
• Pick up follow-on work a reply implies (the peer shipped it, now you integrate).
• Send an amendment or a new message with /eidos:message if the request changed.
• Commit these local changes per the normal git workflow.

Output

• Reports: messages you sent, grouped by peer and status, with reply signals.
• May update: local files with ::repo links to previously unrecorded sends.
• May trigger: /eidos:message for amendments or follow-ups.