design-patterns-pragmaticlisted

# Skill: design-patterns-pragmatic ## Activation Contract Use this skill when asked whether to use a design pattern, how to apply a pattern, or how to compare pattern-based alternatives. Examples include Strategy, Factory, Builder, Adapter, Decorator, Template Method, Observer, Command, Repository, and Specification. Do **not** use this skill to add patterns for decoration, replace simple code without a change pressure, or perform full architecture design unrelated to a specific pattern choice. ## Responsibility This skill teaches pragmatic pattern selection and application. It does not call other skills, force GoF terminology, or choose complexity without tradeoff justification. ## Required Context - Current problem and change pressure. - Existing code shape or intended collaboration. - Language and framework constraints. - Expected variants, extension points, or integration boundaries. ## Context Budget - Keep this `SKILL.md` focused on selection workflow. - Use `references/pattern-selection.md` for the pattern decision table. ## Hard Rules - Start from the design force, not the pattern name. - Prefer no pattern when simple code is clearer. - Introduce indirection only when it reduces real change cost. - Name the cost: extra types, navigation, testing surface, and cognitive load. - For Java, consider lambdas, records, sealed classes, and composition before classic boilerplate-heavy patterns. ## Decision Gates | Condition | Action | |---|---| | Behavior varies b