review-oo-design

Review object-oriented designs against Arthur Riel's 61 design heuristics and naming guidelines.

5|Updated Sep 9, 2017
One-click install
npx skills add https://github.com/hpcsc/dotfiles --skill review-oo-design-hpcsc
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: review-oo-design
Source: https://github.com/hpcsc/dotfiles/tree/main/link/common/claude/.claude/skills/review-oo-design
Command: npx skills add https://github.com/hpcsc/dotfiles --skill review-oo-design-hpcsc

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? It turns subjective opinions about class and module design into evidence-backed findings by grading abstractions against Arthur Riel's 61 design heuristics, cohesion matrices, and a domain vocabulary diff. ## Core Features & Use Cases - Abstraction review: Inventories types, fields, methods, and relationships (containment, association, inheritance), then builds method×field cohesion matrices and function×parameter matrices to detect god classes, anemic types, and missing abstractions. - Naming and vocabulary audit: Diffs the code's glossary against the domain's own words to find one-word-two-concepts collisions, split vocabularies, and domain concepts with no home in the code. - Design mode: Proposes abstractions, responsibilities, and relationships for new modules, with a self-review pass and rejected alternatives. - Use Case: Ask it to review a Go package where a Manager type keeps growing; it measures cohesion, cites file:line evidence, names the concrete cost of each finding, and proposes an incremental redesign with blast radius and effort estimates. ## Quick Start Ask the AI to review the object-oriented design of the package at ./internal/orders using the review-oo-design skill.

Frequently Asked Questions about review-oo-design

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I review a class design for god objects and anemic types?▼

Run the review on the target package; it inventories types, builds a method×field cohesion matrix per type, and classifies every relationship as containment, association, or inheritance. Findings cite file:line evidence and must name a concrete cost before being reported.

How to decide between inheritance and composition in a code review?▼

The skill applies Riel's decision table: shared data only means containment, shared data and behaviour means a common base, and interface only means a base only if used polymorphically. It also runs the substitution test, where a subtype may only weaken preconditions and strengthen postconditions.

Does this design review work for Go or Elixir code?▼

Yes, it loads a per-language paradigm mapping before reviewing, since Riel wrote for C++ and Smalltalk. In Go, embedding is treated as containment and inheritance heuristics are void; in Elixir, class-based heuristics are adapted or excluded entirely.

Can it detect missing abstractions in a module of free functions?▼

Yes, the function×parameter matrix finds abstractions that do not exist yet: a block of functions sharing the same parameters is a type, and a column marked in nearly every row is a constructor argument. It also guards against the opposite failure of over-objectification.

What are the limitations of heuristic-based design review?▼

Triggered heuristics are prompts to look, never findings on their own, and a violation with no concrete cost is not reported. It does not cover correctness, security, performance, test quality, or formatting style, which belong to other review passes.