Standing service review-every-pull-request-on-one-repository · revised 11 October 2026
Standing service
A written review for each pull request on one repository, every month
Pull requests opened on one organisation-owned repository each get a written review, up to an agreed number a month, with a monthly summary of the findings and what happened to each.
This starts a conversation by email. Nothing is charged, and nothing is reviewed, until we have agreed scope and terms with you in writing.
The responsibility you hand over
On a small team, review is the first thing dropped when a deadline is close. Changes merge unread, and a defect, a missing test or an unclear design is found later at higher cost. A standing responsibility keeps a second reader on each change for as long as you want it, without depending on one colleague's spare hours.
Who it’s for: A founder or engineering lead with one or two developers, or an agency team, where pull requests are merged with little or no independent review.
Usually starts when: The team merges its own work without a second reader, or review depends on whoever has a spare hour that week, and defects have started to reach the main branch.
The result: Each pull request opened on the named repository, up to the agreed monthly number, receives a written review, and each month you see how many were reviewed, what was found and what your team did with each finding. The merge decision stays with you.
What stays true, and what we do about it
No response-time guarantee is published for this new service. A target for how soon a review is posted is agreed in writing before it starts, set to what a service at this stage can actually keep.
Hours are agreed in writing before the service starts. At launch the service is not staffed round the clock, so we do not offer out-of-hours cover.
What must remain true
- Each pull request in scope on the named repository receives a written review
- Every finding ends the month marked accepted, dismissed by your team with a reason, or still open
What we watch
- Pull request notifications on the named repository, read through the account you invite
- The agreed monthly number and size, and any list of pull requests you ask us to prioritise
When something happens
Scroll the table sideways to read it all.
| When | What we do |
|---|---|
| A pull request in scope is opened or marked ready for review. | We read it and the code around it, run its tests where that helps, and post a written review with findings, reasons and a way to verify each. Priced as: Written review of five pull requests |
| The author changes a pull request after our review. | We re-read the changed parts once and update our findings. |
| A month ends. | We send the summary: pull requests reviewed, findings and how each ended, and anything we did not reach. |
We do on our own
- Read in-scope pull requests and the code they touch with the Read role you grant
- Run tests and quick checks in an isolated workspace
- Post review comments, as Comment reviews only, through the invited account
We ask you first
- Reviewing pull requests above the agreed number or size
- Changing the agreed monthly number or size
- Any change to the agreed access on the one repository; we never accept a role above Read
We escalate to you when
- A pull request contains a secret or customer data
- A change looks as though it could harm users or their data if merged
- Volume regularly passes the agreed number or size
How you know it held. Each month's summary lists every pull request reviewed and the outcome of every finding, and you can compare it with your repository's own pull request list.
How we keep it true
This service is never finished. Each month's summary shows what was reviewed and how each finding ended, and it continues until you end it.
Written review findings for up to five named pull requests Job Each time it fires
Up to five pull requests you name each get a written review: findings with severity, location and how to verify, plus what was not examined. It informs your reviewer; it does not approve a merge.
One review each time an in-scope pull request is opened, up to the agreed number a month
Each review meets the same standard as the one-off review you can buy on its own.
What is included, and what is not
- A written review on each in-scope pull request, posted as a Comment review through the account you invite with the Read role, or sent as a document if you prefer
- The monthly summary, comparable with your own pull request list
- A short note of recurring patterns across the month, with suggestions your team can adopt or ignore
Included
- One repository owned by a GitHub organisation, and its pull requests into the default branch that are opened or marked ready for review in the month, up to five a month, each up to 300 changed lines, or another number and size agreed in writing. Changed lines are the additions and deletions the platform shows, not counting lockfiles and generated files; a month is a calendar month and unused reviews do not carry over
- A written review of each pull request in scope: findings by severity with file and line, the reason and a way to verify, and a note of what was not examined
- One re-read of the changed parts if the author updates a pull request after our review
- A monthly summary: pull requests reviewed, findings by severity and kind, the findings your team accepted or dismissed, taken from your own responses, and any pull request we did not reach
Not included
- Approving or blocking a merge: the merge decision and your branch rules stay with your team. Reviews are posted as comments only, never as Approve or Request changes
- Write access of any kind, or a repository owned by a personal account: GitHub gives collaborators on a private repository owned by a personal account write access only, never read-only, so we cannot take such a repository on this service
- Pull requests above the agreed monthly number or size, which are quoted separately
- Fixing findings, writing tests or deploying
- A security audit, a compliance review or any statement that a change is safe to run in production
- Out-of-hours cover or any guaranteed response time
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Each in-scope pull request has a written review in which every finding states a file and line, what is wrong or risky, why it matters and how to verify it.
Evidence: The reviews, which you can read finding by finding against those four fields.
Each month's summary lists every in-scope pull request, its findings by severity and how each finding ended, and any pull request that was not reviewed.
Evidence: The monthly summary compared with your repository's own pull request list.
No review approves or blocks a merge or states or implies that a change is safe to run in production, and every review is posted as a Comment review.
Evidence: The reviews as posted, their review type on the platform and your own reading of their wording.
The invited account holds the Read role and no other role on the one repository throughout the month.
Evidence: The repository's access list showing the account and its role.
Sign-off. You read the reviews and the monthly summary and decide what to do with each pull request. The service counts as delivered for a month when the summary is accepted.
If it fails. If we miss a pull request in scope, it does not count against the monthly number and we say so in the summary. If the service is not working for you, you can end it at the end of any month.
When it fits, and when we stop
It fits when
- One repository owned by a GitHub organisation, where a company-controlled account can be invited with the Read role; GitHub says anyone with read access can review and comment on a pull request. A private repository owned by a personal account is not eligible, because GitHub offers collaborators on it write access only. Moving it into an organisation is your decision and happens before the service starts
- A person on your side decides on each pull request and tells us when a finding is accepted or dismissed
- Pull requests contain no production data or secrets
We stop and tell you if
- The repository is private and owned by a personal account, or the only way to give us access is a role above Read: we decline the service, because we will not hold write access to review code
- Pull requests regularly exceed the agreed number or size, so reviews would become skims: we agree a different scope with you
- Pull requests regularly contain secrets or customer data
- Nobody acts on or answers the findings for two months in a row: we ask whether the service is still useful and may stop it
What could go wrong
A review changes nothing in your repository. Comments can be deleted by your maintainer, and removing the invited account ends our access. Ending the service leaves your repository exactly as it is, with open reviews finished or handed back.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| Reviews become rubber stamps, or noise that people stop reading. | The monthly summary shows how many findings your team accepted and dismissed, and the service stops being useful by its own numbers if nobody acts; either side can end it at the end of a month. |
| A review is read as approval to merge. | Reviews carry a not-examined list, never approve or block, and say plainly that the decision is yours. |
| The invited account gives us more access than you intended. | We ask only for the Read role on one organisation-owned repository and never accept write access. You create the invitation, see the account's role in the repository's access list and can remove it at any time. |
A second reviewer checks a sample of each month's reviews for unsupported claims and approval-like wording. No human supervisor is included unless your agreement names one. At launch the work is largely automated, and we say so.
Stays with a person
- You decide whether to merge every pull request
- You approve any change to the agreed monthly number or size
Access we would need
- The Read role on one organisation-owned repository, through an account you invite; comments only, no write access
Questions
How is this different from buying one review?
A one-off review covers a set of pull requests you name, once, and costs less. This service reviews each in-scope pull request as it opens, month after month, with one re-read when the author updates it, a monthly summary of how each finding ended and a note of recurring patterns, so it is priced above the one-off.
Do you approve or block merges?
No. Reviews are posted as comments with findings, never as Approve or Request changes. Approving, blocking and merging stay with your team and your branch rules.
Can you review a private repository on my personal GitHub account?
Not on this service. GitHub gives collaborators on a private repository owned by a personal account write access only, and we will not hold write access to review code. Moving the repository into an organisation is your decision; the invited account then needs only the Read role.
What if we open more pull requests than the agreed number?
We tell you, and the extra ones are quoted separately or the agreed number is changed in writing. We do not skim them.
Send an enquiry
Send us
- The hosting platform, roughly how many pull requests the repository gets a month and how large they usually are
- The language and framework in general terms, and how merging is decided today
- Who on your side will read the reviews and answer them
- Do not send code, credentials or an access invitation in the first enquiry
Later, once you agree
- An invitation for a company-controlled account to the one organisation-owned repository with the Read role and no other role
- The agreed monthly number and size, the person to ask when intent is unclear and how your team will tell us what was accepted or dismissed
- Instructions to run the tests, if they help the review
Your repository, branch rules and merge decisions stay yours. We read pull requests and post comments through an account you invite to one organisation-owned repository with the Read role, which GitHub says is enough to review and comment, and which you can remove at any time. We never ask for write access. GitHub gives collaborators on a private repository owned by a personal account write access only, never read-only, so such a repository is not eligible. We do not approve, block, merge or change anything in the repository.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “review-every-pull-request-on-one-repository” as the subject.