demand-elegance

Demand Elegance Skill

Forces the agent to challenge its own non-trivial diff before presenting it: fewer moving parts, standard patterns over custom abstractions, boring over clever. Does NOT apply to typos, one-line fixes, or hotfixes — over-engineering trivial work is the failure mode this skill explicitly avoids.

When to Use

• A fix feels hacky, fragile, or "barely working".
• Multiple solutions exist and the tradeoffs aren't obvious.
• The diff is large and includes infrastructure the original task didn't ask for.
• Refactoring with simplification as the explicit goal.
• Self-review before presenting any non-trivial solution.
• NOT for: typos, one-line bugfixes, comment edits, formatting, production hotfires.

Prerequisites

• A working solution (or near-working) to challenge — don't run this on a blank canvas.
• The full diff visible (git diff via the powershell tool).
• Willingness to throw work away if a simpler approach exists.

How to Run

1. Confirm the change is non-trivial. If trivial, skip — see Pitfalls.
2. Run the Elegance Check (4 questions in Procedure §1).
3. Apply the Simplicity Ladder (Procedure §2) to choose between options.
4. Self-review the diff as if it were someone else's PR.
5. If hacky, restart with the elegant approach — don't deodorize the smell.

Quick Reference

Question	If answer is "yes" → action
Is there a more elegant way?	Try it before shipping.
Knowing what I know now, would I build it this way?	If no, refactor before presenting.
Can I reduce moving parts?	Cut them.
Would a senior engineer raise an eyebrow?	They would. Fix it.

Choose	Over
Fewer lines	More lines (all else equal)
Standard patterns	Custom abstractions
Fewer dependencies	More dependencies
Readable	Clever
Boring & correct	Exciting & fragile

Procedure

Step 1: The Elegance Check

For non-trivial work, before presenting the diff, ask in order: