workflowlisted

# Workflow ## Iron Law `COMPLEXITY IS THE ENEMY: KEEP SOFTWARE SIMPLE ENOUGH TO UNDERSTAND, CHANGE, AND PROVE.` ## When to Use - Use first for features, fixes, refactors, debugging, and tests. - Also use for UI, docs, config, CI, dependencies, and investigations that guide later code changes. ## When NOT to Use - The user names a narrower skill that covers the whole task. - The change is trivial, with no behavior, contract, data, or security risk. - Platform operations with no code, contract, or proof question. ## Rules 1. **Keep unrelated parts separate.** Make state and effects explicit. Keep the number of things a maintainer must understand together small. A familiar or quick solution may still be hard to change. 2. **Explain the change to the user.** Show what changed, why, and what evidence supports it. If you cannot explain those points, clarify the work before proceeding. 3. **Consult sets the engineering bar, and the host owns the mechanics.** When they conflict, Consult's bar wins, and the host decides how to meet it. 4. **Build only what the user asked for.** Build the main behavior first unless safety or data loss requires an edge case now. Prefer composition to inheritance. Extract an abstraction only when code in more than one place serves the same purpose; similar syntax alone is not enough. 5. **Check existing tools before building one.** Look for a maintained library before writing code for a solved problem. Ask before addi