@tickernelz/paperclip-pro-adapter-codex-local 2026.930.4 → 2026.930.6

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tickernelz/paperclip-pro-adapter-codex-local",
-  "version": "2026.930.4",
+  "version": "2026.930.6",
   "license": "MIT",
   "homepage": "https://github.com/tickernelz/paperclip-pro",
   "bugs": {
@@ -39,8 +39,8 @@
   ],
   "dependencies": {
     "@agentclientprotocol/codex-acp": "^1.6.2",
-    "@tickernelz/paperclip-pro-adapter-utils": "2026.930.4",
-    "@tickernelz/paperclip-pro-shared": "2026.930.4",
+    "@tickernelz/paperclip-pro-adapter-utils": "2026.930.6",
+    "@tickernelz/paperclip-pro-shared": "2026.930.6",
     "picocolors": "^1.1.1"
   },
   "devDependencies": {

package/skills/paperclip/SKILL.md

@@ -244,6 +244,8 @@ Because of that, follow these rules:
 
 **Step 9 — Delegate if needed.** For ordinary execution tasks, create subtasks with `paperclipCreateIssue` and set `parentId` and `goalId`; `paperclipCreateChildIssue` does the same for a direct child of the issue you hold. For conversation tasks, use the project handoff above instead. When a follow-up issue needs to stay on the same code change but is not a true child task, set `inheritExecutionWorkspaceFromIssueId` to the source issue. Set `billingCode` for cross-team work.
 
+**Parent rule.** An issue you create because of the task you are working on (follow-up, deploy, fix, review) gets `parentId` = that task, or use `paperclipCreateChildIssue`. Omit `parentId` only for independent work, a conversation handoff, or a deliberate non-child follow-up that sets `inheritExecutionWorkspaceFromIssueId` (see above). A create during a run that holds an issue with neither `parentId` nor `inheritExecutionWorkspaceFromIssueId` returns `warnings[].code: "parent_missing"` with `suggestedParentIssueId`; fix it with `paperclipUpdateIssue` when the issue belongs to that work.
+
 ### Delegating review tasks
 
 This is the only way an agent hands its own work to a reviewer: create the review subtask with `paperclipCreateChildIssue` assigned to the reviewer, add it to `blockedByIssueIds` on your issue, then set `status: "in_review"` — you keep the assignment and wake on the verdict. Run-scoped writes are subtree-scoped: the delegate's run can write to its own issue and descendants, generally **not** to your issue. Write review-task descriptions accordingly:

package/skills/paperclip/references/api-reference.md

@@ -606,6 +606,8 @@ paperclipUpdateIssue { issueId: "issue-30", status: "done", comment: "Broke down
 paperclipDashboard {}
 ```
 
+Parent rule: an issue created because of the task you are working on (follow-up, deploy, fix, review) gets `parentId` = that task, or use `paperclipCreateChildIssue`. Omit `parentId` only for independent work, a conversation handoff, or a deliberate non-child follow-up that sets `inheritExecutionWorkspaceFromIssueId` to the source issue. When an agent run holding an issue creates one without `parentId` or `inheritExecutionWorkspaceFromIssueId`, the create still succeeds and the response adds `warnings: [{ code: "parent_missing", message, suggestedParentIssueId, suggestedParentIdentifier }]`; set `parentId` with `paperclipUpdateIssue` when the new issue belongs to that work.
+
 ---
 
 ## Comments and @-mentions