home / skills / pplmx / husky-rs / senior-reviewer

senior-reviewer skill

/.agent/skills/senior-reviewer

This skill reviews Rust code for architectural integrity, clean design, and robust error handling to improve long-term maintainability.

npx playbooks add skill pplmx/husky-rs --skill senior-reviewer

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
1.6 KB
---
name: Senior Reviewer
description: Acts as a strict but helpful senior engineer, reviewing code for architectural soundness, maintainability, and SOLID principles.
---

# 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?

Overview

This skill acts as a strict but helpful senior engineer, reviewing Rust code for architectural soundness, maintainability, and alignment with SOLID principles. It focuses on long-term code health rather than only immediate correctness and is tuned for projects implementing husky-like git hooks in Rust. The guidance is practical and aims to reduce technical debt while keeping the codebase easy to evolve.

How this skill works

The skill inspects design choices, code cleanliness, performance, error handling, and testability. It highlights violations of SOLID, separation of concerns, and common Rust-specific pitfalls (unnecessary cloning, ownership issues, and async/IO patterns). Reviews include concrete suggestions to refactor, simplify, or add tests and examples of safer alternatives.

When to use it

  • When adding or modifying git hook logic (pre-commit, pre-push) implemented in Rust
  • Before merging changes that affect core infrastructure or developer tooling
  • When refactoring modules that interact with Git, IO, or external processes
  • When introducing complex async flows, concurrency, or global state
  • When preparing a release and ensuring maintainability and error handling

Best practices

  • Favor small, focused functions and structs; each type should have a single responsibility
  • Keep business logic decoupled from CLI or Git plumbing; expose testable interfaces
  • Avoid unnecessary clones; prefer borrowing, Cow, or smart pointers where appropriate
  • Propagate errors with context (thiserror, anyhow) and surface clear messages for hooks
  • Write unit tests for core logic and integration tests for hook behavior using temp repos

Example use cases

  • Review a new pre-commit hook that lints and formats staged files to ensure minimal IO and fast failure
  • Audit a refactor that extracts Git command wrappers to verify separation of concerns
  • Assess async code that runs concurrent checks to prevent race conditions and high memory use
  • Validate error reporting so CI and developers get actionable feedback from hooks
  • Recommend tests for simulating git states (untracked, staged, merge conflicts) in CI

FAQ

How strict is the review style?

Strict on long-term maintainability and correctness, but pragmatic: suggestions prioritize minimal disruption and measurable ROI.

Does the skill provide automated fixes?

It suggests concrete refactor steps and code snippets, but expects the developer to apply or run transformations to preserve intent.