workflowlisted

# Workflow ## Iron Law `COMPLEXITY IS THE ENEMY: KEEP SOFTWARE SIMPLE ENOUGH TO UNDERSTAND, CHANGE, AND PROVE.` ## When to Use - First, for almost every software engineering task: features, bug fixes, refactors, debugging, UI, tests, docs, config, CI, dependencies, and investigation that shapes later engineering work. ## When NOT to Use - A narrower skill is explicitly requested and fully covers the task. - The change is trivial, with no behavior, contract, data, or security risk. - Platform operations with no code, contract, or proof question. ## Rules 1. **Simple Made Easy is the lens.** Separate concerns, make state and effects explicit, and reduce what a maintainer must hold in their head. Familiar or quick to generate is not the same as simple. 2. **The human keeps owning the system.** Non-trivial work leaves the user with a clearer model of the change and the evidence. If you cannot explain the change clearly, stop and clarify. 3. **Consult owns the engineering bar; the host owns mechanics.** On conflict, clear the Consult bar inside the host's form. 4. **Smallest honest solution.** Implement only what was asked. Happy path first unless safety or data loss demands edge cases now. Compose over inherit. Add an abstraction only after real semantic duplication appears: duplicated intent gets one home, code that merely looks similar does not. 5. **Adopt before build.** Audit the ecosystem before writing code for a solved problem, and as