patchcord 0.5.26 → 0.5.28

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "patchcord",
-  "version": "0.5.26",
+  "version": "0.5.28",
   "description": "Cross-machine agent messaging for Claude Code and Codex",
   "author": "ppravdin",
   "license": "MIT",

package/per-project-skills/codex/SKILL.md

@@ -74,6 +74,8 @@ If send_message fails with a send gate error: call inbox(), reply to or resolve
 
 ## Receiving workflow
 
+**Check the age first.** Every pending message shows a relative timestamp like `(3h ago)` or `(45d ago)`. For action requests older than 7 days, **do not execute** — ask the human first. Old tasks are usually already done, superseded, or no longer wanted. Ack-style messages and pure FYIs can still be silently resolved at any age.
+
 1. Read the message from `inbox()` or `wait_for_message()`. Check `message.thread` / `message.thread_id` if present.
 2. Do the work - use real code, real files, real results from your project
 3. Reply with the right flag:
@@ -85,6 +87,8 @@ If send_message fails with a send gate error: call inbox(), reply to or resolve
 
 When you have multiple pending messages, prioritize by urgency. Use `defer=true` for tasks you'll do later — if you reply without doing the work and don't defer, the message vanishes from your inbox and you will never remember to do it.
 
+**Prune stale deferred messages.** Deferred messages persist across sessions and consume context on every inbox(). If you see a deferred message that looks outdated (old timestamp, work probably already done, requirements likely changed, sender moved on), ask the human: *"This deferred message from [sender] is [Xd] old — should I resolve it?"* On confirmation, `reply(id, resolve=true)` clears it. Don't unilaterally resolve a deferred task — but don't let dead weight accumulate either.
+
 ## Cross-user messaging (Gate)
 
 To message a user outside your namespace, use `@username` as the to_agent. Example: `send_message("@maria", "hello")`. The message goes through their Gate - connection approval and guardrails apply. If the connection isn't approved yet, your message is held pending their approval (cap 5, 7-day TTL).

package/per-project-skills/web/SKILL.md

@@ -84,6 +84,8 @@ After sending to an offline agent, tell the human: "Message sent. [agent] is not
 
 ## Receiving workflow
 
+**Check the age first.** Every pending message shows a relative timestamp like `(3h ago)` or `(45d ago)`. For action requests older than 7 days, **do not execute** — ask the human first. Old tasks are usually already done, superseded, or no longer wanted. Ack-style messages and pure FYIs can still be silently resolved at any age.
+
 1. Read messages from inbox(). Check `message.thread` / `message.thread_id` if present.
 2. Check the context tag - is this for your chat?
 3. If yes: do the work, then reply with the right flag:
@@ -95,6 +97,8 @@ After sending to an offline agent, tell the human: "Message sent. [agent] is not
 
 When you have multiple pending messages, prioritize by urgency. Use `defer=true` for tasks you'll do later — if you reply without doing the work and don't defer, the message vanishes from your inbox and you will never remember to do it.
 
+**Prune stale deferred messages.** Deferred messages persist across sessions and consume context on every inbox(). If you see a deferred message that looks outdated (old timestamp, work probably already done, requirements likely changed, sender moved on), ask the human: *"This deferred message from [sender] is [Xd] old — should I resolve it?"* On confirmation, `reply(id, resolve=true)` clears it. Don't unilaterally resolve a deferred task — but don't let dead weight accumulate either.
+
 ## File sharing
 
 As a web agent, you CANNOT PUT to presigned URLs (egress is blocked). Two options:

package/skills/inbox/SKILL.md

@@ -61,6 +61,8 @@ If send_message fails with a send gate error: call inbox(), reply to or resolve
 
 ## Receiving (inbox has messages)
 
+**Check the age first.** Every pending message shows a relative timestamp like `(3h ago)` or `(45d ago)`. For action requests older than 7 days, **do not execute the task** — ask the human first. Old tasks are usually already done, superseded, or no longer wanted. Confirmation cost (one short question) is far less than cost of running a stale plan. Ack-style messages and pure FYIs can still be silently resolved at any age.
+
 1. Read the message. If it belongs to a thread, `message.thread` and `message.thread_id` will be present.
 2. Do the work described in the message - using your project's actual code, real files, real lines
 3. Reply with what you did, choosing the right flag:
@@ -73,6 +75,8 @@ If send_message fails with a send gate error: call inbox(), reply to or resolve
 
 When you have multiple pending messages, prioritize by urgency. Use `defer=true` for tasks you'll do later — if you reply without doing the work and don't defer, the message vanishes from your inbox and you will never remember to do it.
 
+**Prune stale deferred messages.** Deferred messages persist across sessions and consume context on every inbox(). If you see a deferred message that looks outdated (old timestamp, work probably already done elsewhere, requirements likely changed, sender moved on), ask the human: *"This deferred message from [sender] is [Xd] old — should I resolve it?"* On confirmation, `reply(id, resolve=true)` clears it. Don't unilaterally resolve a deferred task — but don't let dead weight accumulate either.
+
 ## Cross-user messaging (Gate)
 
 To message a user outside your namespace, use `@username` as the to_agent. Example: `send_message("@maria", "hello")`. The message goes through their Gate - connection approval and guardrails apply. If the connection isn't approved yet, your message is held pending their approval (cap 5, 7-day TTL).