separation-of-concerns
SoC — Separation of Concerns
Before Applying
If .agents/stack-context.md exists, read it first. Apply this principle using idiomatic patterns for the detected stack. For framework-specific details, use context7 MCP or web search — don't guess.
Principle
Each module, layer, or component in a system should address a single concern. A concern is a distinct aspect of functionality — data access, business rules, presentation, authentication, error handling, logging.
Why This Matters in Production
When concerns are entangled, changes become dangerous. Modifying the database schema shouldn't break the UI. Changing the logging format shouldn't affect business logic. Adding authentication shouldn't require rewriting every handler.
Separated concerns mean:
- Isolated failures. A bug in rendering doesn't corrupt data. A database timeout doesn't crash the UI.
- Independent testing. Business rules can be tested without a database. UI can be tested without a backend.
- Parallel development. Different team members can work on different layers without merge conflicts.
- Targeted debugging. When something breaks, the problem is localized to one layer, not spread across the whole stack.
More from jordancoin/codingskills
kiss
When writing or reviewing code to reduce complexity and improve readability. Use when the user says "simplify this," "too complex," "hard to read," "clean up," "what does this do," or "can't follow this code." For over-engineering concerns, see yagni. For structural clarity, see separation-of-concerns.
19yagni
When writing or reviewing code to prevent over-engineering and speculative features. Use when the user says "is this over-engineered," "do we need this," "should I add," "future-proof," or "just in case." For simplicity concerns, see kiss. For abstraction design, see solid.
16solid
When designing module boundaries, interfaces, or class hierarchies for maintainable architecture. Use when the user says "how should I structure this," "too coupled," "hard to test," "dependency injection," "single responsibility," or "interface design." For simpler structural concerns, see separation-of-concerns.
11dry
When writing or reviewing code to eliminate duplicated knowledge and business logic. Use when the user says "this is duplicated," "we have this in two places," "single source of truth," "DRY this up," or "shotgun surgery." For premature abstraction concerns, see yagni.
10law-of-demeter
When reviewing code for excessive coupling and deep object chains. Use when the user says "too coupled," "train wreck," "chained calls," "feature envy," "mocking is painful," or "this reaches too deep." For broader structural coupling, see solid.
9detect-stack
Analyze a codebase to detect its language, framework, conventions, and CI gates. Run this on first use in a project to generate stack context that all coding principle skills reference. Use when the user says "detect stack," "analyze this project," or "what's this codebase using.
9