Best for
- Use when reviewing code design, planning feature architecture, asking "is this the right design?
Source profileQuality 74/100
jackchuka/skills/dev-software-design/SKILL.md
dev-software-design
Opinionated guide to software design principles and architectural patterns. Use when reviewing code design, planning feature architecture, asking "is this the right design?", "how should I structure this?", or requesting design philosophy guidance. Triggers on questions about SOLID, DRY, KISS, YAGNI, Clean Architecture, DDD, hexagonal architecture, composition vs inheritance, coupling, cohesion, or any software design trade-off discussion.
- Source repository stars
- 15
- Declared platforms
- 0
- Static risk flags
- 0
- Last source update
- 2026-07-28
- Source checked
- 2026-07-28
Decision brief
What it does—and where it fits
Opinionated guidance on classic design principles and architectural patterns, with concrete code examples and trade-off analysis.
Not for
- Tasks that require unconfirmed production actions or broad system permissions.
- Environments where the pinned source and install steps cannot be inspected.
Compatibility matrix
Platform support, with evidence labels
| Platform | Status | Evidence | What to check |
|---|---|---|---|
| Codex | Not declared | No explicit evidence | Portability before use |
| Claude Code | Not declared | No explicit evidence | Portability before use |
| Cursor | Not declared | No explicit evidence | Portability before use |
| Gemini CLI | Not declared | No explicit evidence | Portability before use |
Installation
Inspect first. Install second.
The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.
Source-detected install commandSource
npx skills add https://github.com/jackchuka/skills --skill "dev-software-design"Safe inspection promptEditorial
Inspect the Agent Skill "dev-software-design" from https://github.com/jackchuka/skills/blob/7b0b33f68b8f11522e43622e5cb3bacd802999d2/dev-software-design/SKILL.md at commit 7b0b33f68b8f11522e43622e5cb3bacd802999d2. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.
Workflow
What the source asks the agent to do
- 01
When Applying Design Guidance
1. Diagnose first — Identify the specific design tension (coupling, cohesion, complexity, rigidity) 2. Name the principle — State which principle applies and why 3. Show the trade-off — Every principle has a cost; state it explicitly 4. Demonstrate with code — Before/after examp…
Diagnose first — Identify the specific design tension (coupling, cohesion, complexity, rigidity)Name the principle — State which principle applies and whyShow the trade-off — Every principle has a cost; state it explicitly - 02
Core Stance: Pragmatism Over Dogma
Principles are heuristics, not laws. Apply them when they reduce complexity; skip them when they add it.
Principles are heuristics, not laws. Apply them when they reduce complexity; skip them when they add it.Prefer boring, obvious code over clever, abstract code.The best design is the simplest one that handles current requirements. Speculative generality is a code smell. - 03
Classic Principles Quick Reference
For detailed explanations, examples, and anti-patterns for each principle, see references/principles.md.
For detailed explanations, examples, and anti-patterns for each principle, see references/principles.md. - 04
Architectural Patterns Quick Reference
For detailed guidance on each pattern including structure, trade-offs, and code examples, see references/architecture.md.
For detailed guidance on each pattern including structure, trade-offs, and code examples, see references/architecture.md. - 05
Decision Framework
When advising on design, follow this priority order:
Does it work correctly? — Correctness over eleganceCan someone else read it? — Clarity over clevernessCan it be tested? — Testability over convenience
Permission review
Static risk signals and limitations
No configured static risk pattern was detected
This is not proof of safety. Runtime behavior, indirect dependencies, and hidden external systems are outside the static scan.
Evidence record
Why each signal appears
EvidenceSourceComputedTestedEditorial
| Signal | Value | Evidence type | Meaning |
|---|---|---|---|
| Quality score | 74/100 | Computed | Documentation, specificity, maintenance, and trust rules |
| Repository stars | 15 | Source | Repository attention, not individual Skill quality |
| Compatibility | 0 platforms | Source | Declared in the catalog source record |
| Usage guide | automated source guide | Editorial | Generated or reviewed according to the visible evidence level |
Pinned source
Provenance and original SKILL.md
- Repository
- jackchuka/skills
- Skill path
- dev-software-design/SKILL.md
- Commit
- 7b0b33f68b8f11522e43622e5cb3bacd802999d2
- License
- MIT
- Collected
- 2026-07-28
- Default branch
- main
View the original SKILL.md
Software Design Philosophies
Opinionated guidance on classic design principles and architectural patterns, with concrete code examples and trade-off analysis.
When Applying Design Guidance
- Diagnose first — Identify the specific design tension (coupling, cohesion, complexity, rigidity)
- Name the principle — State which principle applies and why
- Show the trade-off — Every principle has a cost; state it explicitly
- Demonstrate with code — Before/after examples grounded in the user's codebase context
Core Stance: Pragmatism Over Dogma
- Principles are heuristics, not laws. Apply them when they reduce complexity; skip them when they add it.
- Prefer boring, obvious code over clever, abstract code.
- The best design is the simplest one that handles current requirements. Speculative generality is a code smell.
- Three concrete duplications are better than one wrong abstraction (Rule of Three).
Classic Principles Quick Reference
| Principle | One-liner | Apply when... | Skip when... |
|---|---|---|---|
| SRP | One reason to change | A module mixes unrelated concerns | Splitting creates indirection with no clarity gain |
| OCP | Extend, don't modify | You need plugin-style variation | You're still discovering requirements |
| LSP | Subtypes must be substitutable | Building type hierarchies | Using composition instead |
| ISP | Small, focused interfaces | Clients depend on methods they don't use | Interface has natural cohesion |
| DIP | Depend on abstractions | You need testability or swappable implementations | Only one implementation exists or will ever exist |
| DRY | Single source of truth | Identical logic with identical reasons to change | Similar-looking code with different reasons to change |
| KISS | Simplest solution that works | Always the default | Never skip this |
| YAGNI | Don't build it until you need it | Tempted to add "just in case" features | Building foundational APIs with known extension points |
For detailed explanations, examples, and anti-patterns for each principle, see references/principles.md.
Architectural Patterns Quick Reference
| Pattern | Best for | Avoid when |
|---|---|---|
| Clean/Hexagonal | Long-lived systems with complex domains | Simple CRUD apps, prototypes |
| DDD | Complex business logic with domain experts | Technical/infrastructure-heavy systems |
| Event-Driven | Decoupled workflows, audit trails | Simple request/response flows |
| CQRS | Read/write asymmetry, complex queries | Uniform read/write patterns |
| Monolith-first | New projects, small teams | Already proven need for independent deployment |
| Microservices | Independent team deployment at scale | Small team, shared database, tight coupling |
For detailed guidance on each pattern including structure, trade-offs, and code examples, see references/architecture.md.
Decision Framework
When advising on design, follow this priority order:
- Does it work correctly? — Correctness over elegance
- Can someone else read it? — Clarity over cleverness
- Can it be tested? — Testability over convenience
- Can it change safely? — Isolation of change over DRY
- Does it perform adequately? — Performance only when measured
Common Design Smells and Remedies
| Smell | Likely violation | Remedy |
|---|---|---|
| God class / function | SRP | Extract cohesive responsibilities |
| Shotgun surgery (one change touches many files) | Low cohesion | Colocate related logic |
| Feature envy (method uses another object's data more than its own) | Misplaced responsibility | Move method to the data owner |
| Primitive obsession | Missing domain concept | Introduce a value type |
| Deep inheritance trees | Favoring inheritance over composition | Flatten with composition/interfaces |
| Boolean parameters | SRP, OCP | Split into separate functions |
| Speculative generality | YAGNI | Delete unused abstractions |
Offering Guidance
When reviewing or advising:
- Reference the specific principle by name with a one-sentence rationale
- Show a minimal before/after code example in the user's language
- State the trade-off honestly ("this adds an interface but isolates the database dependency")
- If multiple principles conflict, state the tension and recommend based on context
- Load references/principles.md for deep-dive principle discussions
- Load references/architecture.md for architectural pattern guidance
Alternatives
Compare before choosing
Computed 10042,015
coreyhaines31/marketingskills
ab-testing
When the user wants to plan, design, or implement an A/B test or experiment, or build a growth experimentation program. Also use when the user mentions "A/B test," "split test," "experiment," "test this change," "variant copy," "multivariate test," "hypothesis," "should I test this," "which version is better," "test two versions," "statistical significance," "how long should I run this test," "growth experiments," "experiment velocity," "experiment backlog," "ICE score," "experimentation program
Computed 1007
event4u-app/agent-config
design-intelligence
Grounded design brief from the adopted corpus — style, WCAG-checked color tokens, typography, layout pattern, anti-patterns. Use on ui-design-brief or any which-style/palette/font/chart decision.
Computed 1007
event4u-app/agent-config
existing-ui-audit
Use BEFORE writing or editing any non-trivial UI — inventories components, design tokens, shadcn primitives, and reusable patterns into state.ui_audit. Hard gate for the ui directive set.
Computed 9982,073
nexu-io/open-design
emil-design-eng
This skill encodes Emil Kowalski's philosophy on UI polish, component design, animation decisions, and the invisible details that make software feel great.