Re-imagined and re-written Debug tool. Instead of prompting Claude to perform initial analysis (and hoping it did), the tool now works through the debug process as an 'investigation', encouraging Claud to gather its 'findings' / 'hypothesis', stepping back as needed, collecting files it's gone through and keeping track of files relevant to the issue at hand. This structured investiion is then passed to the other model with far greater insight than the original debug tool ever could.

Improved prompts, guard against overengineering and flag that as an antipattern

systemprompts/analyze_prompt.py

@@ -39,6 +39,10 @@ SCOPE & FOCUS
 • Identify strengths, risks, and strategic improvement areas that affect future development
 • Avoid line-by-line bug hunts or minor style critiques—those are covered by CodeReview
 • Recommend practical, proportional changes; no "rip-and-replace" proposals unless the architecture is untenable
+• Identify and flag overengineered solutions — excessive abstraction, unnecessary configuration layers, or generic
+  frameworks introduced without a clear, current need. These should be called out when they add complexity, slow
+  onboarding, or reduce clarity, especially if the anticipated complexity is speculative or unlikely to materialize
+  in the foreseeable future.
 
 ANALYSIS STRATEGY
 1. Map the tech stack, frameworks, deployment model, and constraints

systemprompts/chat_prompt.py

@@ -29,6 +29,9 @@ SCOPE & FOCUS
 • Recommend new technologies or patterns ONLY when they provide clearly superior outcomes with minimal added complexity.
 • Avoid speculative, over-engineered, or unnecessarily abstract designs that exceed current project goals or needs.
 • Keep proposals practical and directly actionable within the existing architecture.
+• Overengineering is an anti-pattern — avoid solutions that introduce unnecessary abstraction, indirection, or
+  configuration in anticipation of complexity that does not yet exist, is not clearly justified by the current scope,
+  and may not arise in the foreseeable future.
 
 COLLABORATION APPROACH
 1. Engage deeply with Claude's input – extend, refine, and explore alternatives ONLY WHEN they are well-justified and materially beneficial.

systemprompts/codereview_prompt.py

@@ -55,6 +55,9 @@ Your review approach:
   - Ways to reduce the overall complexity while maintaining and retaining functionality without introducing regression
 8. Where further investigation and analysis is required, be direct and suggest which code or related file needs to be
 reviewed
+9. Remember: Overengineering is an anti-pattern — avoid suggesting solutions that introduce unnecessary abstraction,
+   indirection, or configuration in anticipation of complexity that does not yet exist, is not clearly justified by the
+   current scope, and may not arise in the foreseeable future.
 
 SEVERITY DEFINITIONS
 🔴 CRITICAL: Security flaws or defects that cause crashes, data loss, or undefined behavior

systemprompts/precommit_prompt.py

@@ -53,6 +53,9 @@ REVIEW METHOD
 4. Flag bugs, regressions, crash risks, data loss, or race conditions.
 5. Recommend specific fixes for each issue raised; include code where helpful.
 6. Acknowledge sound patterns to reinforce best practices.
+7. Remember: Overengineering is an anti-pattern — avoid suggesting solutions that introduce unnecessary abstraction,
+   indirection, or configuration in anticipation of complexity that does not yet exist, is not clearly justified by the
+   current scope, and may not arise in the foreseeable future.
 
 CORE ANALYSIS (adapt to diff and stack)
 • Security – injection risks, auth flaws, exposure of sensitive data, unsafe dependencies, memory safety
@@ -62,6 +65,11 @@ CORE ANALYSIS (adapt to diff and stack)
 
 ADDITIONAL ANALYSIS (only when relevant)
 • Language/runtime concerns – memory management, concurrency, exception handling
+    • Carefully assess the code's context and purpose before raising concurrency-related concerns. Confirm the presence
+    of shared state, race conditions, or unsafe access patterns before flagging any issues to avoid false positives.
+    • Also carefully evaluate concurrency and parallelism risks only after confirming that the code runs in an environment
+     where such concerns are applicable. Avoid flagging issues unless shared state, asynchronous execution, or multi-threaded
+     access are clearly possible based on context.
 • System/integration – config handling, external calls, operational impact
 • Testing – coverage gaps for new logic
     • If no tests are found in the project, do not flag test coverage as an issue unless the change introduces logic

systemprompts/thinkdeep_prompt.py

@@ -32,6 +32,9 @@ GUIDELINES
 5. Offer multiple viable strategies ONLY WHEN clearly beneficial within the current environment.
 6. Suggest creative solutions that operate within real-world constraints, and avoid proposing major shifts unless truly warranted.
 7. Use concise, technical language; assume an experienced engineering audience.
+8. Remember: Overengineering is an anti-pattern — avoid suggesting solutions that introduce unnecessary abstraction,
+   indirection, or configuration in anticipation of complexity that does not yet exist, is not clearly justified by the
+   current scope, and may not arise in the foreseeable future.
 
 KEY FOCUS AREAS (apply when relevant)
 - Architecture & Design: modularity, boundaries, abstraction layers, dependencies