architecture-simplificationlisted

## Purpose Over time, codebases accumulate "just in case" abstractions. This skill guides the safe removal of unnecessary complexity: remove the noise around the core logic without changing the core logic itself. ## When to Use - An interface has only one implementation and no second one is planned - A wrapper, factory, or layer only passes arguments straight through - Two code paths do the same thing and should be consolidated ## Inputs - The suspect abstraction(s) and their call sites - A green test suite covering the affected area ## Workflow 1. **Identify the abstraction cost.** Does this interface have only one implementation? Does this wrapper class just pass arguments straight through? Measure before cutting: ```bash grep -rn "implements IUserRepository" src/ # count implementations grep -rn "IUserRepository" src/ | wc -l # count references ``` 2. **Run the tests first.** The affected area must be green before any removal — this is the behavioral baseline. 3. **Inline the logic.** Move the logic from the unnecessary abstraction directly into the caller. 4. **Delete the dead code.** Remove the interface, wrapper, or factory that is no longer needed. 5. **Test verification.** Re-run the same tests; the observable behavior of the system must not have changed. **Example:** if a `UserRepository` implements `IUserRepository` but there is only ever one database, inline `UserRepository` and delete `IUserRepository`. ## Output - The simplifie