What languages does claude-oop-excellence support?

Any language the model can read. Detection is principle-based — universal design principles (SOLID, Law of Demeter, DRY) plus language-neutral signs — not a per-language matrix. It works across TypeScript/JavaScript, Python, Java, Go, Rust, C#, and more, and verifies fixes using whatever test/typecheck/lint commands your project already defines.

Will the plugin bloat my context window?

The side-effecting action skills (/fix-risks, /implement-patterns) are disable-model-invocation, so they cost no standing context. The worker subagents only cost tokens when an audit or action run spawns them, and they fan out one per in-scope entity in parallel.

How are fixes verified?

/fix-risks and /implement-patterns run your project's own detected test, typecheck, and lint commands — e.g. npm test, pytest, make test, go test ./... — and verify each change before moving on. There is no single-language tooling assumption, and every change is applied through a safe, reviewable sequence.

What is the glossary?

skills/glossary/glossary.json is the single source of truth — 102 entities: 45 issues (code smells, antipatterns, vulnerabilities, supply-chain risks) and 57 design patterns. Every detection sign, principle, severity, and cross-reference lives there, so adding coverage means appending to the glossary, not writing a new agent.

How do I uninstall claude-oop-excellence?

Run /plugin disable claude-oop-excellence to turn it off, or /plugin uninstall claude-oop-excellence to remove it entirely. The plugin keeps no project-side state of its own — your code and tests are the only artifacts it touches, and only through gated, user-invoked actions.

claude-oop-excellence — audit, fix & verify OO design in any language

Q: Does /audit change my code?

No. /audit is read-only end to end — it never modifies code. It produces one unified report ending with a Recommended Actions section that prints the exact /fix-risks and /implement-patterns commands to run next. Nothing changes until you invoke one of those yourself.

How it works

One front door, two tracks, one report

/audit is the single read-only entry point. It resolves a selector against the glossary and fans workers out per in-scope entity in parallel — the RISK track for issues and the PATTERN track for patterns — merging everything into one unified report that ends with a gated handoff to two user-invoked action commands.

