agenticnotetaking/skills/inbox

/eidos:inbox

List and work through messages other repos have left in your agent-inbox/. You own this inbox. You may edit its files freely.

Agents from other repos may push new messages into your inbox at any time. They never edit existing files. Only you do. So re-check the inbox. Don't assume it is unchanged since you last looked. 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:inbox [open | all | <message>]

Instructions

1. Overview first (cluster, don't process)

• Read agent-inbox/message - *.md in the current repo.
• Default to open ones (status: open or in-progress).
• Group by status, then cluster related messages.
  • Related = same thread, sender, topic, or an amends: chain.
  • Surface amendments next to the message they amend (amends:).
• Present the clustered overview. For each: subject, from, timestamp.
• Stop here. This step only orients. It does not start work.

2. Pick one thing

• Work one message, or one cluster of related messages, at a time.
• Only batch messages that genuinely belong together (same thread or topic).
• Unrelated messages are separate units of work. Don't fan out across them.
• If which to take first is ambiguous, let the user choose.

3. Read it

• Show # Context, then each section.
• Summarise the - [ ] requests and any FYI sections.
• Resolve ::repo wikilinks for context when useful:

  python3 ${CLAUDE_PLUGIN_ROOT}/scripts/resolve.py <repo> <file>
  

4. Check relevance (messages may be stale)

• A message captures the sender's view at the moment they wrote it.
  • Their own state then.
  • And what they assumed about your state then.
• Both can have drifted since. Either one makes the request stale.
• Before acting, verify each request is still relevant:
  • already satisfied by work you did since it was sent?
  • the sender's premise about your repo no longer holds?
  • superseded by a later message or an amends:?
  • no longer applicable on the sender's side either?
• If stale, do not blindly do the work.
  • Note it with a =>, confirm with the user, and set status accordingly.
  • e.g. => already handled by [[...]], no action needed.

5. Act (you edit in place)

• Work the requests. Check items [x] as you satisfy them.
• Add => output notes under each item: what you produced, decisions, deviations.
  • Same grammar as plans. See [[c - actions carry input and output context - plain bullets before arrow bullets after]].
• Maintain the whole-message status: open -> in-progress -> done.
• All of this edits files in your own inbox, which is allowed.
  • See [[c - foreign agents append to an inbox - only the owner edits in place]].

6. Reply

• A reply is a new message back to the sender. Use /eidos:message.
• Then record it in the original with an inline => and a ::repo wikilink:
  • => done, now supplied, see [[message - <ts> - <tldr>::<senderRepo>]].
• Never edit the sender's files. Replies and amendments are new files.

7. Commit

• Inbox edits live in your own repo. Commit them per the normal git workflow.

Output

• Updates: message files in agent-inbox/ (checkboxes, => notes, status)
• May trigger: /eidos:message for replies