| PR #297 (Auri) | PR #308 (Charles) | |
|---|---|---|
| Title | "first try skill for whole migration" | "Create a decision tree to execute using different modules a migration" |
| Files | 9 (+1090 -126) | 17 (+1308 -71) |
| Architecture | Monolithic: 1 SKILL.md + 3 reference files | Modular: 1 orchestrator + 15 phase modules |
| Strategies | Spring compat + Native Quarkus | Native Quarkus only |
| Extra content | write-rule skill refactor |
pom.xml changes for spring-boot-todo-app |
1. Dual migration strategy PR #308 only covers Native Quarkus (JAX-RS + Panache). PR #297 offers Spring compat as the recommended option, which is important for incremental migrations or teams that can't rewrite everything at once.
2. Reference files verified against Quarkus source code Three exhaustive reference files (~408 lines total):
annotation-map.md(189 lines, 10 sections, 3 columns: Spring / Native / Compat)config-map.md(146 lines, 12 sections including Spring Cloud Config)dependency-map.md(73 lines, 8 sections)
PR #308 has no reference files — its mappings are inline and much more limited (only covers the annotations used by the todo-app, not a general catalog).
3. Self-reflection and Migration Report (Step 5) 6-question self-evaluation checklist + structured report template covering: what migrated cleanly, what required manual judgment, what was left as TODO, what code was removed and why, what checks failed initially, and what's missing from the skill references. PR #308 ends at the verification phase with no documentation of what happened.
4. 11 Common Pitfalls
Lessons learned from real migrations: naming strategy mismatch (Spring snake_case vs Hibernate 6 camelCase), OSIV, JAX-RS path conflicts, Qute strict rendering, @InjectMock package change, etc. PR #308 only has inline warnings specific to the todo-app.
5. Spring compat extension limitations table (7 extensions)
Verified against Quarkus extension source code: what does NOT work in each quarkus-spring-* extension. This doesn't exist in any other skill.
6. Pre-migration workflow
Numbered branches (migration/run-01), self-update from the source repo, draft PR as a permanent record. Creates a repeatable and traceable process. PR #308 doesn't address branching or PR creation.
7. mtool integration
Prefers mtool analyze/transform when available before making manual changes.
1. Decision Gate Table with automated detection
The orchestrator defines a table with concrete grep/find commands for each phase:
| Phase | Gate Check | Detection Command | Gate Result |
|---|---|---|---|
| 3. entity-layer | @Entity without PanacheEntity |
grep -rq '@Entity' src/ && ! grep -rq 'extends PanacheEntity' src/ |
PASS/SKIP |
PR #297 analyzes the project in Step 1 but has no formal per-phase gates — the decision to execute each phase is implicit.
2. Individually reusable modules Each phase is a standalone SKILL.md with preconditions. You can run just one:
"Read
.claude/skills/spring-boot-to-quarkus/controller-to-resource/SKILL.mdand execute it"
PR #297's skill is all-or-nothing — you can't run just the templates phase.
3. Phase Dependency Graph Explicit graph of which phases depend on which:
Phase 4: repository-layer .... (requires Phase 3: entities extend PanacheEntity)
Phase 6: controller-to-resource (requires Phases 3-5: layers migrated)
Phase 6a: ui-model ........... (requires Phase 6: controllers converted)
PR #297 has a numerical order but doesn't document dependencies between phases.
4. Formal Execution Protocol Pseudocode that Claude can follow mechanically:
FOR phase IN [0..11]:
1. EVALUATE gate
2. DECIDE (ALWAYS/PASS/SKIP)
3. LOAD skill
4. EXECUTE
5. COMPILE checkpoint
6. LOG result
5. ui-model and ui-redirect as dedicated modules (409 lines combined)
Highly detailed: Model.addAttribute() → Template.data() with multiple cases, OpenRewrite recipe gap analysis, before/after code snippets with tests. These are Charles' largest modules and cover the most complex migration scenario (MVC with templates). PR #297 has inline examples but more concise.
6. Qute strict data map warning Charles documents a critical gotcha that PR #297 doesn't cover in as much detail:
"Every
.data()call site must provide the same complete set of keys. The empty-result path must include.data("noTasks", true)etc. Forgetting even one key causesTemplateException."
7. Per-phase checkbox checklists
Each module has - [ ] Step items that Claude marks off, giving progress visibility. The orchestrator has a global checklist too.
| PR #297 (Auri) | PR #308 (Charles) |
|---|---|
| No formal gates — relies on Claude judging which phases apply | No Spring compat support — native only |
| Not modular — can't run a single phase in isolation | No reference files — incomplete mappings, todo-app-specific |
| Doesn't document dependencies between phases | No self-reflection or migration report |
| No per-phase progress checkboxes | No general pitfalls documentation (naming strategy, OSIV, etc.) |
| No compat extension limitations | |
Includes a .bk backup file that shouldn't be in the PR |
|
Hardcodes Quarkus version 3.33.1 |
|
| No mtool integration | |
| No branching/PR workflow |
These PRs are highly complementary. An ideal combined version would take:
- The gate + module architecture from Charles as the execution skeleton
- The reference files + pitfalls + compat limitations from Auri as the knowledge base
- The dual strategy (compat vs native) from Auri
- The self-reflection + migration report from Auri as the final step
- The branching workflow from Auri for traceability
- The detailed ui-model / ui-redirect modules from Charles
- The Qute strict data map warning from Charles