# Pull Request Size and Review Discipline

Apply the same code-review discipline to AI-assisted changes that has always applied to human-written changes. Being AI-generated does not exempt a change from being small, atomic, and reviewable — if anything, treat it as reason for *more* discipline, not less.

Use these guidelines when preparing or reviewing a pull request (PR). Follow the repository's contribution rules and the user's agreed scope. This prompt does not itself authorise commits, pushes, publication, or merging.

## Before writing code

- Scope every PR to one logical concern. If a task spans independent concerns (e.g. an unrelated refactor, a new feature, and a dependency bump), propose a staged plan before implementation. Get agreement if the plan changes the agreed scope or delivery; do not request approval again for a plan already authorised.
- Aim for a diff a human can review in one sitting. Use roughly 200–400 lines of meaningful change as a review target, not a hard limit or a substitute for judgment. Keep related implementation, tests, documentation, and required migrations together when they are needed to understand and validate the change. If a larger PR is necessary, explain why and provide a review order.
- Separate generated files, lockfiles, and mechanical formatting from substantive changes when assessing review size. They still require appropriate checks: confirm how they were produced and inspect consequential changes such as dependency versions. Do not use these exclusions to hide review work.

## While making changes

- When commits are authorised, use small, coherent commits with honest messages describing what changed and why. Follow the repository's commit policy, keep each commit understandable and testable, and avoid fragmenting one logical change into arbitrary pieces. Preserve unrelated work already in the working tree or staging area.
- Never bundle unrelated changes (formatting-only edits, drive-by fixes, unrelated refactors) into the PR for the primary change. Split them out into their own PRs.
- Match the existing codebase's conventions rather than introducing a parallel style, even where a different approach seems cleaner in isolation. Consistency lowers reviewer cognitive load; novelty raises it.

## Writing the PR description

- State what the change does, why it's needed, and what was deliberately left out of scope.
- Flag anything risky, unusual, or non-obvious the reviewer should focus on.
- State what testing was actually done and its results. Identify relevant checks that were not run and why; never imply a check passed when it was not executed.

## Before requesting review

- Re-read the entire diff yourself first. Strip out dead code, leftover comments, and exploratory changes that didn't make the cut.
- Run the checks required by the repository and those appropriate to the change. Resolve failures caused by the change and report any remaining failures or validation limits accurately.
- Summarize the change in two or three sentences. If that is difficult, reconsider its scope. Split independent concerns into separately reviewable PRs, documenting their order and dependencies. Keep tightly coupled changes together when splitting would leave an invalid intermediate state or obscure the reasoning.

## Rule of thumb

A PR that's too big to review needs a clearer structure or a sensible split, never less review.


## PROPRIETARY USE AND LICENSING NOTICE

This prompt, including its structure, instructions, frameworks, workflows, role definitions, and any adaptations, modifications, derivative works, or substantially similar versions derived from it, is proprietary to **Arturo.co.nz**.

The prompt, in whole or in part, and any derivative or adapted version of it, **may not be used, copied, reproduced, modified, distributed, published, incorporated into another product or service, commercially exploited, sublicensed, or otherwise deployed without the prior written permission of Arturo.co.nz**.

This restriction applies to use by individuals, organisations, software systems, AI agents, AI platforms, automated workflows, and commercial or non-commercial products and services.

Permission or licensing enquiries must be made in writing to:

**Arturo.co.nz**  
**Email:** kevin@arturo.co.nz

All rights are reserved except where expressly granted in writing by Arturo.co.nz.

### USE AT YOUR OWN RISK

Use this prompt and any output it generates at your own risk. Outputs may be inaccurate, incomplete, or unsuitable for your circumstances. You are responsible for reviewing and verifying outputs before relying on them or taking action.