Project-level scope analysis for evaluating whether a project has exceeded its useful boundaries, needs splitting, or is experiencing scope creep. Use when evaluating project structure, considering whether to split a project, assessing feature belonging, or when projects feel too large or unfocused during brainstorm, scope, or architecture review. Covers cohesion test at project level, feature belonging assessment, scope creep detection, split-vs-keep decision framework, and safe splitting patterns.
Analyzes code projects to detect scope creep and determine when to split them versus improving internal organization.
npx claudepluginhub smileynet/code-spiceThis skill inherits all available tools. When active, it can use any tool Claude has access to.
Run this during architecture review or when scope feels unclear:
utils/, helpers/, or common/ smaller than any domain folder?If 3+ items fail: The project may have outgrown its boundaries. Run the split-vs-keep framework below.
| Question | Belongs | Doesn't Belong |
|---|---|---|
| Who uses it? | Same users as existing features | Different user group entirely |
| When does it change? | Same triggers as the core product | Independent triggers, different release cycle |
| How is it deployed? | Same deployment artifact and cadence | Needs separate scaling, uptime, or infrastructure |
| What data does it use? | Same domain entities | Different data domain with minimal overlap |
| Who maintains it? | Same team with shared context | Different team or skill set required |
If 3+ answers land in "Doesn't Belong": The feature is a candidate for extraction.
Describe your project's purpose in a single sentence. If the sentence contains "and" connecting unrelated capabilities, that conjunction is a potential split point. Related capabilities often belong together — the question is whether they share users, data, and deployment needs.
Scope creep follows a predictable progression:
Each phase transition feels small. Monitor for transitions and make conscious decisions about whether to accept them.
| Metric | Healthy | Warning | Critical |
|---|---|---|---|
| Utils/helpers ratio | <10% of codebase | 10-25% | >25% — domain boundaries unclear |
| Cross-feature dependencies | Rare, well-defined interfaces | Growing, some circular | Pervasive — features can't change independently |
| New developer productivity | Productive in days | Productive in weeks | Months before meaningful contributions |
| Unrelated issue coupling | Issues affect one feature | Issues span 2-3 features | Most issues touch 4+ features |
Are different teams blocked by shared codebase?
├── Yes → Split along team boundaries (Conway's Law)
└── No
Does the project need different scaling for different features?
├── Yes → Extract the differently-scaled component
└── No
Are cascading failures affecting unrelated features?
├── Yes → Split to isolate failure domains
└── No
Is onboarding time growing beyond acceptable?
├── Yes → Consider splitting, but check if better
│ internal organization helps first
└── No → Don't split. Improve internal boundaries instead.
| Your situation | Recommendation |
|---|---|
| One team, features cohesive, shared data | Don't split — improve internal organization |
| One team, features diverging, shared deployment | Internal boundaries — modules or packages, not projects |
| Multiple teams, shared codebase friction | Split along team boundaries — Conway's Law |
| Independent scaling needs | Extract the bottleneck — Strangler Fig pattern |
| Cascading failures across features | Isolate failure domains — split for resilience |
| "It's getting big" but no measured pain | Don't split — size alone is not a reason |
| Indicator | Natural Growth | Scope Creep |
|---|---|---|
| User request | From primary audience | From a different user group |
| Domain fit | Same business domain | Adjacent or unrelated domain |
| Data model | Uses existing entities | Requires new, unrelated entities |
| Team expertise | Existing team can build it | Requires different skill set |
| Deployment | Ships with existing cadence | Needs different infrastructure |
Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.
Applies Anthropic's official brand colors and typography to any sort of artifact that may benefit from having Anthropic's look-and-feel. Use it when brand colors or style guidelines, visual formatting, or company design standards apply.
Create beautiful visual art in .png and .pdf documents using design philosophy. You should use this skill when the user asks to create a poster, piece of art, design, or other static piece. Create original visual designs, never copying existing artists' work to avoid copyright violations.