{"id":18340,"plugin_id":"plugins_6a88e6256bb48191a343d39dace5e05c","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T23:14:47.237Z","digest":"a27de3fd0bde0871ad94634d7adbecf5762356b8ae80e692199e9adb12a6d1f3","against":null,"payload":{"description":"Review changed code before commit or PR with fast checks plus SOLID, security, performance, and test coverage audit.","included_files":[],"name":"code-review","skill_md_contents":"---\nname: code-review\ndescription: Review changed code before commit or PR with fast checks plus SOLID, security, performance, and test coverage audit.\nargument-hint: '[--base-branch <branch>]'\nallowed-tools: Read Grep Glob Bash\neffort: high\n---\n\n# code-review\n\nTwo-phase code review skill. Phase 1 catches surface-level issues fast. Phase 2 audits structural correctness using SOLID as the primary framework and KISS/DRY/YAGNI for implementation quality.\n\n## Usage\n\n**With a base branch** — reviews only the files changed between your current branch and the specified base:\n```\n/code-review --base-branch main\n/code-review --base-branch develop\n/code-review --base-branch origin/main\n```\n\n**Without arguments** — Claude will detect your local branches and ask you to pick the base interactively:\n```\n/code-review\n```\nYou'll be prompted with a question like:\n> \"Which branch should be used as the base for this review?\"\n> Options: `main`, `master`, `develop`, or any other local branch detected. Select one or type a custom name.\n\n> **Tip:** Run `/init-project` first if the project has no `AGENTS.md`. The review uses it for stack-aware checks in Phase 1.\n\n---\n\n> **Mindset**: There is no reward for speed. The reward comes from persistence on resolving issues to a high standard. Consistent iteration produces better outcomes than fast completion.\n\n---\n\n## Setup — Resolve Base Branch\n\nCurrent branch: `!git branch --show-current`\n\nAvailable local branches:\n```\n!git branch\n```\n\n**Step 1 — Parse the argument.**\nCheck if `$ARGUMENTS` contains `--base-branch`. If it does, extract the value that follows it and use that as `BASE_BRANCH`. Skip to Step 3.\n\n**Step 2 — Ask the user (only if `--base-branch` was not provided).**\nUse `AskUserQuestion` with the following question:\n\n- Question: \"Which branch should be used as the base for this review?\"\n- Header: \"Base branch\"\n- Build the options from the branch list above. Always include the most common default (`main`) plus any branches found locally. Cap at 4 options; if there are more, include the 3 most relevant and leave \"Other\" for free input. If there is no more options but default, just use the default.\n\n**Step 3 — Scope the review to changed files.**\nRun:\n```\ngit diff <BASE_BRANCH>...HEAD --name-only\n```\nRead only the files returned by that command. Do not review files that were not changed relative to `BASE_BRANCH`.\n\nIf the diff is empty, inform the user: \"No changes detected between the current branch and `<BASE_BRANCH>`.\" and stop.\n\n---\n\n## Phase 1 — Fast Pre-Commit Check\n\nCatch the 80% of issues before going deeper. Run this first.\n\n### 1.1 Spec & Logic\n\n- [ ] Code exactly matches the stated requirements — no more, no less\n- [ ] Edge cases are handled: empty states, null/undefined, error boundaries\n- [ ] No leftover debug artifacts: `console.log`, commented-out code, TODO-without-ticket\n\n### 1.2 Type Safety & Validation\n\n- [ ] No unconstrained `any` / `unknown` casts without justification\n- [ ] External input (API responses, form data, env vars) is validated at the boundary\n- [ ] Types are derived from a single source of truth — not duplicated across files\n\n### 1.3 Stack Alignment\n\nCheck the detected stack (see `AGENTS.md` if available) and verify conventions are followed:\n- Framework-specific patterns are used correctly (e.g., server vs. client components, lifecycle hooks, routing conventions)\n- Styling follows the project's chosen approach consistently\n- ORM/database queries follow the project's data-access layer patterns\n\n### 1.4 Verification\n\n- [ ] Existing tests pass\n- [ ] New behavior has test coverage (unit or integration)\n- [ ] There is observable evidence the change works (test output, screenshot, logs)\n\n\n### 1.5 Security Checks\n\n- [ ] No hardcoded secrets or credentials\n- [ ] No sensitive data in logs or error messages\n- [ ] Input validation prevents injection attacks\n- [ ] Dependencies are up to date\n\n### 1.6 Performance Checks\n\n- [ ] No N+1 queries\n- [ ] No unnecessary database queries\n- [ ] No unnecessary API calls\n- [ ] No unnecessary computations\n\n**Phase 1 outcome:**\n- All items pass → proceed to Phase 2\n- Any item fails → fix and re-run Phase 1 before continuing\n\n---\n\n## Phase 2 — Deep SOLID & Structural Audit\n\n### Gate 1: Single Responsibility (SRP)\n\n- **Pass:** Each function/class has one reason to change. Logic is encapsulated by domain. Functions are under ~20 lines.\n- **Fail:** \"God objects\" that mix UI, state, and I/O logic. Deep nesting (>2 levels). Side effects inside functions advertised as pure.\n- **Action on Fail:** Trigger decomposition — split logic into atomic, single-purpose units. Each extracted piece should be testable in isolation.\n\n### Gate 2: Open/Closed + Liskov Substitution (OCP/LSP)\n\n- **Pass:** New behavior is added by extending, not by modifying existing code. Subtypes are drop-in replacements for their parents without breaking contracts.\n- **Fail:** Large `if/else` or `switch` chains that must grow for each new type. Subclass methods throwing \"Not Implemented\".\n- **Action on Fail:** Refactor using the Strategy pattern or polymorphism. Close the current abstraction and extend via composition.\n\n### Gate 3: Interface Segregation + Dependency Inversion (ISP/DIP)\n\n- **Pass:** Interfaces are narrow — clients only depend on what they use. High-level modules depend on abstractions, not concrete implementations.\n- **Fail:** \"Fat\" interfaces where implementors are forced to stub unused methods. Hardcoded `new SpecificClass()` inside constructors. Tight coupling to third-party SDKs in business logic.\n- **Action on Fail:** Introduce dependency injection. Split fat interfaces into focused contracts. Wrap third-party dependencies behind an abstraction layer owned by your code.\n\n### Gate 4: Pragmatic Quality (KISS / DRY / YAGNI)\n\n- **Pass:** Zero duplicated logic. Simplest solution that satisfies the requirement. Intent-revealing names (`isExpired` vs `flag`). Related code is colocated.\n- **Fail:** Over-engineering for hypothetical future requirements. Magic numbers. Single-use abstractions with more complexity than the code they replaced. Abbreviated names (`ptr`, `tmp`, `idx`).\n- **Action on Fail:** Inline over-engineered abstractions. Replace magic numbers with named constants. Choose duplication over a premature abstraction when the abstraction adds net complexity.\n\n---\n\n## Phase 2 — Critical Patterns\n\n### Dependency Impact Scan\n\nBefore any signature change, identify every file that imports the target.  \nIf a signature changes, all dependent files **must** be updated in the same change. Never leave broken imports or type errors downstream.\n\n### Structural Integrity\n\n- Check for unreachable code and dead exports\n- Check for circular dependencies\n- Verify files are in the correct location per the project's structure (reference `AGENTS.md`)\n- Run the project's lint and type-check commands. Block completion if they fail.\n\n---\n\n## Reporting\n\nAfter completing both phases, report findings in this format:\n\n```\n## Code Review Results\n\n### ❌ Errors (must fix)\n- <specific issue, file:line, remediation>\n\n### ⚠️ Warnings (should fix)\n- <specific issue, file:line, remediation>\n\n### ✅ Passed\n- <what was verified>\n\n### Recommendation\nApprove / Request Changes — <one-line rationale>\n```\n\n- If errors exist: report them and ask \"Should I apply the fixes?\"\n- After applying fixes: re-run the relevant phase to verify resolution\n- If the codebase has no `AGENTS.md`, suggest running `/init-project` first for better stack-aware review\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}