convention-over-configuration
Convention over Configuration
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
Adopt sensible defaults and consistent patterns so that decisions are made once and applied everywhere. Reserve explicit configuration for the cases that genuinely need to differ from the default.
Why This Matters in Production
Every configuration option is a decision that someone must make, document, understand, and maintain. Misconfigured systems are a top cause of production incidents — wrong environment variables, typos in YAML, conflicting settings between services.
Convention-driven systems are predictable. A new team member can look at one module and know how every other module works. There's no "well, this service does it differently because someone configured it that way 18 months ago."
Configuration should be the exception, not the default. When everything is configurable, nothing is standardized.
Rules
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.
21yagni
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.
17dry
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.
12solid
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.
12law-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.
11detect-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.
10