Prompts for code review and release readiness
Ask Codex or Claude Code for evidence-backed findings, then prepare a release decision that records verification, operating needs, and recovery.
017 · Review a specific change against the requirement
Use when: there is an identifiable change to inspect. Codex is Nicholas’s usual reviewer; Claude Code can review too. Start with read-only access and explicitly permitted non-destructive checks.
Bring: the approved requirement, revision, business rules, and previous review decisions. Check: each material finding has evidence and a consequence; a human resolves it rather than counting model approvals.
Review this change. Do not edit files or production data.
Requirement and acceptance criteria: [source]
Revision or diff: [exact change]
Important business rules and design decisions: [source]
Previous findings and resolutions: [source, if any]
Allowed verification actions: [read-only inspection and named safe checks]
Read the connected code and callers, not only the diff. Prioritize incorrect behavior, authorization boundaries, data loss, partial failure, regressions, and missing checks for material risk. Check whether the tests exercise the real product behavior.
For each finding, give severity, file and location, a concrete scenario, evidence or reproduction steps, and user impact. Separate confirmed defects from questions. Do not repeat a resolved finding without new evidence. If no material finding is supported, say so and state the verification limits. Do not give a safety guarantee.028 · Prepare a release decision and handoff
Use when: implementation and review are complete enough for the release owner to decide. This prompt prepares evidence; it does not authorize deployment.
Bring: the final revision, review resolutions, check output, deployment process, and recovery requirements. Check: the owner can see what is ready, what is unknown, and who is responsible afterward.
Prepare a release-readiness note for human review. Do not deploy or modify data.
Candidate revision: [exact version]
Acceptance criteria and check results: [evidence]
Review findings and resolutions: [record]
Deployment and configuration: [current process]
Data changes and recovery requirements: [details or none]
Support owner and access handoff: [agreed responsibilities]
List what is verified, what is not verified, unresolved blockers, required configuration or permissions, and checks to run after deployment. Explain recovery limits, including whether reverting code would leave data changes behind.
Record the AI tools and model versions used when known; mark unknown values as unknown. Note any approved usage costs and unresolved billing terms without inventing amounts.
End with the specific decisions the release owner must make and the operating information the team needs after handoff.03Use the result to make a human decision
A release note is useful when it points to evidence and makes uncertainty visible. It does not replace a deployment policy, the agreed support arrangement, or the engineer’s understanding of the system.
Discuss an AI-assisted project →