Give a reviewer the exact change, the intended behavior, and a place to record actionable findings. Copy the checklist on its own, or use it as the starting task for your Engineering team.
Code review checklist · Built on the Engineering team
1 / Code Review Agent
Read the change with its callers and state owner. Record the trigger and consequence of each supported finding.
2 / QA Agent
Check invalid inputs, access differences, retries, and cancellation where they affect this change. Identify missing coverage.
3 / CI Investigation Agent
Separate passed, failed, pending, and unobserved checks for the exact revision. Return a packet for the human reviewer.
Illustrative outputs. Your team works from your own materials.
Fictional example. Replace these details with evidence from your own work.
Scope: fictional payment adapter change, base demo-a → head demo-b.
Finding: a timed-out request is retried with a new operation ID.
Evidence: fictional adapter.ts lines 42–55; the first outcome is not reconciled.
Consequence: the same operation could run twice.
Next check: preserve the operation identity and exercise an unknown first outcome.
A finding explains a reachable consequence and the evidence needed to resolve it.
This example explains the task. It is not a live run or a customer result.
Start with what you already have. The team can ask for missing details before preparing the next step.
Copy the starting task and adapt it to your work. With the Engineering team in your workspace, share it with Engineering Agent alongside your source materials.
Team installation is currently in limited access. You can explore the team and copy the task and reference files here.
Editable template
engineering-code-review-task.md
# Prepare a code review packet Engineering Agent: coordinate a review of the supplied change with Code Review, QA, and CI Investigator. Use only supplied or authorized repository context. Repository / source: Base revision: Head revision: Expected behavior and acceptance criteria: Out of scope: Supplied CI and manual evidence: Human reviewer: Read the exact diff and affected callers. For each supported finding include severity, location at the reviewed revision, trigger, consequence, and the smallest useful next check. Keep questions separate from findings. Check whether another existing owner already handles the proposed behavior. Return: scope receipt; prioritized findings; evidence by check and revision; unresolved questions; suggested next actions. Clearly mark absent, stale, failed, and pending evidence. Do not claim unperformed validation passed. Do not approve, merge, deploy, or contact external parties. Request missing access from the user.
Use these editable templates as inputs or work with them on their own. Free to copy and download. Worked examples use fictional records.
Editable template
engineering-code-review-checklist.md
# Code review checklist Repository: Base → head revision: Reviewer / date: Expected behavior: Reviewed files and callers: Excluded areas and reason: Use Observed / Issue / Unverified / Not applicable, with a source for each line. A checked box is not a CI receipt. - [ ] Scope: does the diff implement the stated behavior without unrelated changes? - [ ] Ownership: does the existing state owner remain responsible for updates? - [ ] Inputs: what happens for empty, malformed, large, or unavailable inputs? - [ ] Access: is the operation checked for the actual user and target resource? - [ ] Ordering: can concurrency, retries, timeouts, or cancellation repeat or lose work? - [ ] Data: can readers handle the new representation during rollout and rollback? - [ ] Errors: are failures useful to users without exposing private details? - [ ] Coverage: do relevant tests exercise the failure or boundary, and which revision ran? - [ ] UX: are changed states understandable and usable with keyboard and narrow screens? - [ ] Maintenance: can this reuse an existing mechanism and remove replaced code? ## Findings Severity / exact location / trigger / consequence / evidence / next check: ## Evidence Check / revision / observed status / receipt / missing scope: ## Questions and handoff Question / owner / required evidence / status: Human decision and date:
Fictional worked example
engineering-code-review-example.csv
| record_id | record_type | severity | revision | location | observation | consequence | next_check | status |
|---|---|---|---|---|---|---|---|---|
| F-01 | fictional finding | high | demo-b | adapter.ts:42-55 | Timeout retry creates a new operation ID | An unresolved request could run twice | Reconcile original outcome and test retry identity | open |
| Q-01 | fictional question | unrated | demo-b | CI evidence | Recovery receipt was not supplied | Readiness cannot be concluded | Ask CI owner for exact revision receipt | unverified |
Start with the exact change and intended behavior, then examine affected ownership, access boundaries, failure paths, tests, and maintainability. Record evidence for findings and separate unresolved questions from confirmed defects.
This is a downloadable checklist and an optional task for an existing Engineering team. Repository access and available tools must be configured and authorized separately. Downloading it does not connect a repository or start a review.
No. The output is a review packet for the authorized reviewer. It does not approve, merge, modify branch settings, or deploy a change.
Name the inaccessible source and keep the affected conclusion unverified. Request the minimum additional context needed; do not infer success from a missing result.