Consider adding waste judge to sdd workflow

[InfJoker]

Hello! Using your plugin and tried going through sdd flow multiple times. Though results were good, I noticed that agent just makes a lot of duplication that eventually leads to unmaintainable code. I found out that running waste judge reduces time spent on reviews and iteration after implementation was already done. I only added waste judge as final gate, but I think we can try to place it in plan phase also

[LeoVS09]

Sure, good idea @InfJoker. I actually rarely have code duplication, but still added jscpd check as part of the linting step in my projects, so the agent resolves this issue before marking the task as complete.
But still adding some refactoring judge check as part of the process is a good idea. Can you elaborate on the waste judge? Does it some custom agent that you wrote? Can you share the prompt?
Do you want to add a check of the specification file itself as part of plan phase?

[InfJoker]

@LeoVS09 wow, I didn't know such tools exist, let me take a look. But
I am mainly cpp user, so I guess your tool will not work for me. Also llm tends to make not exact copy paste, but duplicate concepts and logic. That really takes time during review.

Waste judge is basically agent inspired by your kaizen muda analysis. I just quickly crafted a prompt to enhance my workflow- it seems it gives positive results whenever I ran sdd workflow.

I wanted to chat with you about including this kind of analysis in the plugin and what other ideas you might have.

[LeoVS09]

Thank you. Very interesting way of using the Kaizen plugin.
Yep, the jscpd is a tool for JS/TS only. CPP probably has something similar. But if we talk about overall code quality, you're right. The code is not exactly identical, but it is not reused often enough.

I see a few ways to tackle this:

• Possible to extend the DDD plugin rules with additional rules to avoid code duplication. They are injected in agent context during code reading/wiring. So it should be used by implementation agents and judges to verify during the code-writing stage.
• Possible to add a waste judge at the end of the implementation workflow, or extend the existing verification step at the end. But one judge will probably work well only with small to medium changes and not in large codebases. For larger cases, we need to launch multiple judges, which essentially will turn it into /code-review:review-local-changes command, which is not great to copy and paste. Plus, the orchestrator can have a too polluted context at the end of implementation, which will prevent him from following the new orchestration workflow precisely enough.
• As a simple, proactive solution. Possible to add a requirement for the QA agent to always include some basic checks in all code modification commands, like: no duplicated code, align with CLAUDE.md/CONTRIBUTING.md/rules, and pass build/lint/tests. But avoiding code duplication may require judges to spend more time searching the codebase, rather than on business-related criteria, so it also has drawbacks.
• A more proper, generic approach would be to add Waste Judge to /code-review:review-local-changes and /code-review:review-pr. So it can be run after verification and even in CI/CD pipeline. But it is obviously not so simple and self-contained, like using only the SDD plugin commands.
• Maybe better to treat code duplication as a high-priority criterion and move it to the initial stages of specification wiring, to code impact analysis. The Code Explorer agent can check which functions and classes already exist and can be reused during implementation, directly or indirectly (by extending them), and include their mentions in its analysis. This will allow the rest of the agents and judges to incorporate it into their processes.

So... sounds like all variants have their pluses and minuses. Better to combine them to find an optimal solution:

• Let's start by adding potentially reusable functions/classes research to the Codebase Impact Analysis stage.
• Add a requirement to the Software Architect agent to use this information during his stage
• Add a list of required checks, like "build/lint/test pass" to the QA agent, and the requirement to add criteria for what code should be reused during each implementation stage -> This will allow judges to focus only on their code part with already known functions, and not require them to make any additional research.
• As a last check, add Waste Judge during the implementation verification stage. Maybe even better to rename it to something more generic, like Code Quality Judge, and extend with different rules from the DDD plugin and clean architecture guidelines.

All of it together should surface and fix the majority of the issues. I can assume it will not have a big impact on execution time, in case the majority of problems are found even before the Code Quality Judge is launched. But all of it still will have only sub-optimal results, because on big amount of changes agents tend to miss code or halicunate.

To make it more error-prone, it is better to extend /code-review:review-local-changes and /code-review:review-pr commands with Waste/Code Quality Judge. One or a few instances of these agents should be capable of reviewing the whole codebase, as an additional check for large changes. And it will allow developers to choose whether the task deserves to spend tokens on it or not.

Okay, sounds like a plan. @InfJoker, thank you for the suggestion. We will add updates of SDD and Code Review to our board.

[InfJoker]

Is it possible to request a review when this is done? Or I can even volunteer to contribute to your vision

[LeoVS09]

Sure, you can make PR as you see it. We will discuss implementation details during review