How do I install the Design Smell Review skill?

Run npx skillmds@latest add charlieviettq/design-smell-review in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Design Smell Review safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Design Smell Review?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Design Smell Review free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Design Smell Review?

charlieviettq (@charlieviettq) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Design Smell Review by charlieviettq

Name: Design Smell Review
Author: charlieviettq

Design Smell Review

Lightweight design smell review for modules and APIs—coupling, cohesion, naming, boundaries, and unnecessary complexity. Use before large refactors or when code feels hard to change. Complements gstack/review (diff-focused).

charlieviettq Updated Sep 17, 2026

File contents

Design smell review

Scope

Review structure and boundaries, not line-by-line style. Pair with PR diff review for changes; use this for module-level health.

Smell checklist

Smell	Signal	Direction
God module	Many unrelated responsibilities	Split by domain
Shotgun surgery	One change touches many files	Consolidate logic
Feature envy	Module A mostly uses B's data	Move behavior
Leaky abstraction	Impl details escape API	Narrow public surface
Config soup	Magic strings everywhere	Named constants / schema
Boolean flags	`if is_x` branches everywhere	Polymorphism or strategy

Workflow

Map entry points and dependencies (imports, public API).
List responsibilities per module; flag >1 unrelated core job.
Check testability — can core logic run without I/O?
Propose smallest structural improvement (not full rewrite).
Record decision in ADR if trade-off is significant.

Output format

## Summary
[1-2 sentences]

## Smells (priority order)
1. [Smell] — evidence — suggested fix (effort: S/M/L)

## Recommended next step
[One concrete change to try first]

Simplification (Chesterton's Fence)

Before deleting or collapsing code, ask why it exists:

Comment, test, or git history explaining constraint?
If unknown, prefer small experiment or question over bulk delete.
Remove duplication only when behavior is proven identical.
"Fewer lines" is not success if edge cases or observability regress.

Boundaries

Do not block small fixes on perfect architecture.
Prefer incremental extraction over big-bang rewrites.

---name: design-smell-reviewdescription: Lightweight design smell review for modules and APIs—coupling, cohesion, naming, boundaries, and unnecessary complexity. Use before large refactors or when code feels hard to change. Complements gstack/review (diff-focused).---# Design smell review## ScopeReview **structure and boundaries**, not line-by-line style. Pair with PR diff review for changes; use this for module-level health.## Smell checklist| Smell | Signal | Direction ||-------|--------|-----------|| God module | Many unrelated responsibilities | Split by domain || Shotgun surgery | One change touches many files | Consolidate logic || Feature envy | Module A mostly uses B's data | Move behavior || Leaky abstraction | Impl details escape API | Narrow public surface || Config soup | Magic strings everywhere | Named constants / schema || Boolean flags | `if is_x` branches everywhere | Polymorphism or strategy |## Workflow1. Map **entry points** and **dependencies** (imports, public API).2. List **responsibilities** per module; flag >1 unrelated core job.3. Check **testability** — can core logic run without I/O?4. Propose **smallest** structural improvement (not full rewrite).5. Record decision in ADR if trade-off is significant.## Output format```text## Summary[1-2 sentences]## Smells (priority order)1. [Smell] — evidence — suggested fix (effort: S/M/L)## Recommended next step[One concrete change to try first]```## Simplification (Chesterton's Fence)Before deleting or collapsing code, ask **why it exists**:- Comment, test, or git history explaining constraint?- If unknown, prefer small experiment or question over bulk delete.- Remove duplication only when behavior is proven identical.- "Fewer lines" is not success if edge cases or observability regress.## Boundaries- Do not block small fixes on perfect architecture.- Prefer incremental extraction over big-bang rewrites.

Frequently asked questions