Code review and quality
Review the smallest relevant change set and report evidence-backed findings before summaries.
Workflow
- Establish the intended behavior, changed files, compatibility boundary, and available verification evidence.
- Trace affected control flow and data flow. Prioritize defects that can change behavior, lose data, weaken authorization, leak secrets, or break compatibility.
- Check error handling, lifecycle/resource cleanup, concurrency, input validation, and boundary conditions only where the changed path makes them relevant.
- Check tests for the highest-risk behavior and failure modes. Do not request duplicate test layers when one sufficient layer proves the risk.
- Report findings by severity with a tight file/line location, concrete failure scenario, and the smallest defensible correction.
- If no actionable finding remains, say so and list material residual risks or verification gaps.
Boundaries
- Review does not authorize edits, commits, publication, deployment, or external writes.
- Do not invent defects from style preferences or hypothetical scale.
- Prefer deletion and simplification over speculative abstractions.
- Use
$security-and-hardening only when the review contains a material security boundary.
- Use
$performance-optimization only when measurements or a hot path justify performance analysis.
- Use
$verification-before-completion before claiming a requested fix is complete.
Output
For each actionable finding provide severity, location, impact, evidence, and minimal fix direction. Keep the overview after the findings.
1---2name: code-review-and-quality3description: Review existing code for correctness, maintainability, security, performance, and missing tests. Use for code-review or quality-audit requests; do not modify code unless the user also asks for fixes.4---56# Code review and quality78Review the smallest relevant change set and report evidence-backed findings before summaries.910## Workflow11121. Establish the intended behavior, changed files, compatibility boundary, and available verification evidence.132. Trace affected control flow and data flow. Prioritize defects that can change behavior, lose data, weaken authorization, leak secrets, or break compatibility.143. Check error handling, lifecycle/resource cleanup, concurrency, input validation, and boundary conditions only where the changed path makes them relevant.154. Check tests for the highest-risk behavior and failure modes. Do not request duplicate test layers when one sufficient layer proves the risk.165. Report findings by severity with a tight file/line location, concrete failure scenario, and the smallest defensible correction.176. If no actionable finding remains, say so and list material residual risks or verification gaps.1819## Boundaries2021- Review does not authorize edits, commits, publication, deployment, or external writes.22- Do not invent defects from style preferences or hypothetical scale.23- Prefer deletion and simplification over speculative abstractions.24- Use `$security-and-hardening` only when the review contains a material security boundary.25- Use `$performance-optimization` only when measurements or a hot path justify performance analysis.26- Use `$verification-before-completion` before claiming a requested fix is complete.2728## Output2930For each actionable finding provide severity, location, impact, evidence, and minimal fix direction. Keep the overview after the findings.
sciman-top