code-review-checklist-runner
Purpose
Apply a disciplined checklist to source changes so correctness, design, security, testability, and maintainability concerns are not missed.
Trigger this skill when
- You need a focused code-review or inspection analysis or artifact rather than generic commentary.
- Review discipline, issue handling, or closure quality matters to the outcome.
- You need a reusable output another reviewer, developer, or agent can extend safely.
Expected inputs
- code diff or source files
- review scope and checklist focus
- related requirements or issues
- test evidence if available
Deliverables
- checklist-based findings
- issue list with rationale
- evidence gaps
- recommended next skill
Operating procedure
- Clarify the artifact, review objective, and what counts as a meaningful issue.
- Separate explicit evidence from assumptions, missing context, or inference.
- Apply the relevant review structure, checklist, or inspection framing consistently.
- Produce compact findings that support triage, rework, and decision-making.
- Recommend the next most useful review, remediation, readiness, or process step.
Quality gates
- Do not treat preference as defect unless the criterion is explicit.
- Make severity, uncertainty, and evidence quality explicit.
- Prefer actionable findings tied to consequence over vague style commentary.
- Keep the artifact compact, structured, and reusable.
Handoff targets
- review-issue-categorizer
- review-severity-scorer
- rework-plan-writer
Output style
- Be explicit about evidence quality and uncertainty.
- Prefer structured findings over narrative filler.
- Tie recommendations to risk, delivery consequence, or rework cost.
- Use severity, priority, or confidence labels when useful.
Failure modes to avoid
- Do not collapse all issues into one undifferentiated list.
- Do not hide missing evidence, unclear criteria, or reviewer uncertainty.
- Do not recommend vague actions with no owner or closure path.
- Do not ignore process defects when the artifact issues are symptoms of review failure.
Minimum output skeleton
## Summary
## Findings
## Structured outputs
## Evidence / confidence
## Assumptions
## Open questions
## Recommended next skill
1---2name: code-review-checklist-runner3description: code-review-checklist-runner4---5# code-review-checklist-runner67## Purpose8Apply a disciplined checklist to source changes so correctness, design, security, testability, and maintainability concerns are not missed.910## Trigger this skill when11- You need a focused code-review or inspection analysis or artifact rather than generic commentary.12- Review discipline, issue handling, or closure quality matters to the outcome.13- You need a reusable output another reviewer, developer, or agent can extend safely.1415## Expected inputs16- code diff or source files17- review scope and checklist focus18- related requirements or issues19- test evidence if available2021## Deliverables22- checklist-based findings23- issue list with rationale24- evidence gaps25- recommended next skill2627## Operating procedure281. Clarify the artifact, review objective, and what counts as a meaningful issue.292. Separate explicit evidence from assumptions, missing context, or inference.303. Apply the relevant review structure, checklist, or inspection framing consistently.314. Produce compact findings that support triage, rework, and decision-making.325. Recommend the next most useful review, remediation, readiness, or process step.3334## Quality gates35- Do not treat preference as defect unless the criterion is explicit.36- Make severity, uncertainty, and evidence quality explicit.37- Prefer actionable findings tied to consequence over vague style commentary.38- Keep the artifact compact, structured, and reusable.3940## Handoff targets41- review-issue-categorizer42- review-severity-scorer43- rework-plan-writer4445## Output style46- Be explicit about evidence quality and uncertainty.47- Prefer structured findings over narrative filler.48- Tie recommendations to risk, delivery consequence, or rework cost.49- Use severity, priority, or confidence labels when useful.5051## Failure modes to avoid52- Do not collapse all issues into one undifferentiated list.53- Do not hide missing evidence, unclear criteria, or reviewer uncertainty.54- Do not recommend vague actions with no owner or closure path.55- Do not ignore process defects when the artifact issues are symptoms of review failure.5657## Minimum output skeleton58```md59## Summary60## Findings61## Structured outputs62## Evidence / confidence63## Assumptions64## Open questions65## Recommended next skill66```