patterns-and-refactoringlisted

# Patterns & Refactoring Three doors into this skill. Pick the one that matches the trigger. Every door ends at the same place: **Step 6 — verify what you actually built.** ```mermaid flowchart TD T{Trigger} -->|New code| A[Path A: force → YAGNI gate → decision] T -->|Existing code that hurts| B[Path B: smell → tests → smallest refactoring] T -->|Someone else's design or PR| C[Path C: behaviour first → gate in reverse → review] B -->|a pattern emerges| A A --> Z[Implement] --> V[Step 6: verify against the decision] B --> Z C --> V ``` --- ## Step 0 — Triage (every path) Over-applying this skill is itself an anti-pattern. Be honest about the level. | Level | Looks like | What you produce | |---|---|---| | **TRIVIAL** | One-line fix, copy change, config value, new field on an existing form, bug fix introducing no abstraction | **Nothing.** Skip this skill and write the code. | | **STANDARD** | New service, endpoint, component, job, integration; a refactor across a handful of files | 2–4 lines before coding: *force or smell → choice made → alternative rejected and why* | | **ARCHITECTURAL** | New module or bounded context, publishable package, cross-cutting refactor, a decision other code must live with | A **Pattern Decisions** section in the spec or plan, with a Mermaid diagram and the rejected alternatives | Between two levels? Pick the lower. A missing paragraph is cheap; ceremony on every task gets the whole process abandoned. **Reviewers