Prompt file imported from ssarode41/to-dos (
.github/prompts/pre-pr-code-review.prompt.md). Copyright stays with the author.
Use the repository-wide instructions and, when test automation is part of the change, the QA test automation skill.
Review the supplied implementation before a pull request is created. Read the Jira story and the relevant requirements, architecture, design review, and implementation plan artifacts when they exist. Inspect the working-tree or pull-request diff and nearby tests.
Review Every Area
- Correctness: Verify each changed component against requirements and acceptance criteria, including invalid input, missing fields, empty results, Not Found behavior, state transitions, and compatibility.
- Security: Check input validation, authorization boundaries, secret exposure, sensitive logs, injection risks, unsafe defaults, and excessive data exposure.
- Error Handling: Check API failures, missing files, empty repositories, dependency failures, timeouts, partial failures, safe responses, retries, cleanup, and user-visible error states.
- Test Coverage: Check happy paths and relevant negative, boundary, missing-field, Not Found, empty-result, and failure cases at the lowest meaningful test level.
- Code Clarity: Check names, control flow, repository conventions, complexity, and whether logic is understandable without unnecessary comments.
- DRY Principle: Identify meaningful duplicated logic and recommend shared abstractions only when they improve cohesion and maintainability.
- Dependency Safety: Inspect package and lockfile changes; run safe audit tooling when configured, and distinguish verified vulnerabilities from items requiring external confirmation.
Review Rules
- Do not modify code, tests, dependencies, configuration, or planning documents.
- Run only read-only or non-mutating validation commands when useful; record exact commands and results.
- Report findings first, ordered by severity: Blocker, High, Medium, Low, Informational.
- Every non-informational finding must include a unique ID, location, confidence, evidence, impact or failure scenario, remediation, and focused verification step.
- If a review area has no issue, mark it Pass with evidence. If it cannot be assessed, mark it Unable to Verify and explain why.
- Redact secrets and sensitive data. Never fabricate test results, dependency audit results, approvals, or CI links.
Output
Return:
## Findings
### CR-001: <short title> (High)
- Location:
- Confidence:
- Requirement or decision:
- Evidence:
- Impact or failure scenario:
- Recommendation:
- Verification:
## Open Questions and Assumptions
## Checklist Results
| Review area | Status | Evidence or notes |
|---|---|---|
| Correctness | Pass | ... |
| Security | Pass | ... |
| Error Handling | Pass | ... |
| Test Coverage | Pass | ... |
| Code Clarity | Pass | ... |
| DRY Principle | Pass | ... |
| Dependency Safety | Unable to Verify | ... |
## Validation
| Command or check | Result | Notes |
|---|---|---|
## PR Readiness
- Recommendation: Ready | Ready with follow-ups | Changes Required | Blocked
- Blocking findings:
- Required actions before PR:
- Accepted risks and owners:Do not claim the PR is ready unless the evidence supports that conclusion.