Job review-written-findings-for-named-pull-requests · revised 11 October 2026
Written review findings for up to five named pull requests
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.
You might be seeing
- Pull requests are merged after a quick look because nobody has time to read them properly
- Work from an outside developer is accepted without anyone on the team having checked it
No passwords, keys, card details or admin invites needed to start.
What usually happened
A pull request is about to be merged on trust. The author is a contractor, a new hire or the only developer, or the change is too big for the reviewer to read closely, so defects, missing tests and unclear design reach the main branch unchallenged. The job produces an independent written review of the named pull requests. The decision to merge, and responsibility for the code, stay with you.
Who it’s for: A founder or engineering manager with a pull request waiting for merge that nobody on the team has the time or the context to review carefully, such as a contractor's or agency's work, or a change from the only developer.
Usually starts when: A large or risky pull request is about to be merged on trust, or work from a contractor or agency is about to be accepted and no one else has read it.
The result: Each named pull request has a written review listing findings by severity, each with its location, explanation and a way to verify it, plus a list of what was not examined. Your own reviewer can act on every finding without asking us what we meant.
Check whether this job fits
Describe the pull requests, not their code. These checks show whether a bounded written review is the right help.
Checks you can run yourself
Write the intent of each change in a sentence
For each pull request, write what it is supposed to do and what could go wrong if it were wrong. Use plain words and no code.
Look for: A change where you cannot say what it is for is a finding already. Changes where a mistake would be costly belong first in the set.
What you get
- One written review per pull request, ordered by severity, each finding with file and line, what is wrong or risky, why it matters and how to check it
- A summary across the set: patterns we saw, the changes that matter most before merging, and what is done well
- A not-examined list for each pull request: files, behaviours, environments and risks we did not or could not assess
- On request, the findings posted as comments on the pull request through an account you invite for that purpose
Included
- Up to five named pull requests in one repository, within a total size agreed before work (as a guide, up to about 1,500 changed lines in all)
- Read each change in full, with the surrounding code it touches, against what its description says it should do
- Check design fit, correctness and edge cases, error handling, tests that were added or are missing, readability and documentation that should change
- Where a suspected defect can be shown, show it with a failing test or a traced input; otherwise label the finding as suspected
Not included
- Approval of the pull requests, a statement that they are safe to merge or to run in production, a security audit or any compliance review
- Fixing the findings, writing the missing tests or merging anything
- Changes that can only be assessed with production data, credentials or a live system
- A review of the whole repository or its architecture, or of generated, vendored and minified files unless you name them
- Style enforcement beyond findings that affect readability or correctness
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Every finding states a file and line, what is wrong or risky, why it matters and how to verify it, and no finding rests on style preference alone without a stated reason.
Evidence: The written reviews, checked finding by finding against these four fields.
Every finding labelled a defect is supported by a failing test or a traced input that shows it; every other finding that cannot be shown is labelled suspected.
Evidence: The attached failing tests or traces, and the labels on each finding.
Each pull request has a not-examined list naming the files, behaviours and environments that were not assessed, and no review text states or implies that a change is approved or safe to ship.
Evidence: The not-examined lists and a read of the review wording by the second reviewer.
For three findings you choose across the set, your reviewer can find the code and follow the verification steps without any further explanation from us.
Evidence: Your reviewer's written confirmation for each of the three findings.
Sign-off. Your reviewer reads the reviews, tries the spot-check findings, signs off in writing and decides what to do with each pull request. Payment follows sign-off.
If it fails. If the reviews do not meet the agreed checks, you do not pay for this fixed scope. If a change cannot be assessed with the access or information available, we say so in its not-examined list and stop short of guessing.
When it fits, and when we stop
It fits when
- You can name the pull requests, say what each should achieve and say who on your side decides on each
- The changes can be shared through an authorised company-controlled read-only route after agreement, with no production data or secrets in them
- The language and framework are named at enquiry so we can confirm we can read the code and run its tests where that helps
We stop and tell you if
- A change contains secrets or customer data: we stop and ask you to remove it and rotate any credential before we look further
- The set is far larger than agreed: we propose a split or a larger quote instead of skimming
- The change cannot be understood without domain knowledge or documents you cannot provide
What could go wrong
A review changes nothing in your repository, so there is nothing to undo. If comments were posted on a pull request at your request, your maintainer can delete them, and removing the invited account ends our access.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A review with few findings is read as approval to ship. | Every review states what was and was not examined, says plainly that it is not an approval or a statement of safety, and reports a clean result as no findings in the areas examined. |
| False findings cost your team time. | Each finding says how to verify it, defects are shown with a failing test or traced input where possible and are otherwise labelled suspected. |
| A reviewer misses a real defect. | A review lowers the chance of a defect reaching production but cannot find all of them. We say so in the handover and describe what we did not cover. |
| Confidential code is exposed while it is being read. | Access is read-only through an authorised route, the code stays in an isolated workspace, and we agree before work when it is deleted. |
A second reviewer reads each draft for unsupported claims, missing areas and language that implies approval. Merging, and every decision about the pull requests, stays with your authorised maintainer.
Need to keep it working?
A review of every new pull request on a repository is offered separately as a monthly service.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Google's published engineering practices list what a reviewer should look for: design, functionality, complexity, tests, naming, comments, style and documentation. A senior colleague can use it as a checklist. google.github.io
- If you have no one to review, GitHub lets anyone with read access comment on a pull request, so an outside reviewer you already trust can be invited without giving write access. docs.github.com
Questions
Is this an approval of the code?
No. It is a written review that informs your reviewer. We do not approve changes, certify them as safe to run in production or replace your own decision to merge.
Will you fix what you find?
No. Each finding says how to verify it. Fixing one defect with a regression test is a separate job.
Is this a security audit?
No. If we see something that looks like a weakness we say so, but a security audit or compliance review is a different, larger scope that we do not offer here.
Can the findings go straight onto the pull request?
Yes, on request, through an account you invite for the purpose. Otherwise you receive them as a document.
Send an enquiry
Send us
- How many pull requests, their rough size and the language and framework, in general terms
- What each change is meant to do, in a sentence, and who decides whether it is merged
- Whether the repository has tests that can run without production services (yes or no)
- Do not send code, diffs, credentials or customer data in the first enquiry
Later, once you agree
- Read-only access to the named pull requests and the code they touch, through an authorised company-controlled route you approve
- The description of intent for each change and instructions to run the tests
- The person we ask when intent is unclear, and the person who accepts the review
You own the repository and every decision about merging. We read the named pull requests with read-only access through a company-controlled identity, never a personal login, and keep the code in an isolated workspace for the length of the job. We do not merge, approve or change anything in your 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-written-findings-for-named-pull-requests” as the subject.