agentsclimarketplace
Sign in

Agent mail

Skill boshu2/agentops/skills/agent-mail

Use Agent Mail as an optional messaging and file-reservation adapter for explicitly coordinated writers. Triggers: "coordinate writers", "reserve files".From its SKILL.md

Install
npx -y skills add boshu2/agentops --skill agent-mail

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

SKILL.md

6.6 KB, as published. Nobody here has run it

Agent Mail — optional coordination adapter

Agent Mail carries messages, acknowledgements, identities, and temporary file reservations. It is not a task tracker, queue, proof ledger, or lifecycle controller.

Reservations are advisory: they prevent collisions only because every cooperating writer checks them against the same absolute project path, and one writer registered against a different path resolution makes the whole ledger advisory fiction. Agent Mail enforces nothing on a writer that does not check.

Named failure mode — silence-as-status: reading an unanswered thread as "work stalled" or "work done"; mail silence proves only that no mail arrived.

Anti-pattern: widening or renewing a reservation unprompted when a conflict appears. Corrective: report the conflict to the caller as-is; scope and TTL changes are the caller's call.

Boundary

  • Skip Agent Mail for a single writer.
  • The caller supplies the absolute project path, agent identities, thread id, participants, paths, exclusivity, reason, and TTL.
  • Reservations prevent accidental overlap among cooperating writers. They do not create work ownership or affect Plan, Candidate, or verdict semantics.
  • Mail silence proves nothing about work status.
  • A message or acknowledgement is evidence that communication occurred, not evidence that a change is correct or complete. The adapter cannot select AgentOps semantics, issue a binding verdict, or turn factory completion into delivery or validation proof.
  • Release a reservation, including any force_release, only on the caller's explicit request for that exact reservation. Force-release has no autonomous trigger; a conflict is reported, not force-cleared.
  • Agent Mail never selects work, changes tracker state, commits code, validates, integrates, closes, releases, or delivers work.

Modes and authority

Two disjoint surfaces; do not reach the second from the first:

  • Coordination mode (default). Register identity, reserve/release the caller's paths, send/read/acknowledge the caller's threads. This is the whole of routine use, and all of it writes durable Agent Mail records.
  • Admin / disaster-recovery mode (explicitly caller-authorized only). Installing the git pre-commit guard, doctor repair, backup/restore, and the irreversible clear-and-reset-everything are a separate mode. Each requires the caller's explicit authorization for that specific operation; none is ever performed as a side effect of coordination. clear-and-reset-everything deletes the database and all storage and cannot be undone — never run it, even with --force, without an explicit destructive-reset authorization from the caller.

Surfaces

Choose exactly one mailbox owner and access mode for each storage root. When an HTTP/MCP daemon owns the root, use its MCP tools; do not point the direct am CLI at the same database. Use the CLI fallback only with a root not owned by a running Agent Mail runtime. A busy mailbox activity lock or a bounded read timeout is a degraded adapter result, not permission to restart the service, repair the database, or silently switch roots.

Use the MCP tools when they are present. Otherwise use the self-describing am CLI. Pin the intended storage root explicitly, and discover current syntax with am mail --help, am file_reservations --help, and related group help; do not infer commands from remembered aliases. If a direct macOS read rejects a symlinked snapshot directory such as /var, use a caller-scoped, non-symlinked temporary directory for that isolated invocation or report the adapter degraded; never weaken the traversal check.

One-shot use

  1. Confirm that multiple explicitly coordinated writers share the repository.
  2. Freeze one storage root and either MCP/server mode or direct-CLI mode; never mix both against the same live database.
  3. Register the caller-supplied identity against the same absolute project path.
  4. Reserve only the supplied paths, with a bounded TTL.
  5. Report conflicts without waiting, narrowing scope, or changing the plan.
  6. Send the supplied message once and record its id.
  7. Read or acknowledge only the requested thread.
  8. Before the caller advances a declared transition, verify every acknowledgement-required message in that transition has the intended recipient acknowledgement. Later traffic is not an implicit acknowledgement.
  9. Release only reservations the caller explicitly asks to release.

Output

Return the project, identity, thread/message ids, reservation ids and paths (with their TTLs), conflicts, and timestamps. The caller owns all subsequent decisions.

Terminal outcomes are explicit, never silent:

  • Adapter unavailable — neither the MCP tools nor the am CLI is present: report that Agent Mail is unavailable and stop. Do not fall back to hand-written coordination or treat the absence as "no conflicts".
  • Reservation conflict — report the conflicting reservation as-is; do not narrow, widen, renew, or force-release it.
  • Mailbox ownership conflict — a daemon and direct CLI contend for one storage root: report the lock owner/mode and stop; do not restart, repair, or bypass the lock as a coordination side effect.
  • Required acknowledgement pending — report the exact message and intended recipient and stop the dependent transition. Do not infer acknowledgement from a later reply or repair it after validation.
  • Timeout / degraded surface — report the operation as timed out or degraded with what was and was not observed; a timeout is evidence, not "done".
  • Cleanup — reservations released this session are listed by id; any left in place (still holding a TTL) are named so the caller can see what remains.

References

What ships with it: 3 files

14.3 KB alongside SKILL.md

references/

Gives 0 of the 12 instructions most context ai engineering skills give

Counted across 1,328 of the 2,349 authors here whose files we hold, read 2026-09-06

  • Dispatch a fresh subagent for each taskin 76 of 1328, across 59 files
  • Perform spec compliance review before code quality reviewin 44 of 1328, across 34 files
  • Dispatch a final code reviewer after all tasksin 38 of 1328, across 26 files
  • Answer subagent questions before allowing implementationin 36 of 1328, across 26 files
  • Use the least powerful model capable of the taskin 33 of 1328, across 26 files
  • Create a TodoWrite list for all tasksin 32 of 1328, across 22 files
  • Perform a task review after each implementationin 31 of 1328, across 24 files
  • Extract all tasks and context from the planin 29 of 1328, across 20 files
  • Provide full task text to subagentsin 28 of 1328, across 20 files
  • Use git worktrees for isolated workspacesin 25 of 1328, across 20 files
  • Specify the model explicitly when dispatching a subagentin 23 of 1328, across 18 files
  • Execute all tasks from the plan without stoppingin 21 of 1328, across 16 files

Said here and by no other author read

  • use am CLI if no MCP tools exist
  • pin the intended storage root explicitly
  • register identity against the absolute project path
  • reserve paths with a bounded TTL
  • report conflicts to the caller as-is
  • send messages once and record the id

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.

Keep looking

Skills are one crate of 626,474. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.