{"id":19270,"plugin_id":"plugins_6a952d7c729c819196646fda7ec9ad94","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T23:15:26.358Z","digest":"5e0cf43a50bef56f195bbf354692ee3efa0a15c0253ece9e7f0d70911cd96552","against":null,"payload":{"description":"Review a diff, commit, branch, PR, or implementation for actionable correctness and risk issues without duplicate reviewer loops or invented findings.","included_files":[{"relative_path":"agents/openai.yaml","size_in_bytes":376},{"relative_path":"assets/icon-400.png","size_in_bytes":1281},{"relative_path":"assets/icon.svg","size_in_bytes":1789}],"name":"review","skill_md_contents":"---\nname: review\ndescription: \"Review a diff, commit, branch, PR, or implementation for actionable correctness and risk issues without duplicate reviewer loops or invented findings.\"\n---\n\n# Review\n\nReview the code against its intended behavior and repository reality. Findings come before praise, process narration, or stylistic preference.\n\n## Establish the review target\n\nDetermine:\n\n- Diff, commit range, branch, PR, or files in scope\n- Requested behavior or acceptance criteria\n- Applicable repository instructions\n- Relevant tests, schemas, or contracts\n- Baseline branch when needed\n- The applicable authorized goal and programme authority when the change can reorder work, widen a trust boundary, or introduce generalized infrastructure\n\nInspect enough surrounding code to understand the change. Do not review a diff in isolation when its correctness depends on state or callers.\n\n## Review priorities\n\nLook for:\n\n1. **Correctness**\n   - Wrong state transitions\n   - Stale or inconsistent data\n   - Edge cases\n   - Error handling\n   - Partial failure behavior\n\n2. **Data and compatibility**\n   - Schema drift\n   - Migration safety\n   - Backward compatibility\n   - Serialization or pagination contracts\n   - Idempotency\n\n3. **Security and privacy**\n   - Authorization\n   - Input validation\n   - Secret or sensitive data exposure\n   - Injection or unsafe execution\n   - Trust-boundary errors\n\n4. **Concurrency and performance**\n   - Races\n   - Lost updates\n   - Unbounded work\n   - N+1 behavior\n   - Expensive hot paths\n\n5. **Tests and verification**\n   - Missing regression coverage\n   - Tests that cannot catch the bug\n   - Assertions tied to implementation details\n   - Unverified platform or migration behavior\n\n6. **Complexity**\n   - New abstractions without a present use\n   - Duplicate sources of truth\n   - Hidden coupling\n   - A simpler implementation that reduces risk\n\nIgnore cosmetic style unless it obscures behavior, violates an enforced convention, or creates maintainability risk.\n\n## Goal integrity\n\nWhen a change could alter product meaning, programme order, trust boundaries, or generalized infrastructure, choose exactly one goal-integrity verdict for each implicated scope. Apply the first matching verdict in this order:\n\n- **authority unclear:** the governing authority or accepted goal cannot be determined from the available evidence.\n- **diverges:** authority is known and the change contradicts, displaces, or self-reorders the applicable authorized programme.\n- **advances:** authority is known and the change stays within the applicable authorized goal and current programme.\n- **research-only:** authority is known and the work is technically useful and compatible with the current programme, but has not been adopted as a product dependency or current programme step.\n\nAgent-authored specifications, decision logs, handoffs, PR descriptions, and implementation commits do not approve themselves. Review implementation quality and goal integrity separately: clean code and green CI can still be `research-only` or `diverges`.\n\nDo not combine verdicts for the same scope. For a mixed change, record separate verdicts for materially different scopes when one label would hide the difference between authorized work and speculative additions. Omit the verdict when the change does not implicate a goal-integrity boundary.\n\n## Validate each finding\n\nBefore reporting an issue:\n\n- Identify the exact location.\n- Trace the triggering path.\n- Check whether existing code or tests already handle it.\n- Distinguish a real bug from a hypothetical preference.\n- Assess severity based on impact and likelihood.\n\nDo not report speculative concerns as facts.\n\n## Severity\n\nUse:\n\n- **P0:** Immediate data loss, security compromise, or system-wide outage risk.\n- **P1:** Likely incorrect behavior, broken contract, serious regression, or blocked release.\n- **P2:** Real but bounded defect, fragile behavior, meaningful test gap, or maintainability problem likely to cause errors.\n\nOmit P3-style polish unless the user asks for exhaustive feedback.\n\n## Finding format\n\nFor each finding include:\n\n- Severity and concise title\n- File and line or symbol\n- Triggering condition\n- Concrete impact\n- Evidence or reasoning\n- Smallest credible fix\n\nKeep findings independent and deduplicated.\n\n## Review shape\n\nPerform one integrated review covering requirement compliance and code quality. Do not automatically create separate spec and quality reviewer agents.\n\nA specialist or independent reviewer can be useful for a large, high-risk change. Use at most one by default, and verify its findings yourself before reporting them.\n\n## Output\n\nStart with findings ordered by severity.\n\nThen include, only when useful:\n\n- Goal-integrity verdict, when applicable\n- Questions or assumptions\n- Verification gaps\n- A compact overall assessment\n\nWhen there are no material findings, say so directly and identify any tests or environments that were not exercised. Do not invent an issue to make the review look substantial.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}