Software tradeoff analysis, decision frameworks, and common tradeoff patterns. Use when evaluating design alternatives, choosing between competing approaches, analyzing costs vs. benefits of technical decisions, or when a decision involves tension between two desirable properties. Covers duplication vs. coupling, flexibility vs. complexity, performance optimization, API design, dependency management, error handling strategies, and distributed system tradeoffs.
Analyzes technical decision tradeoffs like DRY vs coupling and flexibility vs complexity to guide architectural choices.
npx claudepluginhub smileynet/code-spiceThis skill inherits all available tools. When active, it can use any tool Claude has access to.
The cardinal rule: Context changes everything. A pattern that's optimal in one situation may be harmful in another. Validate assumptions with measurement, not intuition.
| Tradeoff | Option A | Option B | Choose A When | Choose B When |
|---|---|---|---|---|
| DRY vs. Coupling | Extract shared code | Duplicate code | Logic is truly identical and owned by one team | Services evolve independently or teams need autonomy |
| Flexibility vs. Complexity | Add extension points | Keep it simple | Multiple consumers with different needs | One consumer or needs are well-known |
| Optimize vs. Ship | Optimize hot path | Ship and measure | Profiling shows a bottleneck on a hot path | No measured performance problem exists |
| Abstract vs. Direct | Wrap dependencies | Use directly | Dependency may change or needs testing isolation | Dependency is stable and abstraction adds no value |
| Checked vs. Unchecked errors | Force caller to handle | Let errors propagate | Caller can meaningfully recover | Error is unrecoverable or caller can't act on it |
| Library vs. Custom | Use third-party library | Build your own | Problem is well-solved and library is maintained | Core differentiator or library is a poor fit |
| Monolith vs. Services | Single deployable | Distributed services | Small team, early product, simple scaling needs | Independent team scaling, polyglot requirements |
| Consistency vs. Availability | Strong consistency | Eventual consistency | Financial transactions, inventory counts | Social feeds, analytics, caching layers |
| You're tempted to... | The real tradeoff is... | Ask yourself... |
|---|---|---|
| Remove duplicated code | Coupling vs. independence | Will these paths diverge? Do different teams own them? |
| Add an extension point | Flexibility vs. complexity | Do you have >1 consumer? Is the use case concrete? |
| Optimize a code path | Performance vs. readability | Is this on the hot path? Do you have profiling data? |
| Add a third-party library | Development speed vs. long-term maintenance | Is this a core differentiator? Is the library well-maintained? |
| Extract a microservice | Team autonomy vs. operational complexity | Is the monolith actually blocking you? |
| Use strong consistency | Correctness vs. availability and latency | What's the business cost of stale or incorrect data? |
| Wrap a dependency | Future flexibility vs. current complexity | How likely is replacement? How deep is the integration? |
| Symptom | Likely Wrong Choice | Course Correction |
|---|---|---|
| Changing one service breaks another | Over-extracted shared code (too DRY) | Duplicate and decouple |
| Simple features take weeks | Over-engineered flexibility | Remove unused extension points |
| Performance issues in production | Didn't optimize the hot path | Profile, identify bottleneck, targeted fix |
| Library upgrade breaks everything | Too-deep dependency without wrapping | Extract interface, wrap the dependency |
| Teams blocked waiting on each other | Monolith coordination overhead | Extract contested components into services |
| Debugging takes days | Too many microservices for the team size | Consolidate related services |
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.