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.

openspec-verify-terra - Prompt

Name: openspec-verify-terra
Author: nick-syspac

Prompt file imported from nick-syspac/paidsoon (.github/prompts/model-routing/openspec-verify-terra.prompt.md). Copyright stays with the author.

OpenSpec Verify (Terra)

Use the baseline workflow in opsx-apply.prompt.md and review the actual implementation as if the author were not the reviewer.

Purpose

Verify that implementation satisfies the applicable proposal/spec/design/tasks.
Check code quality, risk, regression exposure, and test coverage without assuming implementation is correct.
Produce findings grouped as CRITICAL, HIGH, MEDIUM, LOW, and PASS.

Preferred model

TODO: When the local Copilot prompt schema accepts a direct model selector, set model: GPT-5.6 Terra. This environment currently exposes mode: without a verified identifier for these model names, so this wrapper intentionally avoids guessing.

Guardrails

Verify implementation against the actual OpenSpec artifacts, not a memory of the plan.
Check behaviour, tests, security boundaries, migrations, and operational concerns.
Report spec-compliance gaps explicitly and do not mark a change ready for archive while CRITICAL or HIGH specification-compliance issues remain.
Escalate architecture verification questions to the Sol review path when the problem is design-level rather than implementation-level.

# OpenSpec Verify (Terra) Use the baseline workflow in [opsx-apply.prompt.md](../opsx-apply.prompt.md) and review the actual implementation as if the author were not the reviewer. ## Purpose - Verify that implementation satisfies the applicable proposal/spec/design/tasks. - Check code quality, risk, regression exposure, and test coverage without assuming implementation is correct. - Produce findings grouped as CRITICAL, HIGH, MEDIUM, LOW, and PASS. ## Preferred model > TODO: When the local Copilot prompt schema accepts a direct model selector, set `model: GPT-5.6 Terra`. This environment currently exposes `mode:` without a verified identifier for these model names, so this wrapper intentionally avoids guessing. ## Guardrails - Verify implementation against the actual OpenSpec artifacts, not a memory of the plan. - Check behaviour, tests, security boundaries, migrations, and operational concerns. - Report spec-compliance gaps explicitly and do not mark a change ready for archive while CRITICAL or HIGH specification-compliance issues remain. - Escalate architecture verification questions to the Sol review path when the problem is design-level rather than implementation-level.

Install openspec-verify-terra 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.

{ "prompt": "# OpenSpec Verify (Terra)\n\nUse the baseline workflow in [opsx-apply.prompt.md](../opsx-apply.prompt.md) and review the actual implementation as if the author were not the reviewer.\n\n## Purpose\n- Verify that implementation satisfies the applicable proposal/spec/design/tasks.\n- Check code quality, risk, regression exposure, and test coverage without assuming implementation is correct.\n- Produce findings grouped as CRITICAL, HIGH, MEDIUM, LOW, and PASS.\n\n## Preferred model\n> TODO: When the local Copilot prompt schema accepts a direct model selector, set `model: GPT-5.6 Terra`. This environment currently exposes `mode:` without a verified identifier for these model names, so this wrapper intentionally avoids guessing.\n\n## Guardrails\n- Verify implementation against the actual OpenSpec artifacts, not a memory of the plan.\n- Check behaviour, tests, security boundaries, migrations, and operational concerns.\n- Report spec-compliance gaps explicitly and do not mark a change ready for archive while CRITICAL or HIGH specification-compliance issues remain.\n- Escalate architecture verification questions to the Sol review path when the problem is design-level rather than implementation-level.", "variables": [], "notes": "Independent verification against OpenSpec artifacts, using the Terra tier. Mode: agent.", "metadata": { "source": { "provider": "github-prompts", "repository": "https://github.com/nick-syspac/paidsoon", "path": ".github/prompts/model-routing/openspec-verify-terra.prompt.md", "ref": "1bdacebb3d186d3d8188871dc94c0148b5d06c1a", "url": "https://github.com/nick-syspac/paidsoon/blob/1bdacebb3d186d3d8188871dc94c0148b5d06c1a/.github/prompts/model-routing/openspec-verify-terra.prompt.md", "key": "nick-syspac/paidsoon/.github/prompts/model-routing/openspec-verify-terra.prompt.md" } } }

openspec-verify-terra

About

OpenSpec Verify (Terra)

Purpose

Preferred model

Guardrails

Use it

Install openspec-verify-terra 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

Manifest

Reviews