How long does the integration take?

Change one base URL in an OpenAI-compatible client, or install the Python or TypeScript SDK; the quickstart routes a first request in a few minutes.

Will this lock us into another vendor?

No. The router is Apache-2.0 open source, your provider keys stay yours, and the API is OpenAI-compatible, so leaving is a change of base URL.

What happens when a provider fails?

The router falls back to the next model your policy allows and records the fallback in the trace, so an outage costs a retry, not an incident.

wow-viewer Tool Migration Sequence Plan - Prompt

Name: wow-viewer Tool Migration Sequence Plan
Author: akspa0

Prompt file imported from akspa0/parp-tools (.codex/prompts/wow-viewer-tool-migration-sequence-plan.md). Copyright stays with the author.

Design the migration sequence for the wow-viewer tool suite so the old-repo mess is absorbed in a realistic order instead of a giant simultaneous rewrite.

Read First

gillijimproject_refactor/memory-bank/activeContext.md
gillijimproject_refactor/memory-bank/progress.md
gillijimproject_refactor/src/MdxViewer/memory-bank/activeContext.md
AGENTS.md
gillijimproject_refactor/plans/v0_5_0_wow_viewer_bootstrap_and_migration_draft_2026-03-25.md

Goal

Define the order to migrate shared core services, file-format ownership, CLI tools, and GUI tool panels into wow-viewer with explicit dependency management and realistic vertical slices.

Inputs To Sequence Explicitly

repo bootstrap and project skeleton
shared file-format library
runtime/data-source service layer
viewer shell cutover
tool inventory cutover
CLI/GUI dual-surface workflows
performance-sensitive work that should wait until after core boundaries are real

Non-Negotiable Constraints

Do not schedule a giant all-at-once rewrite.
Do not let enhanced renderer ambitions consume the tool-suite migration plan.
Do not migrate tools before the shared service/core boundary they depend on exists.
Keep real-data validation visible in the phase exits.
Be explicit about what remains in parp-tools during each phase.

What The Plan Must Produce

The phase order.
Entry and exit criteria per phase.
Dependencies between phases.
The first three vertical slices.
What should deliberately wait until later.
Where real-data validation must occur.
What would cause the plan to fail or thrash.

Deliverables

Return all items:

numbered phase plan
dependency map
first three vertical slices
per-phase validation expectations
what stays in parp-tools during each phase
deferred work list
major sequencing risks

First Output

Start with:

the first phase that should happen before any serious tool migration
the first vertical slice that proves the architecture split is real
the tool families that should wait until later phases
the biggest sequencing mistake to avoid

Install wow-viewer Tool Migration Sequence Plan and it becomes one more candidate the router can pick - when it fits.

A listing is a routing target with a manifest: what it does, which domains it covers, what it costs and who publishes it. Once installed it sits beside your own models and tools, is scored like any other candidate for each request, and shows up in the trace when it wins. Ratings come from workspaces that installed it, one per account.

Design the migration sequence for the `wow-viewer` tool suite so the old-repo mess is absorbed in a realistic order instead of a giant simultaneous rewrite. ## Read First 1. `gillijimproject_refactor/memory-bank/activeContext.md` 2. `gillijimproject_refactor/memory-bank/progress.md` 3. `gillijimproject_refactor/src/MdxViewer/memory-bank/activeContext.md` 4. `AGENTS.md` 5. `gillijimproject_refactor/plans/v0_5_0_wow_viewer_bootstrap_and_migration_draft_2026-03-25.md` ## Goal Define the order to migrate shared core services, file-format ownership, CLI tools, and GUI tool panels into `wow-viewer` with explicit dependency management and realistic vertical slices. ## Inputs To Sequence Explicitly - repo bootstrap and project skeleton - shared file-format library - runtime/data-source service layer - viewer shell cutover - tool inventory cutover - CLI/GUI dual-surface workflows - performance-sensitive work that should wait until after core boundaries are real ## Non-Negotiable Constraints - Do not schedule a giant all-at-once rewrite. - Do not let enhanced renderer ambitions consume the tool-suite migration plan. - Do not migrate tools before the shared service/core boundary they depend on exists. - Keep real-data validation visible in the phase exits. - Be explicit about what remains in `parp-tools` during each phase. ## What The Plan Must Produce 1. The phase order. 2. Entry and exit criteria per phase. 3. Dependencies between phases. 4. The first three vertical slices. 5. What should deliberately wait until later. 6. Where real-data validation must occur. 7. What would cause the plan to fail or thrash. ## Deliverables Return all items: 1. numbered phase plan 2. dependency map 3. first three vertical slices 4. per-phase validation expectations 5. what stays in `parp-tools` during each phase 6. deferred work list 7. major sequencing risks ## First Output Start with: 1. the first phase that should happen before any serious tool migration 2. the first vertical slice that proves the architecture split is real 3. the tool families that should wait until later phases 4. the biggest sequencing mistake to avoid

