Skip to content
gutternote

Pull request feedback

When someone reviews a verified preview of your pull request, Gutternote posts one comment on the pull request. Later notes, replies and resolves edit that same comment, so you get one notification, not one per note. A reviewer’s next sitting gets a new comment.

What it needs

  • A repository verified through the GitHub App. See GitHub.
  • Post a summary comment on the pull request turned on for the project.
  • The pull request number and full head commit SHA in a new preview’s build tags. See Build context.

If no comment appears, check these three first.

The tags alone do not bind a preview to a repository. Gutternote verifies the PR and commit with GitHub when the preview is first registered. Older unbound previews show Repository not verified and keep their notes in Gutternote. Changing the project repository never sends their notes to a different PR.

Read the list

Each note is a numbered block, with a line between notes.

  • The page path after the number opens the preview with the note selected. Beside it are the reply and reaction counts. If the note was left on an older commit, that commit is named there too.
  • The note’s text is quoted under the path.
  • Select the screenshot to open the full screenshot.
  • The Resolved checkbox is at the foot of the note. A ticked box is a resolved note.

Resolve a note

Tick Resolved under it. Gutternote resolves the note and records your GitHub username as the person who resolved it. Untick the box to reopen the note. The comment updates within moments. To tick a box, you need write access to the repository.

If a box does not stay ticked, the GitHub App’s updated permissions are probably still waiting for an owner to accept them. See GitHub.

Apart from the checkboxes, the GitHub comment is a copy. Reply in Gutternote, not in GitHub. A reply in GitHub does not reach the note.

To see every note on the latest preview in one place, select See all threads in the dashboard ↗ under the comment’s heading.

Pull request lifecycle

The dashboard’s full review destination can show Pull request is open, Closed without merging, or Merged from a signed GitHub event when every visible note is bound to that same verified repository and pull request. The same lifecycle label appears on its bound preview environment. An existing GitHub comment or check shows that label when GitHub publishing is enabled; it does not refresh while publishing is paused. Resolved and unresolved counts remain independent of that status. If notes are unbound or point to different repositories, or the event is ambiguous, status is unavailable; until a signed event arrives, it is unknown. Merging never resolves notes or starts an agent. New feedback after a merge stays unresolved, keeps the Merged label, and increases the unresolved count. Changing these settings does not resume GitHub publishing.

Send the notes to your agent

Open Send to agent (unresolved notes) below the list and copy the block. It tells the agent how to install the Gutternote plugin, then lists each unresolved note with its Thread ID. Paste it into your coding agent. The agent fixes each note and resolves it.

To have your agent find the notes itself, see Resolve feedback with your agent. The comment’s footer links there too.