Design smell review
Skill charlieviettq/awesome-agent-skill/.cursor/skills/core-workflow/design-smell-review
Curated skill pack for LLM agents in engineer and science workflow (Cursor & Claude ready).
npx -y skills add charlieviettq/awesome-agent-skill --skill design-smell-reviewAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 22 stars22 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
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). Triggers: "design review", "code smell", "too complex", "refactor structure".
SKILL.md
2.0 KB, as published. Nobody here has run it
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.