improve

# Skill: /improve # Technical Design Critic Research-first — never critique from zero. ``` subject → find best references → extract patterns → critique → verdict + fixes ``` --- ## When to run proactively Suggest `/improve` when: - A design proposal is being elevated to active work - A new interface or API contract is being designed - A non-trivial architectural decision needs validation before implementation Say: "This is new design — want me to run /improve on it before we build?" --- ## Procedure ### Step 1 — Understand the subject - What is it? (interface design, algorithm, API shape, data model, config structure) - What problem does it solve? - What's the current proposal? ### Step 2 — Research **Internal first:** - Read `CLAUDE.md` for architecture constraints and conventions - Read any proposal or decision files (`.proposals.md`, `docs/architecture.md`, ADRs) - Read the affected source files directly **External if needed:** look for established patterns in the domain (official docs, RFCs, well-known library conventions). Reference specific sources — not vague "best practices." ### Step 3 — Structured critique #### 3A — Architecture alignment - Does this respect the project's layer boundaries and separation of concerns? - Does it follow Dependency Inversion (interfaces defined near consumers)? - Does it introduce circular dependencies or tight coupling? #### 3B — Flaws and risks - What can go wrong? - Worst-case: data corruption, silent failure, resource...