Install any skill in seconds. Free to start, no credit card required.
Get Started Free →levnikolaevich/ln-76-architecture-migration-planner
Plans a reversible architecture migration with compatibility, data movement, rollout, and rollback.
Passed 8 of 14 test cases with the skill, and 6 of 14 without it.
and 8 more in the full report
7 fixed7 passed either way7 still failing4 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 7 test cases the skill fixed. Same model, same prompt, with and without the skill.
We evaluated our migration from REST to gRPC and completed 18 checklist items while 2 items remain UNPROVEN due to missing load test metrics. Format the Completion section of your 5-part report (Result, Scope, Evidence, Verification, Completion) to reflect this status.
| Checked | Without skill | With skill |
|---|---|---|
| Formats the completion status line as Checklist: X/Y complete. | Missed | Passed |
| Documents the reason and outcome impact for each UNPROVEN checklist item. | Passed | Passed |
The instructions your model reads when the skill loads.
Goal: Plan a safe transition from evidenced current architecture to an explicit target, with reversibility limits and recovery actions. Change only the approved migration document; do not execute migrations, edit product code, build a generic task plan, approve delivery, or hide irreversible steps.
Execution contract: The ordered checkboxes are the Definition of Done. Track every item internally as PENDING, PROVEN with concrete evidence, CLEARED with evidence that its condition is absent, or UNPROVEN with a gap; reading, delegation, or tool failure is not proof. Reconcile items after each section. Before returning, resolve all PENDING and count only PROVEN and CLEARED; apply the skill's verdict and approval rules to every gap.
Preserve user intent, scope, and existing authorization. Continue authorized work; ask only for consequential unresolved choices or required external approval. Scale depth to material risk without silently skipping checks. Preserve dependency and safety ordering; otherwise choose the verification method appropriate to each obligation.
| Need | Preferred capability | Fallback |
|---|---|---|
| Current and target states | Repository evidence plus approved architecture artifacts | Explicit user-provided states with limitations |
| Consumers and compatibility | Language intelligence, schema tools, config search, telemetry, and direct inspection | Conservative inventory marked UNVERIFIED |
| Data scale and runtime risk | Production metrics, checked-in reports, migrations, and workload evidence | Ranges with validation gates before execution |
| External migration constraints | Official vendor migration and compatibility guidance | Mark dependent phases BLOCKED or UNVERIFIED |
| Document mutation | Minimal patch to the approved migration-plan artifact | Return BLOCKED when authority or path is unclear |
A migration phase must leave the system in a supported state. Additive and reversible steps precede cutover; destructive cleanup follows verified zero use.
docs/architecture/migration-plan.md.BLOCKED rather than invent either state.test cases passed, vs 6 / 14 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.