{ "prompt": "Design the migration sequence for the `wow-viewer` tool suite so the old-repo mess is absorbed in a realistic order instead of a giant simultaneous rewrite.\n\n## Read First\n\n1. `gillijimproject_refactor/memory-bank/activeContext.md`\n2. `gillijimproject_refactor/memory-bank/progress.md`\n3. `gillijimproject_refactor/src/MdxViewer/memory-bank/activeContext.md`\n4. `AGENTS.md`\n5. `gillijimproject_refactor/plans/v0_5_0_wow_viewer_bootstrap_and_migration_draft_2026-03-25.md`\n\n## Goal\n\nDefine the order to migrate shared core services, file-format ownership, CLI tools, and GUI tool panels into `wow-viewer` with explicit dependency management and realistic vertical slices.\n\n## Inputs To Sequence Explicitly\n\n- repo bootstrap and project skeleton\n- shared file-format library\n- runtime/data-source service layer\n- viewer shell cutover\n- tool inventory cutover\n- CLI/GUI dual-surface workflows\n- performance-sensitive work that should wait until after core boundaries are real\n\n## Non-Negotiable Constraints\n\n- Do not schedule a giant all-at-once rewrite.\n- Do not let enhanced renderer ambitions consume the tool-suite migration plan.\n- Do not migrate tools before the shared service/core boundary they depend on exists.\n- Keep real-data validation visible in the phase exits.\n- Be explicit about what remains in `parp-tools` during each phase.\n\n## What The Plan Must Produce\n\n1. The phase order.\n2. Entry and exit criteria per phase.\n3. Dependencies between phases.\n4. The first three vertical slices.\n5. What should deliberately wait until later.\n6. Where real-data validation must occur.\n7. What would cause the plan to fail or thrash.\n\n## Deliverables\n\nReturn all items:\n\n1. numbered phase plan\n2. dependency map\n3. first three vertical slices\n4. per-phase validation expectations\n5. what stays in `parp-tools` during each phase\n6. deferred work list\n7. major sequencing risks\n\n## First Output\n\nStart with:\n\n1. the first phase that should happen before any serious tool migration\n2. the first vertical slice that proves the architecture split is real\n3. the tool families that should wait until later phases\n4. the biggest sequencing mistake to avoid", "variables": [], "notes": "Sequence the wow-viewer tool-suite migration into realistic vertical slices. Use when deciding the order to move old tools, file families, and shared services without exploding scope. Arguments: Optional tool family, dependency problem, or milestone boundary to prioritize.", "metadata": { "source": { "provider": "github-codex-prompts", "repository": "https://github.com/akspa0/parp-tools", "path": ".codex/prompts/wow-viewer-tool-migration-sequence-plan.md", "ref": "5608d59a180dc4296e29bc19be1a3cc5e94ef309", "url": "https://github.com/akspa0/parp-tools/blob/5608d59a180dc4296e29bc19be1a3cc5e94ef309/.codex/prompts/wow-viewer-tool-migration-sequence-plan.md", "key": "akspa0/parp-tools/.codex/prompts/wow-viewer-tool-migration-sequence-plan.md" } } }

wow-viewer Tool Migration Sequence Plan

About

Read First

Goal

Inputs To Sequence Explicitly

Non-Negotiable Constraints

What The Plan Must Produce

Deliverables

First Output

Install wow-viewer Tool Migration Sequence Plan and it becomes one more candidate the router can pick - when it fits.

What it costs to adopt - in engineering time.

One base URL

No vendor lock-in

Failover built in

Use it

Manifest

Reviews