Job pull-request-and-commit-hygiene-set-up-and-measured · revised 12 October 2026
PR templates and checks so pull requests carry what reviewers and release notes need
A pull request template, a title and commit convention check and an optional drafted description. The share of pull requests meeting the template is measured before and after.
You might be seeing
- Pull request bodies are blank or say "fixes"
- Commit messages follow no convention
No passwords, keys, card details or admin invites needed to start.
What usually happened
Review, changelogs and automation all lean on what a pull request says about itself. When bodies are empty, every later step is slower or guesswork, and a tool that drafts descriptions can describe code that the diff does not contain.
Who it’s for: A team whose pull request descriptions are empty, so reviewers and release notes have nothing to work from.
Usually starts when: Reviewers keep asking "what is this for?" and release notes cannot be written from the titles.
The result: You get a pull request template, a check on titles and commit messages for new commits only, and an optional drafted description that is off by default. The share of pull requests meeting the template is measured before and after, and the check fails a planted bad pull request and passes a good one.
Check whether this job fits
Answer these without sending code, tickets or logins. Nothing is submitted unless you choose to contact us.
What you get
- The template and check workflow as a pull request you merge
- The before and after table
- The planted-bad-pull-request test
- The off-switch steps
Included
- One repository on GitHub Actions
- A pull request template and a title and commit convention check on new commits only; no history is rewritten
- An optional description drafter, off by default, checked on 5 of your diffs
- The share of pull requests meeting the template, 30 before and up to 30 after, with the table
- An off switch
Not included
- Rewriting or changing pushed history
- Enforcing the convention by blocking merges unless you choose it
- Training people to use the convention
- Release notes; see the release-notes job
- Making the drafter mandatory
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
The check fails a pull request we plant that breaks the convention and passes a good one, on the same trigger. This is a smoke test.
Evidence: The two run links.
The share of pull requests meeting the template is measured on 30 before and on 30 after, or on all that land within 60 days, and the table is shown.
Evidence: The before and after table with a link per pull request.
If the drafter is on, five drafted descriptions for diffs your maintainer picks are checked against those diffs by your maintainer, and none describes a change the diff lacks. This is a spot check, not a rate.
Evidence: The five descriptions, their diffs and the maintainer's verdicts.
No pushed commit was rewritten.
Evidence: The repository history, unchanged for existing commits.
Sign-off. Your maintainer reads the table and the planted test and signs off in writing. You merge the pull request. Payment follows sign-off.
If it fails. If the agreed checks do not pass, you do not pay for this fixed scope. We hand over what we found and agree whether to stop or re-quote; no surprise work.
When it fits, and when we stop
It fits when
- One repository on GitHub Actions
- A team that agrees to try a convention
- 30 recent pull requests to measure before
We stop and tell you if
- The team will not use any convention
- The repository has too few pull requests to measure
- You want history rewritten
What could go wrong
Close the pull request and nothing changes. After a merge, delete the template and workflow files. No history is touched.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A drafted description misdescribes the diff. | The drafter is off by default and five descriptions are checked against their diffs before you turn it on. |
| The convention is ignored and the check becomes noise. | The check starts as advice and the before and after table shows whether it is working. |
| Pull request text carries instructions meant for the model. | Pull request titles and bodies are treated as data: the model gets the text and returns drafts a script checks, with no tools and no network. If the drafter runs in your Actions it holds your restricted model key and nothing else. |
A separate automated reviewer checks the work before hand-over. Your maintainer agrees the convention and reads the drafted descriptions. No human supervisor is included unless your agreement names one, and at launch the work is largely automated.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree the convention, the checks and whether the drafter is on
- Measure 30 recent pull requests against the template
- Build the template, the check and the optional drafter on a branch
- Test a planted bad pull request and a good one; check 5 drafted descriptions
- Separate automated reviewer checks the workflow and token scope
- Hand over the pull request; measure again once 30 more pull requests land
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, price, start window and delivery date before you accept, and work starts only after agreed inputs, secure access and permissions are in place. Model usage up to a cap we state in writing is in the price, and an enquiry creates no charge or booking.
Need to keep it working?
To draft customer release notes from the improved descriptions, the release-notes job can follow.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
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
- Add a template file to .github yourself; GitHub documents pull request templates. docs.github.com
- Agree a one-line rule in review: no body, no review.
Questions
Do you rewrite our history?
No. The convention applies to new commits only.
Do I have to use the drafter?
No. It is off by default.
Will the check block merges?
Only if you choose that. It starts as advice.
Send an enquiry
Send us
- How many pull requests you merge a month and what the descriptions look like
- Whether you want the optional drafter
- No code or pull request text in the first enquiry
Later, once you agree
- Read-only access to one repository through a company-controlled route
- A branch for the pull request
- The name of your maintainer who agrees the convention
You keep the repository and every setting; we use a bot account with read-only access first, work on a fork or branch, and you merge. The check runs in your account and reads titles and messages only. To measure the before and after and check five drafts we read the repository through a Read-only route, and our automated agents read it in a sandbox; we make no "no training" or "no storage" promise here, and the agreement names the model provider, country, retention and training status before anything is shared.
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 “pull-request-and-commit-hygiene-set-up-and-measured” as the subject.