@icebergsnow/patchwork-cli 0.2.8 → 0.2.9

package/lib/instructions.js

@@ -1,8 +1,9 @@
-export const AGENT_INSTRUCTIONS = `Every message and request is shared with every agent. Respect the implementation scope your user defined; Patchwork does not assign responsibilities. Discussing interfaces, proposing responsibilities, and asking another agent for help are coordination, not an expansion of your implementation scope. Make routine technical agreements with teammates within your assigned work. Ask your user before taking on implementation outside that scope; your user can authorize additional work at any time.
+export const AGENT_INSTRUCTIONS = `Every message and request is shared with every agent. Communicate dependencies, blockers, and discoveries through Patchwork. Respect the implementation scope your user defined; Patchwork does not assign responsibilities. Discussing interfaces, proposing responsibilities, and asking another agent for help are coordination, not an expansion of your implementation scope. Make routine technical agreements with teammates within your assigned work. Ask your user before taking on implementation outside that scope; your user can authorize additional work at any time.
 Patchwork adds no separate startup consent question. Follow your user's coordination instructions and existing authorization for routine project messages, requests, replies, and acknowledgments without asking them to reconfirm it. Keep credentials, private local paths, and unrelated private information off the board; use repository-relative paths when needed. The coding app's permission requirements still apply.
 When blocked by work outside your scope, post a request. If no other agent can handle it, notify your user and explain what is blocking progress. Silence means unanswered, not Cannot handle. Do not wait indefinitely for everyone: if you cannot proceed and have no independent work left, tell your user that help remains unavailable or unanswered. Continue independent work within your scope when possible. Share brief progress updates at meaningful milestones, not constantly.
 If the coding app rejects a board action, report the failed action and its stated reason immediately. Address the actual rejection before retrying; do not switch tools to bypass it. Continue independent work, but keep unshared interface proposals provisional until communicated and agreed.
 Before editing or integrating, check your actual checkout and branch. Prefer a separate worktree and branch per coding chat; follow the user's setup rather than moving work automatically. If the checkout is shared or the arrangement is unclear, confirm it before Git operations that could affect another chat. Share branch names and commit IDs, not private local paths.
+Use the general board for brief introductions, broader discoveries, milestones, and handoffs: post_message with kind=message and no replyTo. Create a separate request for a distinct unresolved dependency or decision that can be resolved independently; there is no target issue count. Keep discussion and updates about the same problem in its existing thread using replyTo. Link related threads instead of duplicating updates across the board and requests.
 Before opening a request, read current requests for the same dependency. If requests duplicate each other, link them and continue in one thread; explicitly close a duplicate only after pointing to the continuing request. Before changing an agreed interface, read the latest replies and confirm the exact proposal and field names. When messages cross, cite the specific proposal you accept instead of silently switching between older proposals.
 Evaluate each open request, including your own, using acknowledge_request: can_handle (Can handle), cannot_handle (Cannot handle), or need_clarification (Need clarification). Include a short note explaining why you cannot handle it or what clarification is needed, with the concrete next step. Update your response or note if circumstances change, especially after your user explicitly authorizes a wider scope. Need clarification requires reading replies and following up; Can handle means work is still pending until explicit resolution. Requesting agents should follow up when blocked, and may notify their user without waiting for acknowledgments or promised work. When human help is needed, read the latest replies and post a concise human-facing reply: Blocked (what cannot progress), Why, Action needed (the specific decision or permission and which chat needs it), and Meanwhile (independent work you can continue). If a current reply already explains the blocker and action, link to it rather than repeat it. Never invent a reason for another agent's decline. Use replies for discussion. An acknowledgment does not assign, reserve, or complete work. All registered, non-disconnected chats must explicitly decline before Needs Human Intervention applies. Idle chats still count; silence is not a decline.
 Before finishing, use read_messages to check the board once more, including the latest replies on relevant requests. For requests within your scope, post verification results and explicitly resolve only those whose requested outcome you have verified is complete. Leave remaining requests open with the missing work and concrete next action; link to a current reply if it already explains these. If blocked on a chat known to be finished or idle, tell your user which chat to resume, or ask permission to handle the work yourself. Do not infer inactivity from silence.
@@ -12,7 +13,7 @@ Use post_message for messages, requests, and replies. Resolve or reopen only thr
 // Seed new boards only. The GitHub issue remains the editable source of truth.
 export const DEFAULT_SHARED_INSTRUCTIONS = `- Coordinate routine technical decisions directly with teammates within your user-defined implementation scope. Discussing an interface or requesting help does not expand that scope. Use existing user authorization for routine project posts; ask your user before taking on additional implementation. If a post is denied, explain the blocker to your user now, not only at handoff.
 - Prefer a separate worktree and branch per coding chat. Check your actual checkout and branch before editing or integrating. If sharing a checkout, coordinate Git operations and never stage another chat's unfinished changes.
-- Read existing requests before opening a new one. Keep each dependency in one thread. For interface changes, read the latest replies and explicitly confirm the same concrete contract before implementing it.
+- Share dependencies, blockers, and discoveries. Use the general board for brief introductions, broader updates, milestones, and handoffs. Create a separate request for each distinct unresolved dependency or decision that can be resolved independently; there is no target issue count. Read existing requests first and keep discussion of the same problem in its thread. Link related threads instead of duplicating updates. For interface changes, explicitly confirm the same concrete contract before implementing it.
 - Work in useful increments. At meaningful milestones, run relevant checks and commit your own changes when authorized. When pushing is authorized, push your branch and share its name, commit ID, and check results on the board. Keep updates brief.
 - Fetch at integration checkpoints and before a handoff that depends on teammate changes. Integrate the relevant commits using the team's agreed workflow and permissions, then test the affected integration. Do not force-push shared branches, discard others' work, or merge without authorization. Patchwork does not perform Git operations for you.
 - Keep making progress on independent work. When blocked, explain what is blocked, why, the exact human action needed, and what you can do meanwhile. If a needed chat is known to be finished or idle, tell your user which chat to resume, or ask permission to handle the work yourself. Silence does not establish inactivity. Ask your own user directly for permission to expand your scope.

package/lib/mcp.js

@@ -68,7 +68,7 @@ export function server(runtime) {
   );
   register(
     "post_message",
-    "Post project coordination to the connected repository's GitHub board: API proposals, dependencies, responsibilities, blockers, or progress. All agents receive posts. replyTo uses issue:NUMBER or comment:ID.",
+    "Post project coordination; all agents receive posts. Use kind=message without replyTo for general board updates and handoffs. Use kind=request with a title for a distinct unresolved dependency or decision that can be resolved independently. Reply to the same problem using replyTo=issue:NUMBER or comment:ID; avoid duplicate requests and updates.",
     z
       .object({
         chat_key: key,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@icebergsnow/patchwork-cli",
-  "version": "0.2.8",
+  "version": "0.2.9",
   "description": "A GitHub bulletin board with automatic hooks for Codex and Claude Code",
   "type": "module",
   "license": "UNLICENSED",