aictrl-dev Review a Code Change
Produce high-signal findings for the exact pull or merge request revision. Review only; do not fix code.
Workflow
- Resolve the repository, request identifier, base revision, and exact head SHA. Record the SHA in the review so stale findings are detectable.
- Load repository guidance and the request description, linked issue, commits, changed files, tests, and CI state. Inspect surrounding production code rather than judging the diff in isolation.
- Build a change map: entry points, data and control flow, public contracts, persistence, authorization, failure paths, concurrency, and test coverage.
- Review for concrete defects in:
- behavior and requirement coverage;
- security, privacy, authorization, and tenant isolation;
- error handling, retries, idempotency, concurrency, and cleanup;
- data/schema compatibility, migration, and rollback;
- performance and resource bounds;
- API/type/UI consistency and accessibility;
- missing negative, boundary, regression, and integration tests.
- Run focused verification when safe. Never present a theoretical concern as reproduced behavior.
- Before reporting a finding, prove that it is introduced or exposed by the reviewed change, has a specific impact, and is not already prevented elsewhere.
- Assign
BLOCKER,MAJOR,MINOR, orNIT. Include file/line, evidence, failure scenario, and the smallest sound remediation. - Return findings only. If none meet the bar, say so and list residual test or environment limitations.
- Post a provider review only when the user explicitly asks. Bind the posted review to the recorded head SHA.
Finding format
### [MAJOR] <imperative, specific title>
- Revision: `<head-sha>`
- Location: `path/to/file.ext:line`
- Evidence: <what the changed code does>
- Impact: <observable failure or risk>
- Fix: <smallest sound remediation>
- Verification: <test or check that proves the fix>
Boundaries
- Do not edit code, commit, push, dismiss findings, or merge.
- Do not report style preferences unless they create a documented correctness or maintenance risk.
- Do not reuse findings from an older head without revalidating them.
- Separate verified defects from residual risk and untested hypotheses.
Built by aictrl.dev. This skill teaches the workflow; aictrl operationalizes it — grounded in your backlog, team standards, and codebase knowledge graph. See how →