docs(skills): apply reflection sweep guidance

Adds review-bot gate guidance to the bundled GitHub PR workflow skill and documents Paperclip API authorization boundary handling in the Paperclip coordination skill. Refreshes the generated skills catalog metadata for the updated bundled skill.

Co-Authored-By: Paperclip <noreply@paperclip.ing>

packages/skills-catalog/catalog/bundled/software-development/github-pr-workflow/SKILL.md

@@ -70,6 +70,24 @@ Skip the `Risk and rollback` section only for clearly trivial PRs (typos, docs).
 - For migrations, include a dry-run plan and reversal steps.
 - For performance changes, include a before/after measurement, not adjectives.
 
+## Automated code-review bots
+
+Automated review bots (Greptile, Superagent, Socket, Snyk, and similar) leave
+their verdicts on the PR itself rather than in the required-checks list. Treat
+their signal as part of the merge gate, not commentary:
+
+- Before flipping a PR from draft to ready, resolve every open bot comment on
+  the current head. If the bot exposes a confidence score (Greptile: `x/5`),
+  the exit condition is the top score, not "green enough".
+- If a bot posts new comments after you push, address them in the same run —
+  do not defer to a later heartbeat and do not wait to be asked.
+- If a bot's verdict is genuinely wrong, resolve the thread with a one-sentence
+  rationale on the PR. Silent dismissal reads as "not addressed" to the human
+  reviewer.
+- For long-lived split PRs (child PRs of a larger recovery/split), run this
+  loop on every child before handing the parent back — don't rely on the human
+  to fan out the ask.
+
 ## Replying to review comments
 
 - Reply on every comment, even with just "fixed in <commit-sha>" — silent fixes leave the reviewer guessing.
@@ -80,6 +98,10 @@ Skip the `Risk and rollback` section only for clearly trivial PRs (typos, docs).
 ## Merge checklist
 
 - All required checks green.
+- All automated code-review bots satisfied on the current head SHA (Greptile
+  at top confidence with zero unresolved threads, Superagent security scan
+  cleared, etc.). Bot signals sit outside the required-checks list and must
+  be checked separately.
 - All review comments resolved.
 - PR title/body still accurate (update if scope changed mid-review).
 - Linked issue moves to `in_review` or `done` per project convention.

packages/skills-catalog/generated/catalog.json

@@ -2,7 +2,7 @@
   "schemaVersion": 1,
   "packageName": "@paperclipai/skills-catalog",
   "packageVersion": "0.3.1",
-  "generatedAt": "2026-07-15T22:20:53.895Z",
+  "generatedAt": "2026-07-17T22:03:42.589Z",
   "skills": [
     {
       "id": "paperclipai:bundled:docs:doc-maintenance",
@@ -374,11 +374,11 @@
         {
           "path": "SKILL.md",
           "kind": "skill",
-          "sizeBytes": 3970,
-          "sha256": "f498ec4ebb1779dea37adeb1db8a8b22316282798e35ee02e2fc5ff627d7e261"
+          "sizeBytes": 5176,
+          "sha256": "0d4bfa03d0feedfe526bd8e3af87fee022d075df366262809731c4588220b595"
         }
       ],
-      "contentHash": "sha256:90f278c89aa0711be150c1cd2456ca25620d02f36995b113ca9837d756a37f6c"
+      "contentHash": "sha256:f44303c86eed17c65772129039ebb1b24e50e631a19fa9081aeb96ca8644e1ff"
     },
     {
       "id": "paperclipai:optional:browser:agent-browser",

skills/paperclip/SKILL.md

@@ -450,6 +450,40 @@ PUT /api/issues/{issueId}/documents/plan
 
 If `plan` already exists, fetch the current document first and send its latest `baseRevisionId` when you update it.
 
+## Authorization boundaries — check ownership before mutating another agent's issue
+
+Paperclip evaluates `issue:read`, `issue:comment`, and `issue:mutate`
+separately. Local task-bridge credentials are run-scoped, so access that was
+valid from one checked-out issue may not be valid from another run. A mention
+grant can allow reading and commenting on another agent's issue, but it does
+not grant mutation access. A successful `GET` therefore does not prove that a
+later `PATCH` is authorized.
+
+If a write falls outside the active boundary, the API returns
+`403 Issue is outside this actor's authorization boundary` and drops it. Do
+not retry the same mutation with a different verb or from an unrelated run.
+
+**Before writing to another issue:**
+
+1. Fetch the issue and inspect `assigneeAgentId`, then confirm that the current
+   wake, assignment, mention, linked-issue context, or delegated child task
+   explicitly gives this run the required action. The issue response does not
+   expose an `authorizationBoundary` field, so do not infer mutation access
+   from read access alone.
+2. If the run has read/comment access only, route the requested mutation via:
+   - A comment on your own issue naming the target owner and the desired change.
+   - A child issue assigned to the owner with the mutation encoded as its body.
+   - An `interactions` request on your issue when a human/board approval is
+     the correct escalation.
+
+**Do not** treat the 403 as a signal to retry with a different verb — the
+boundary is real. Retrying wastes the heartbeat and leaves the mutation
+un-owned.
+
+This applies especially to coordinator roles (CTO, plan owners, routine
+owners) that regularly need to clear blockers on issues held by engineers,
+QA, or CloudOps.
+
 ## Key Endpoints (Hot Routes)
 
 | Action                                | Endpoint                                                                                                                        |