flowchart TD
    A[/"audit — read-only front door
resolves selector against glossary.json"/]
    subgraph L2["L2 · two parallel tracks"]
      R["RISK track
antipatterns · smells · vulns · supply-chain"]
      P["PATTERN track"]
      PS["scan · patterns already present"]
      PF["fit · most-suitable suggestions"]
      P --> PS
      P --> PF
    end
    subgraph L3["L3 · workers, one per in-scope entity, parallel"]
      WD["entity-detector"]
      WS["pattern-scanner"]
      WF["pattern-suggester"]
    end
    A --> R
    A --> P
    R --> WD
    PS --> WS
    PF --> WF
    WD --> U(["ONE unified report"])
    WS --> U
    WF --> U
    U --> RA["Recommended Actions
prints exact gated commands"]
    RA -. gated, user-invoked .-> ACT[/"fix-risks · implement-patterns"/]

    classDef accent fill:#3a2a20,stroke:#e0855f,color:#f3e7df;
    class U,ACT accent;

Flowchart: the read-only /audit front door resolves a selector against glossary.json, then fans out into two parallel tracks. The RISK track detects antipatterns, code smells, vulnerabilities and supply-chain risks; the PATTERN track has two aspects — scan, for design patterns already present, and fit, for the most-suitable pattern suggestions. Each track spawns workers — entity-detector, pattern-scanner and pattern-suggester — one per in-scope entity in parallel. All of them merge into one unified report, which ends with a Recommended Actions section that prints the exact gated commands; those hand off, only when you invoke them, to /fix-risks and /implement-patterns.

/audit stays read-only end to end — the action layer is separate, gated, and user-invoked. A typical analyze → act loop, with oop as the spine that is fixed before other families:

/audit flags a god-class hotspot and, on the PATTERN track, suggests Extract Class plus a facade to tame the call sites.
The report's Recommended Actions print the exact next command — /fix-risks god-class component src/ — scoped to what it found.
You run it; entity-fixer refactors entity by entity and verifies every change against your project's own detected test, typecheck, and lint commands before moving on.

The RISK track

Finds what's wrong: code smells, antipatterns, vulnerabilities, and supply-chain risks — graded by severity and correlated into hotspots in the unified report.

/audit risks
code smells
antipatterns
vulnerabilities
supply-chain

The PATTERN track

Two aspects: scan reports the design patterns already present, and fit suggests the most-suitable patterns to adopt — Strategy, Facade, Decorator and the rest of the GoF catalog.

/audit patterns
pattern-scan
pattern-fit
57 design patterns

What it finds

102 entities, one parallel pass

Detection is driven by a canonical glossary — 45 issues and 57 design patterns. A full /audit fans out one worker per in-scope entity, so a complete baseline is a single wall-clock pass.

OOP smells

God Class, Anemic Domain Model, Feature Envy, Inappropriate Intimacy, Refused Bequest — the structural smells that erode encapsulation and cohesion. oop is the spine, fixed first.

Antipatterns

Spaghetti code, circular dependencies, the Yo-Yo problem, and other design-level antipatterns caught by universal principles — SOLID, Law of Demeter, DRY — not a per-language matrix.

Vulnerabilities

The security family: injection, unsafe deserialization, secrets in source, and the OWASP-style risks that surface from language-neutral signs in any codebase.

Supply-chain risks

Dependency and build-surface risks — unpinned or risky dependencies and the supply-chain weaknesses that don't show up in the application logic itself.

Pattern scan

The PATTERN track's scan aspect reports the design patterns already present — Strategy, Observer, Factory, Adapter — so you can see the design you actually have.

Pattern fit

The fit aspect suggests the most-suitable patterns to adopt where they'd help — from creational and structural to behavioral, architectural, and DDD.

What makes it excellence

glossary-driven

glossary.json is the single source of truth — 102 entities with detection signs, principles, severity, and cross-references. Add coverage by appending, not by writing agents.

principle-based

Detection lives as universal design principles plus language-neutral signs — so it works in any language the model can read, with no per-language matrix to maintain.

parallel fan-out

The orchestrator selects in-scope entities and fans one generic worker out per entity in parallel, batched by family — a full baseline in one pass.

one unified report

RISK and PATTERN findings merge into a single report with scoring, hotspots, and correlations — and a Recommended Actions handoff with real selectors and paths.

test-verified fixes

/fix-risks and /implement-patterns run your project's own detected test/typecheck/lint command and verify each change before moving on.

gated & read-only

/audit never modifies code. The action commands are disable-model-invocation — Claude never refactors on its own; you invoke a fix by name.

Commands

One selector, every layer

/audit resolves a selector against the glossary and zooms across three layers — track → aspect → family / category / entity. Each selector takes an optional scope suffix: full (default), changed (vs the base branch), or component <path> (a single subtree).

Selector	Resolves to
`/audit [scope]`	L1 (full) — both tracks in parallel, one unified report.
`/audit risks`	RISK track only (alias: `/audit risk-scan`).
`/audit patterns`	PATTERN track — both aspects (scan + fit).
`/audit pattern-scan`	Design patterns already present.
`/audit pattern-fit`	Most-suitable pattern suggestions.
`/audit <category>`	One category — e.g. `vulnerability`, `design-pattern`.
`/audit <family>`	One family — e.g. `oop`, `security`, `behavioral`.
`/audit <entity-id>`	A single entity or pattern — e.g. `god-class`, `strategy`.

Take action — gated, user-invoked only

Command	What it does
`/fix-risks <selector> [scope]`	Fixes risk findings entity by entity via `entity-fixer` (OOP first), verified with the project's own detected commands.
`/implement-patterns <selector> [scope]`	Adopts suggested patterns via `pattern-implementer`, applied through a safe parallel-change sequence + tests.
`glossary`	Resolve any entity by id, list a family or category, or follow cross-references. Read-only.
`onboarding`	In-session orientation — the mental model and analyze → act flow. Read-only.

Common runs: /audit, /audit changed, /audit risks, /audit pattern-fit, /audit god-class component src/.

Use cases

When to reach for it

Inherited a messy codebase

/audit gives one read-only, unified picture — smells, antipatterns, vulnerabilities, and the patterns already in play — before you touch a line.

Reviewing a pull request

/audit changed scopes the whole run to just the files changed vs the base branch — a design-quality gate for the diff under review.

A God Class hotspot

Once the report flags it, /fix-risks god-class refactors it entity by entity and verifies each step against your own tests.

Adopt the right patterns

/audit pattern-fit names the most-suitable patterns; then /implement-patterns adopts them through a safe parallel-change sequence.

Security & supply-chain sweep

/audit security narrows the RISK track to vulnerabilities and supply-chain risks — language-neutral signs, any stack.

Focus on one subtree

/audit <selector> component src/ scopes any run to a single directory — handy for a service, a module, or a package you own.

CI / pre-merge gate

/audit changed is read-only end to end — run it on every PR to catch design regressions before they ship.

Onboarding to the plugin

/onboarding gives a read-only, in-session tour of the mental model and the analyze → act flow — no docs to read first.

Get started

Install in two commands

# In a Claude Code session — add the marketplace, then install
/plugin marketplace add odere-pro/claude-oop-excellence
/plugin install claude-oop-excellence@odere-pro

# Run your first audit — read-only, never changes code
/audit                 # whole project: both tracks, one unified report
/audit changed         # only files changed vs the base branch
/audit god-class       # a single entity

Read-only by default. /audit never modifies code — it ends with a Recommended Actions section that prints the exact /fix-risks and /implement-patterns commands to run next. Those actions are disable-model-invocation (user-invoked only) and verify every change against your project's own tests before moving on.

# Or load a local checkout for one session (development)
claude --plugin-dir /path/to/claude-oop-excellence
# then, in-session:
/reload-plugins

# Verify the install
/plugin        # confirms claude-oop-excellence is enabled
/skills        # /audit, glossary, onboarding registered
/agents        # the oop-orchestrator + workers registered
/context       # confirms ~zero idle context cost

New here?

# A read-only, in-session guided tour before you dive in
/onboarding

Questions

Frequently asked questions

Does /audit change my code?: No. /audit is read-only end to end — it never modifies code. It produces one unified report ending with a Recommended Actions section that prints the exact /fix-risks and /implement-patterns commands to run next. Nothing changes until you invoke one of those yourself.
What languages does it support?: Any language the model can read. Detection is principle-based — universal design principles (SOLID, Law of Demeter, DRY) plus language-neutral signs — not a per-language matrix. It works across TypeScript/JavaScript, Python, Java, Go, Rust, C# and more, and verifies fixes using whatever test/typecheck/lint commands your project already defines.
Will the plugin bloat my context window?: The side-effecting action skills (/fix-risks, /implement-patterns) are disable-model-invocation, so they cost no standing context. The worker subagents only cost tokens when an audit or action run spawns them, and they fan out one per in-scope entity in parallel.
How are fixes verified?: /fix-risks and /implement-patterns run your project's own detected test, typecheck, and lint commands — e.g. npm test, pytest, make test, go test ./... — and verify each change before moving on. There is no single-language tooling assumption.
What is the glossary?: skills/glossary/glossary.json is the single source of truth — 102 entities: 45 issues (code smells, antipatterns, vulnerabilities, supply-chain risks) and 57 design patterns. Every detection sign, principle, severity, and cross-reference lives there, so adding coverage means appending to the glossary, not writing a new agent.
How do I uninstall it?: /plugin disable claude-oop-excellence turns it off; /plugin uninstall claude-oop-excellence removes it entirely. The plugin keeps no project-side state of its own — your code and tests are the only artifacts it touches, and only through gated, user-invoked actions.

Enforce good object-oriented design — in any language.