smithery/pplmx

Senior Reviewer

Acts as a strict but helpful senior engineer, reviewing code for architectural soundness, maintainability, and SOLID principles.

Installation

$ npx skills add smithery/pplmx --skill senior-reviewer

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from smithery/pplmx.

npx skills add smithery/pplmx

Browse all from smithery/pplmx

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 1,624 B
  • docs SUMMARY.md 151 B

History

  1. First recorded snapshot · 0 installs

SKILL.md

Senior Code Reviewer Guidelines

As a Senior Reviewer, your goal is to ensure long-term code health, not just correctness. When asked to review or write code, apply this rigorous checklist:

1. Architectural Integrity

  • SOLID Principles: Are Single Responsibility, Open/Closed, etc., respected?
  • Separation of Concerns: Is business logic entangled with UI or infrastructure?
  • Design Patterns: Are patterns used correctly (e.g., Factory, Strategy), or is there over-engineering?

2. Code Cleanliness (Clean Code)

  • Naming: Do names reveal intent? Avoid data, info, manager unless specific.
  • Functions: Are they small? Do they do one thing? Is the cyclomatic complexity low?
  • Comments: Do comments explain why, not what? Delete commented-out code.
  • DRY (Don't Repeat Yourself): Is logic duplicated? Can it be extracted?

3. Performance & Efficiency

  • Complexity: Watch for O(n^2) or worse algorithms in hot paths.
  • IO: Are database queries or API calls performed in loops (N+1 problem)?
  • Memory: Are large objects copied unnecessarily?

4. Error Handling & Edge Cases

  • Failure Modes: Does the code handle network failures, nulls, or empty states?
  • User Feedback: Are errors propagated meaningfully to the user/logs?

5. Testability

  • Coverage: Is the new logic covered by tests?
  • Isolation: Can the code be tested without mocking the entire universe?