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 Inventory And Cutover Plan - Prompt

Name: wow-viewer Tool Inventory And Cutover Plan
Author: akspa0

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

Inventory the old repo tool sprawl and produce a concrete cutover plan for the wow-viewer tool suite.

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

Produce an explicit inventory of the tools we built across the old repo and decide which ones become rebuilt first-class tools in wow-viewer, which ones fold into existing viewer panels, which ones stay standalone CLIs, and which ones remain archaeology/reference only.

Tools To Classify Explicitly

gillijimproject_refactor/src/MdxViewer built-in panels and utilities
gillijimproject_refactor/src/WoWMapConverter/WoWMapConverter.Cli
gillijimproject_refactor/AlphaWDTAnalysisTool/AlphaWdtAnalyzer.Cli
gillijimproject_refactor/AlphaWdtInspector
gillijimproject_refactor/DBCTool
gillijimproject_refactor/DBCTool.V2
gillijimproject_refactor/BlpResizer
gillijimproject_refactor/AlphaLkToAlphaStandalone
gillijimproject_refactor/src/Pm4Research.Cli
gillijimproject_refactor/src/MDX-L_Tool
gillijimproject_refactor/tools/WlAnalyzer
parpToolbox
PM4Tool
ADTPrefabTool
WoWRollback sub-tools and modules where still relevant

Classification Buckets

rebuild as first-class wow-viewer tool
fold into the main viewer as a panel or workflow
keep as standalone CLI over shared services
keep as research/reference only in parp-tools
discard as superseded duplication

Non-Negotiable Constraints

Do not let every historical tool survive as its own permanent app if a shared core + fewer surfaces is cleaner.
Do not collapse everything into the viewer UI if headless execution still matters.
Do not keep duplicated CLI and GUI logic if both surfaces can ride the same services.
Be explicit about tools that are still valuable only as archaeology or reverse-engineering evidence.

What The Plan Must Produce

A full tool inventory.
A classification for each tool.
The destination in wow-viewer for each surviving tool.
Shared-core dependencies for each tool.
Which current viewer panels should survive, be rebuilt, merge, or die.
Which legacy executables should not be ported forward.
The first three tools or tool families to migrate.

Deliverables

Return all items:

tool inventory table
classification per tool
destination app/panel/CLI mapping
shared-service requirements per tool family
archaeology-only leftovers
first migration wave
major cutover risks

First Output

Start with:

the tool families that clearly deserve first-class survival in wow-viewer
the biggest duplicated tools that should be merged or killed
which old executables look like archaeology, not production assets
the first migration wave you would schedule

Install wow-viewer Tool Inventory And Cutover 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.

Inventory the old repo tool sprawl and produce a concrete cutover plan for the `wow-viewer` tool suite. ## 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 Produce an explicit inventory of the tools we built across the old repo and decide which ones become rebuilt first-class tools in `wow-viewer`, which ones fold into existing viewer panels, which ones stay standalone CLIs, and which ones remain archaeology/reference only. ## Tools To Classify Explicitly - `gillijimproject_refactor/src/MdxViewer` built-in panels and utilities - `gillijimproject_refactor/src/WoWMapConverter/WoWMapConverter.Cli` - `gillijimproject_refactor/AlphaWDTAnalysisTool/AlphaWdtAnalyzer.Cli` - `gillijimproject_refactor/AlphaWdtInspector` - `gillijimproject_refactor/DBCTool` - `gillijimproject_refactor/DBCTool.V2` - `gillijimproject_refactor/BlpResizer` - `gillijimproject_refactor/AlphaLkToAlphaStandalone` - `gillijimproject_refactor/src/Pm4Research.Cli` - `gillijimproject_refactor/src/MDX-L_Tool` - `gillijimproject_refactor/tools/WlAnalyzer` - `parpToolbox` - `PM4Tool` - `ADTPrefabTool` - `WoWRollback` sub-tools and modules where still relevant ## Classification Buckets - rebuild as first-class `wow-viewer` tool - fold into the main viewer as a panel or workflow - keep as standalone CLI over shared services - keep as research/reference only in `parp-tools` - discard as superseded duplication ## Non-Negotiable Constraints - Do not let every historical tool survive as its own permanent app if a shared core + fewer surfaces is cleaner. - Do not collapse everything into the viewer UI if headless execution still matters. - Do not keep duplicated CLI and GUI logic if both surfaces can ride the same services. - Be explicit about tools that are still valuable only as archaeology or reverse-engineering evidence. ## What The Plan Must Produce 1. A full tool inventory. 2. A classification for each tool. 3. The destination in `wow-viewer` for each surviving tool. 4. Shared-core dependencies for each tool. 5. Which current viewer panels should survive, be rebuilt, merge, or die. 6. Which legacy executables should not be ported forward. 7. The first three tools or tool families to migrate. ## Deliverables Return all items: 1. tool inventory table 2. classification per tool 3. destination app/panel/CLI mapping 4. shared-service requirements per tool family 5. archaeology-only leftovers 6. first migration wave 7. major cutover risks ## First Output Start with: 1. the tool families that clearly deserve first-class survival in `wow-viewer` 2. the biggest duplicated tools that should be merged or killed 3. which old executables look like archaeology, not production assets 4. the first migration wave you would schedule

