Spark
Sign In
Skill

Review pull requests for decay risks and design smells

A PR review skill surfacing decay risks and design smells as Symptom-Source-Consequence-Remedy findings, book-grounded.

Get skill
hyhmrright
Maintainer?
80
Spark score
out of 100
Updated 23 days ago
Version 1.4.0
Add to Favorites

Why it matters

Conduct thorough PR code reviews that identify maintainability issues, design smells, and technical decay risks with structured findings that trace each symptom to its root cause, consequences, and remedies based on twelve classic software engineering books.

Outcomes

What it gets done

01

Scan code changes for decay risks across six ordered categories with symptom-to-source attribution

02

Run quick test checks to verify test coverage for production code changes

03

Apply the Iron Law filter to ensure every finding includes concrete evidence and actionable remedies

04

Generate structured reports with health scores and mode-specific formatting for PR reviews

Install

Add it to your toolbox

Run in your project directory:

curl -fsSL https://spark.entire.vc/get/ag-brooks-review | bash

Overview

Brooks-Lint - PR Review

This skill reviews PRs for decay risks and design smells, structuring findings as Symptom-Source-Consequence-Remedy and grounding each in one of twelve referenced engineering books. Use it when reviewing code, checking a PR, or given a diff to review. Skips the quick test check for docs-only or non-production changes.

What it does

This skill runs a PR code review that surfaces decay risks, design smells, and maintainability issues, structuring every finding as Symptom, Source, Consequence, and Remedy, and drawing on twelve classic software-engineering books referenced in shared framework files - a common rules file defining an Iron Law and Health Score, a source-coverage file attributing findings to specific books, a decay-risks file defining symptom taxonomy, and this skill's own PR review guide. If the user hasn't specified files or pasted code, it applies its own automatic scope detection to determine what to review before proceeding.

When to use - and when NOT to

Use it when asked to review code, check a PR, or when someone shares a diff or pastes code for review, expecting decay-risk and design-smell findings rather than a plain style check.

Inputs and outputs

Given code, a diff, or an auto-detected scope, it scans for each decay risk in a specified order, runs a quick test check that's skipped for docs-only or non-production changes, applies the Iron Law to every finding, and outputs a report following the shared report template, labeled PR Review as its report mode.

Integrations

Depends on companion reference files in a shared folder defining the review process, decay-risk order, and book attributions.

Who it's for

Developers and reviewers who want a structured, book-grounded PR review that names the specific engineering source behind each maintainability concern and prescribes a remedy, rather than a generic linting pass.

Source README

Brooks-Lint - PR Review

When to Use

Use this skill when you need pR code review that surfaces decay risks, design smells, and maintainability issues with concrete Symptom → Source → Consequence → Remedy findings, drawing on twelve classic engineering books. Triggers when: user asks to review code, check a PR, shares a diff or pastes code asking...

Setup

  1. Read ../_shared/common.md for the Iron Law, Project Config, Report Template, and Health Score rules
  2. Read ../_shared/source-coverage.md for book-level coverage, exceptions, and tradeoffs
  3. Read ../_shared/decay-risks.md for symptom definitions and source attributions
  4. Read pr-review-guide.md in this directory for the analysis process

Process

If the user has not specified files or pasted code: apply Auto Scope Detection
from ../_shared/common.md to determine the review scope before proceeding.

  1. Understand the review scope, then scan for each decay risk in the order specified (Steps 1-6 of the guide)
  2. Run the Quick Test Check (Step 7 of the guide) - skip for docs-only or non-production changes
  3. Apply the Iron Law to every finding
  4. Output using the Report Template from common.md

Mode line in report: PR Review

Limitations

  • Use this skill only when the task clearly matches its upstream source and local project context.
  • Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
  • Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.

FAQ

Common questions

Discussion

Questions & comments · 0

Sign In Sign in to leave a comment.