Jigward comments on pull requests. People approve and merge them.
How Jigward's review comments fit into your team's review, and why approving, requesting changes and merging stay with the people who own the repository.
Take an example from Orbit Cab, a made-up cosmo-taxi company. A reviewer opens a pull request and finds Jigward’s comments already on it. One says the new surcharge is added on every leg of a ride instead of once, points at the line, says what it would change, and names the test that shows it. The reviewer reads it the way they would read a colleague’s comment, agrees with two findings, disagrees with one, and approves when they are satisfied.
That is the whole division of labor. Jigward adds comments. People approve, request changes and merge.
Four things a pull request can get
GitHub gives a reviewer several ways to respond, and they mean different things:
- A comment says what the reviewer noticed. It decides nothing.
- An approval says the reviewer is satisfied. Branch protection rules often count it toward allowing a merge.
- Requesting changes says the pull request needs more work. Where branch protection requires reviews, it blocks the merge until the reviewer approves or the request is dismissed.
- A merge puts the change into the base branch.
Jigward only ever does the first. It never approves a pull request, never requests changes on one, and never merges one, including its own.
How its review helps
Jigward reviews a pull request it did not open only when someone asks: by requesting its review, by mentioning its GitHub App in a comment, a review or a line of the diff, or by giving it a Task to review one. A Task is a piece of work Jigward carries through to a report.
The review is one set of comments posted together: a summary of the pull request as a whole, and a comment on each line a finding is about. Each finding says what is wrong, why it matters, what Jigward would do, and what that rests on: a team decision and who made it, a rule of the repository, the database schema or the API, or the code.
A later request on the same pull request continues the same Task, so a second review knows what the first one said. A pull request nobody asked about is not reviewed, and a comment that does not mention the App is people talking to each other.
None of this makes Jigward’s comments right. Its review is read the way a colleague’s is, and being wrong costs a comment someone reads, never a merge or a block nobody chose.
Who can ask for a review
On GitHub, whoever asks must be able to write to the repository. Jigward asks GitHub about that when the request arrives. A request from anyone else starts nothing, and so does one GitHub gives no answer about. Failing to find out counts as not being allowed, because a review spends the organization’s money and anyone can comment on a public repository.
Its own changes arrive as drafts
When a Task changes code, Jigward opens a draft pull request on a branch of the Task’s own. The app says it in one line: “Opened as a draft. Jigward never merges it.”
The Task then waits as Awaiting code review: “The pull request waits for a person to review and merge it on GitHub. The task is done once it is merged.” A merge finishes the Task. Closing the pull request without a merge asks the person how to go on. Reopening it puts the Task back to waiting. That switch follows only what GitHub reports a person did, never what the work says about itself.
Feedback continues the same Task. A review that comments or requests changes, its line comments, and comments on the conversation are kept as feedback still to handle. Jigward works on the same branch, updates the same pull request, and answers each comment where it was left. Approvals and comments by bots are not acted on, and a conflict with the base branch is left to a person.
Why the boundary is in the code
GitHub’s API takes a review with an event field, which can approve, request changes or comment.
In Jigward’s GitHub client that field is not a parameter: the request type always sends COMMENT.
The tool that posts a review takes the repository, the pull request number, the head commit, a
summary and the line comments, and has no field for an outcome. The client has no call that merges
a pull request.
A model can misread an instruction. It cannot set a field that does not exist. So the guarantee does not rest on telling the model to behave.
The tool is strict in smaller ways too. A comment on a line the diff does not show refuses the whole review, so nothing half-posted is left behind, and the work is told that nothing was posted and why.
An approval is a statement a person makes and other people act on. If Jigward could make one, every approval in the repository would leave a question behind: did a person make this call, or did a model? Keeping it out of Jigward’s reach means the answer is always a person.