Paperclip proposes routing GitHub reviews back to the task that owns the code

Paperclip is considering a direct bridge between human code review and the task that produced the pull request. PR 13896 describes a gap in which a person requests changes on GitHub but the builder never receives that feedback inside Paperclip. The proposed route finds ownership through a registered pull-request work product, posts the review on the appropriate task and wakes the builder.

It deliberately differs from a review bot that creates new triage tasks for bot-generated findings. This proposal accepts selected human feedback and tries to preserve the original work relationship. If the owning task is already done or cancelled, it creates a follow-up child rather than reopening completed work by adding a comment.

The facts

- PR 13896 is open and unmerged, with a per-company opt-in webhook rather than an automatically enabled integration. - The proposed receiver verifies the GitHub signature against raw request bytes before interpreting feedback. - Accepted human associations are OWNER, MEMBER or COLLABORATOR; an optional login allowlist can narrow but not widen that rule. - Bots, the pull request's own author and configured machine accounts are ignored. - Ownership matching requires the same canonical pull-request URL, avoiding same-number collisions across repositories. - The relay labels the quoted text as review feedback to evaluate, and duplicate deliveries should not create repeated comments or follow-up tasks.

Why it matters

Agent work does not end when a branch or pull request exists. Human review is often the point at which a usable result becomes possible, and copying that review into another system is a fragile manual handoff. The proposal's most important choice is ownership: feedback should reach the builder responsible for the work, including when the task is temporarily assigned to a reviewer. Its terminal-task handling also preserves completion history instead of quietly changing what done meant.

Current

Checked September 24, 2026. The inspected release baseline is v2026.916.1. The primary source is open proposal. Package availability and development-source state are separate: a tag does not establish that an open proposal is usable, and a merge does not establish that every installation has received it.

Evidence

Primary: paperclipai/paperclip PR #13896 (https://github.com/paperclipai/paperclip/pull/13896). Supporting context: paperclipai/paperclip — GITHUB-PR-FEEDBACK.md at c6488701 (https://github.com/paperclipai/paperclip/blob/c6488701b471bd70e504f509528d9f0a123bfc37/doc%2Fconnections%2FGITHUB-PR-FEEDBACK.md); paperclipai/paperclip PR #13896 — implementation diff (https://github.com/paperclipai/paperclip/pull/13896/files). Source pages and available diffs were inspected; test and live-account results remain attributed to their authors, not independently repeated measurements.

Operator take

For evaluation, distinguish a valid signature from authority to instruct an agent. The patch checks both transport authenticity and reviewer association, then frames the text as external feedback. Test repository identity, duplicate deliveries, review-state return assignees, closed-task follow-ups and machine-authored comments as separate cases. The author reports 27 tests, including ten against embedded Postgres, plus mutation checks aimed at those boundaries. Those are useful review artifacts, not independent proof of production behavior.

Caveat

The contributor notes that the proposal was not discussed in the project's development channel first and may need a different integration home. Full repository typechecking was not completed locally because Cargo was unavailable, although narrower TypeScript checks passed. Runtime-level treatment of untrusted input remains outside this change, so the warning text is not a guarantee against prompt injection.