Java changing with tests

**Judgement:** A solid, process-focused skill for making safe Java changes backed by tests and producing PR-ready summaries. Best suited to disciplined, incremental edits rather than large, exploratory overhauls. **Strengths & Benefits** - Centers on explicit acceptance criteria and a small-diff mindset, which tends to produce safer, reviewable changes. - Requires mapping the repo (module, entrypoint, test locations), improving context and reducing “blind” edits. - Emphasizes running targeted unit tests first and only escalating to broader/integration tests as needed, balancing speed and confidence. - Output contract (plan, files changed with intent, commands and results, risks/follow-ups) aligns well with real-world PR expectations. **Key Risks / Limitations** - Assumes a reasonably standard Java testing setup; unusual build systems or custom test workflows may need extra manual guidance. - Safety depends on the quality and coverage of the existing tests; in weakly tested projects it can only provide limited guarantees. - May be slower on large monorepos if full `mvn test` (or equivalent) is required frequently. **Recommended Scenarios** - Teams that require evidence-backed Java changes (features, refactors, or bugfixes) with clear test commands and results for review. - Codebases where minimal, surgical changes are preferred over broad rewrites, and acceptance criteria can be clearly articulated. - Situations where you want a repeatable, auditable workflow: plan → focused edits → targeted tests → broader verification → PR-ready summary. **Less Ideal For** - Massive architectural changes where the “smallest diff” constraint is less relevant. - Projects with non-standard or poorly documented build/test setups, unless you’re willing to provide detailed instructions to the skill.