patchcord 0.5.28 → 0.5.29

package/package.json

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

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

@@ -74,7 +74,7 @@ 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.
+Action requests older than 7d (per the `(Xd ago)` stamp): ask human before executing. Acks/FYIs silent-resolve 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
@@ -87,7 +87,7 @@ 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.
+Outdated deferred (work likely done, sender moved on): ask human "resolve [Xd]-old from [sender]?" before `reply(id, resolve=true)`. Don't unilaterally drop.
 
 ## Cross-user messaging (Gate)
 

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

@@ -84,7 +84,7 @@ 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.
+Action requests older than 7d (per the `(Xd ago)` stamp): ask human before executing. Acks/FYIs silent-resolve 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?
@@ -97,7 +97,7 @@ 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.
+Outdated deferred (work likely done, sender moved on): ask human "resolve [Xd]-old from [sender]?" before `reply(id, resolve=true)`. Don't unilaterally drop.
 
 ## File sharing
 

package/skills/inbox/SKILL.md

@@ -61,7 +61,7 @@ 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.
+Action requests older than 7d (per the `(Xd ago)` stamp): ask human before executing. Acks/FYIs silent-resolve 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
@@ -75,7 +75,7 @@ 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.
+Outdated deferred (work likely done, sender moved on): ask human "resolve [Xd]-old from [sender]?" before `reply(id, resolve=true)`. Don't unilaterally drop.
 
 ## Cross-user messaging (Gate)