1. When examining diffs, run `git --no-pager diff <commit>` and describe the changes in the diff
2. When writing tests, don't introduce new patterns of testing, follow the exising patterns
3. Don't create new files without asking first 
4. Don't run new commands without asking first (unless it's part of an approved plan step iteration, like running `mvn test` or `mvn clean install` to check fixes).
5. When planning, break the plan into incremental steps, then break those into incremental steps.
6. If asked a question, answer the question and then do nothing. Don't answer more than needed.
7. when writing tests, ask before changing the implementation under test. 
8. when writing tests, if there are issues that maybe suggest you might skip tests, never skip tests to work around issues. stop coding and ask for input. 
9. when answering questions about code, always provide links to the exact lines of code
10. Always ask when using git commands
11. Terminal commands should always be for Fish shell
12 Follow Java coding standards
13 Avoid using raw types
14 Use Project Reactor syntax when possible
15 Prefer functional programming when possible

all rules are required, state the rule and your idea before breaking any rule

- Follow Java coding standards
- Avoid using raw types

<!-- Sequential Thinking Workflow -->
<assistant>
    <toolbox>
        <mcp_server name="sequential-thinking"
                        role="workflow_controller"
                        execution="sequential-thinking"
                        description="Initiate the sequential-thinking MCP server">
            <tool name="STEP" value="1">
                <description>Gather context by reading the relevant file(s).</description>
                <arguments>
                    <argument name="instructions" value="Seek proper context in the codebase to understand what is required. If you are unsure, ask the user." type="string" required="true"/>
                    <argument name="should_read_entire_file" type="boolean" default="true" required="false"/>
                </arguments>
                <result type="string" description="Context gathered from the file(s). Output can be passed to subsequent steps."/>
            </tool>
            <tool name="STEP" value="2">
                <description>Generate code changes based on the gathered context (from STEP 1).</description>
                <arguments>
                    <argument name="instructions" value="Generate the proper changes/corrections based on context from STEP 1." type="string" required="true"/>
                    <argument name="code_edit" type="object" required="true" description="Output: The proposed code modifications."/>
                </arguments>
                <result type="object" description="The generated code changes (code_edit object). Output can be passed to subsequent steps."/>
            </tool>
            <tool name="STEP" value="3">
                <description>Review the generated changes (from STEP 2) and suggest improvements.</description>
                <arguments>
                    <argument name="instructions" type="string" value="Review the changes applied in STEP 2 for gaps, correctness, and adherence to guidelines. Suggest improvements or identify any additional steps needed." required="true"/>
                </arguments>
                <result type="string" description="Review feedback, suggested improvements, or confirmation of completion. Final output of the workflow."/>
            </tool>
        </mcp_server>
    </toolbox>
</assistant>

Review this code for readability, performance, and maintainability. Suggest any improvements or flag any bad practices.

Review the changes between this branch and master @diff

Consider:
1. Code quality and adherence to best practices
2. Potential bugs or edge cases
3. Performance optimizations
4. Readability and maintainability
5. Any security concerns
Suggest improvements and explain your reasoning for each suggestion.
Don't suggest Javadoc documentation