Any added suggestion or limitation to system prompt will degrade output when a well-structured prompt is given, improve your prompts and rules if you want a different result, Sonnet 3.7-thinking should not be used without a well structured prompt with a clear action plan, as a hint you can improve its results by adding this clean code rule to your .mdc rules(or at least KISS section), I’m using 3.7-thinking with simple instructions and without any issues of overengineering:
---
description: MUST activate when interacting with files matching the globs. Coding principles to write clean code.
globs: *.py, *.js, *.ts, *.jsx, *.tsx, *.java, *.kt, *.go, *.rs, *.c, *.cpp, *.h, *.hpp, *.cs, *.sh, *.bash, *.zsh, *.php, *.rb, *.swift, *.m, *.mm, *.pl, *.pm, *.lua, *.sql, *.html, *.css, *.scss, *.sass, *.less
---
Priority: High
Instruction: MUST follow all of <principles>
<?xml version="1.0" encoding="UTF-8"?>
<principles>
<principle name="DRY">
<definition>Every piece of knowledge must have a single, unambiguous, authoritative representation within a system</definition>
<key_points>
<point>Eliminate code duplication through abstraction</point>
<point>Centralize business logic in single sources</point>
<point>Improve maintainability through code reuse</point>
</key_points>
<consequences>
<risk>Change propagation errors</risk>
<risk>Inconsistent behavior</risk>
</consequences>
<solution>
<approach>Abstract shared logic</approach>
<approach>Centralize business rules</approach>
</solution>
<implementation_methods>
<method>Parameterization</method>
<method>Inheritance patterns</method>
<method>Configuration centralization</method>
</implementation_methods>
</principle>
<principle name="CurlysLaw">
<definition>Each code entity should have single responsibility and consistent meaning</definition>
<key_points>
<point>Functions/classes should do one thing well</point>
<point>Avoid multi-purpose variables</point>
<point>Prevent context-dependent behavior</point>
</key_points>
<sub_principle type="SingleResponsibility">
<definition>Entity should have one reason to change</definition>
<metrics>
<metric>Max 3-line function description</metric>
</metrics>
</sub_principle>
</principle>
<principle name="KISS">
<definition>Prioritize simplicity in design and implementation</definition>
<benefits>
<benefit>Reduced implementation time</benefit>
<benefit>Lower defect probability</benefit>
<benefit>Enhanced maintainability</benefit>
</benefits>
<metrics>
<metric>Cyclomatic complexity < 5</metric>
</metrics>
<implementation>
<guideline>Do the simplest thing that could possibly work</guideline>
<guideline>Avoid speculative generality</guideline>
</implementation>
</principle>
<principle name="CognitiveClarity">
<definition>Code should be immediately understandable</definition>
<sub_principle type="DontMakeMeThink">
<definition>Minimize cognitive load through immediate understandability</definition>
<metrics>
<metric>Time-to-understand < 30 seconds</metric>
<metric>Zero surprise factor</metric>
</metrics>
</sub_principle>
<implementation>
<strategy>Meaningful naming conventions</strategy>
<strategy>Predictable patterns</strategy>
<strategy>Minimal mental mapping requirements</strategy>
</implementation>
</principle>
<principle name="YAGNI">
<definition>Implement features only when actually needed</definition>
<original_justification>
<reason>Save time by avoiding unneeded code</reason>
<reason>Prevent guesswork pollution</reason>
</original_justification>
</principle>
<principle name="OptimizationDiscipline">
<definition>Delay performance tuning until proven necessary</definition>
<quote author="Donald Knuth">"Premature optimization is the root of all evil"</quote>
<guidelines>
<guideline>Profile before optimizing</guideline>
<guideline>Focus on critical 3%</guideline>
</guidelines>
<statistics>
<statistic name="criticalSectionPercentage" value="3%"/>
<statistic name="nonCriticalOptimizationAttempts" value="97%"/>
</statistics>
</principle>
<principle name="BoyScout">
<definition>Continuous incremental improvement of code quality</definition>
<practice>
<action>Opportunistic refactoring</action>
<action>Technical debt reduction</action>
<action>Immediate cleanup of discovered issues</action>
</practice>
<quality_metrics>
<metric>Code health index ≥ 0.8</metric>
</quality_metrics>
<degradation_rate max="5%">Allowed monthly decline</degradation_rate>
<rationale>
<reason>Counteracts natural code quality decay</reason>
<reason>Reduces technical debt compound interest</reason>
</rationale>
</principle>
<principle name="MaintainerFocus">
<definition>Code for long-term maintainability</definition>
<considerations>
<consideration>Assume unfamiliar maintainers</consideration>
<consideration>Document non-obvious decisions</consideration>
<consideration>Anticipate future modification needs</consideration>
</considerations>
<quote author="Martin Golding">"Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live"</quote>
<practice>
<action>Assume zero domain knowledge in maintainers</action>
</practice>
<time_factor>
<consideration>Assume 6-month knowledge decay</consideration>
<consideration>Code becomes foreign after 1 year</consideration>
</time_factor>
</principle>
<principle name="LeastAstonishment">
<definition>Meet user expectations through predictable behavior</definition>
<implementation>
<requirement>Consistent naming</requirement>
<requirement>Standard patterns</requirement>
<requirement>Minimal side effects</requirement>
</implementation>
<violation_examples>
<example>Unexpected side effects in getter methods</example>
<example>Non-standard exception throwing patterns</example>
</violation_examples>
<convention_rules>
<rule>Follow language idioms</rule>
<rule>Maintain consistent error handling</rule>
</convention_rules>
</principle>
</principles>