{ "prompt": "Inventory the old repo tool sprawl and produce a concrete cutover plan for the `wow-viewer` tool suite.\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\nProduce an explicit inventory of the tools we built across the old repo and decide which ones become rebuilt first-class tools in `wow-viewer`, which ones fold into existing viewer panels, which ones stay standalone CLIs, and which ones remain archaeology/reference only.\n\n## Tools To Classify Explicitly\n\n- `gillijimproject_refactor/src/MdxViewer` built-in panels and utilities\n- `gillijimproject_refactor/src/WoWMapConverter/WoWMapConverter.Cli`\n- `gillijimproject_refactor/AlphaWDTAnalysisTool/AlphaWdtAnalyzer.Cli`\n- `gillijimproject_refactor/AlphaWdtInspector`\n- `gillijimproject_refactor/DBCTool`\n- `gillijimproject_refactor/DBCTool.V2`\n- `gillijimproject_refactor/BlpResizer`\n- `gillijimproject_refactor/AlphaLkToAlphaStandalone`\n- `gillijimproject_refactor/src/Pm4Research.Cli`\n- `gillijimproject_refactor/src/MDX-L_Tool`\n- `gillijimproject_refactor/tools/WlAnalyzer`\n- `parpToolbox`\n- `PM4Tool`\n- `ADTPrefabTool`\n- `WoWRollback` sub-tools and modules where still relevant\n\n## Classification Buckets\n\n- rebuild as first-class `wow-viewer` tool\n- fold into the main viewer as a panel or workflow\n- keep as standalone CLI over shared services\n- keep as research/reference only in `parp-tools`\n- discard as superseded duplication\n\n## Non-Negotiable Constraints\n\n- Do not let every historical tool survive as its own permanent app if a shared core + fewer surfaces is cleaner.\n- Do not collapse everything into the viewer UI if headless execution still matters.\n- Do not keep duplicated CLI and GUI logic if both surfaces can ride the same services.\n- Be explicit about tools that are still valuable only as archaeology or reverse-engineering evidence.\n\n## What The Plan Must Produce\n\n1. A full tool inventory.\n2. A classification for each tool.\n3. The destination in `wow-viewer` for each surviving tool.\n4. Shared-core dependencies for each tool.\n5. Which current viewer panels should survive, be rebuilt, merge, or die.\n6. Which legacy executables should not be ported forward.\n7. The first three tools or tool families to migrate.\n\n## Deliverables\n\nReturn all items:\n\n1. tool inventory table\n2. classification per tool\n3. destination app/panel/CLI mapping\n4. shared-service requirements per tool family\n5. archaeology-only leftovers\n6. first migration wave\n7. major cutover risks\n\n## First Output\n\nStart with:\n\n1. the tool families that clearly deserve first-class survival in `wow-viewer`\n2. the biggest duplicated tools that should be merged or killed\n3. which old executables look like archaeology, not production assets\n4. the first migration wave you would schedule", "variables": [], "notes": "Inventory old repo tools and decide what becomes a first-class wow-viewer tool, what merges into the viewer, what stays CLI-only, and what remains archaeology-only. Arguments: Optional tool family, executable, panel, or domain to prioritize.", "metadata": { "source": { "provider": "github-codex-prompts", "repository": "https://github.com/akspa0/parp-tools", "path": ".codex/prompts/wow-viewer-tool-inventory-cutover-plan.md", "ref": "4f7fb94cfad6bf6348c55c28ae9361c2d2fd9cb7", "url": "https://github.com/akspa0/parp-tools/blob/4f7fb94cfad6bf6348c55c28ae9361c2d2fd9cb7/.codex/prompts/wow-viewer-tool-inventory-cutover-plan.md", "key": "akspa0/parp-tools/.codex/prompts/wow-viewer-tool-inventory-cutover-plan.md" } } }

wow-viewer Tool Inventory And Cutover Plan

About

Read First

Goal

Tools To Classify Explicitly

Classification Buckets

Non-Negotiable Constraints

What The Plan Must Produce

Deliverables

First Output

Install wow-viewer Tool Inventory And Cutover 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