patterns-and-refactoringlisted

# Patterns & Refactoring Two doors into this skill. Pick the one that matches the trigger. ```mermaid flowchart TD T{What triggered this?} -->|New code to design| A[Path A: Force → Pattern] T -->|Existing code that hurts| B[Path B: Smell → Refactoring] A --> A1[Step 1: Name the force] A1 --> A2[Step 2: Route to a family] A2 --> A3[Step 3: Framework already solve it?] A3 --> A4[Step 4: YAGNI gate] A4 --> A5[Step 5: State the decision] B --> B1[Step 1: Name the smell] B1 --> B2[Step 2: Cover with tests] B2 --> B3[Step 3: Smallest refactoring first] B3 --> B4{Does a pattern<br/>emerge naturally?} B4 -->|Yes| A4 B4 -->|No| B5[Stop. Refactoring was enough.] A5 --> Z[Implement] B5 --> Z ``` --- ## Step 0 — Triage (both paths) 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