Engineering Cost Review

• Don't implement requirements verbatim, with no critique.
• If the simplest approach satisfies the requirement, recommend it.
• If the simplest approach serves the goal but conflicts with the requirement, propose changing the requirement.
• If the requirement's scope and cost are so large they crowd out the purpose, question whether the scope is appropriate.
• This is not selfishness that sacrifices UX for DX — it must be a rational choice made with the user's goal and the product's future in mind.
• The user holds decision authority. Present your findings as recommendations in a report; make any actual change or execution only after the user confirms.

Why this skill exists

The most common and costly mistake when using AI to settle a blueprint (spec, implementation plan, etc.) is believing requirements must be implemented verbatim. The user assumes "drop this feature and the implementation gets simpler too." But the reverse is often true — cutting it adds workaround code, and the next iteration rebuilds it anyway, producing double work. The paradox of reducing requirements yet increasing implementation.

This mistake persists because the user reasons about cost from general intuition, and intuition is wrong when it doesn't know what the current or intended stack provides. So this skill's job is to ask, for each decision in the blueprint, "Does this decision minimize implementation cost in this stack?" and propose a cheaper path when one exists. The final judgment of whether a proposal is "reasonable" stays with the user — they know timeline, risk, and business context more accurately.

What this skill does / doesn't do

Does: