clean-architecturelisted

# Clean Architecture (any stack, adapts to the project) Implement features with Clean Architecture — dependency direction `frameworks & drivers → adapters → use cases → domain` — in whatever stack and idiom the project already uses: mobile app, web frontend, backend service, or desktop. The skill imposes **boundaries**, never tools: packages, naming, and state management are detected from the project, not chosen by the skill. This file is a **router**. You **must** open and follow the reference each step links — never work from memory of it. **Not this skill:** pure visual tweaks with no data or business change; finding the root cause of a defect, or deciding where an already-understood fix belongs; documentation-only work; comparing an implementation against a design file. ## The two iron rules 1. **Dependency direction.** Source dependencies point inward only. The delivery layer — a screen, widget, state holder, controller, or route handler — never reaches past use cases into databases, storage, HTTP clients, or platform APIs; a use case never touches delivery, navigation or routing, or vendor types; the domain imports nothing from outside itself. 2. **Convention precedence.** The project's existing convention beats this skill's defaults — naming, state management, DI, folders, error idiom. The boundaries in rule 1 beat everything, including existing code that violates them: violations are **reported, never copied, never silently rewritten**. When the