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.

Implementation Completeness Review - Prompt

Name: Implementation Completeness Review
Author: mulawave

Prompt file imported from mulawave/Afrovision (.github/prompts/implementation-completeness-review.prompt.md). Copyright stays with the author.

Follow the project standards in copilot-instructions.

Preparation hook validation is mandatory for new implementations:

Ensure a tracker exists using new-feature-end-to-end-implementation-template
Ensure tracker completion marks are updated to reflect completed work items in the reviewed change
If missing or incomplete, verdict must be Blocked or Not Ready

Review the provided feature, code, diff, or implementation with a strict completeness standard.

Assess whether the work is actually complete across:

Preparation process compliance (tracker/template/hook checklist)
Tracker completion-state accuracy (completed/in-progress/not-started marks)
User entry points and discovery surfaces
Destination pages, dialogs, panels, and linked flows
Backend, API, storage, and state wiring
Navigation and deep links between related surfaces
Loading, empty, error, success, offline, and disabled states
Permissions, validation, and edge cases
Operational controls needed to manage created content
Verification appropriate to the change

Use this rule: a visible feature is not complete unless the surrounding user experience and expected follow-up actions are also complete.

Example standard:

If a header notifications feature exists, verify the icon, badge, dropdown or panel, read vs unread distinction, list presentation, mark all as read, deep links to relevant content, and a fully wired notifications page with management actions such as mark as read, archive, delete, select all, and delete all.

Output format:

Verdict: Ready, Not Ready, or Blocked
Findings: list the gaps or risks that prevent the work from being truly complete, ordered by impact
Missing supporting flows and states: call out anything implied by the feature but not actually implemented
Verification gaps: note missing tests, manual validation, or runtime checks
Open blockers or assumptions: only if they materially affect readiness

Review rules:

Findings come first
Do not accept backend-only or UI-only slices as complete when the feature clearly requires both
Flag placeholder controls, dead-end navigation, or missing management actions
If no major gaps are found, say that explicitly and note any residual risk
Ask only the minimum clarifying questions needed to judge completeness

Install Implementation Completeness Review 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.

Follow the project standards in [copilot-instructions](../copilot-instructions.md). Preparation hook validation is mandatory for new implementations: - Ensure a tracker exists using [new-feature-end-to-end-implementation-template](../templates/new-feature-end-to-end-implementation-template.md) - Ensure tracker completion marks are updated to reflect completed work items in the reviewed change - If missing or incomplete, verdict must be `Blocked` or `Not Ready` Review the provided feature, code, diff, or implementation with a strict completeness standard. Assess whether the work is actually complete across: - Preparation process compliance (tracker/template/hook checklist) - Tracker completion-state accuracy (completed/in-progress/not-started marks) - User entry points and discovery surfaces - Destination pages, dialogs, panels, and linked flows - Backend, API, storage, and state wiring - Navigation and deep links between related surfaces - Loading, empty, error, success, offline, and disabled states - Permissions, validation, and edge cases - Operational controls needed to manage created content - Verification appropriate to the change Use this rule: a visible feature is not complete unless the surrounding user experience and expected follow-up actions are also complete. Example standard: - If a header notifications feature exists, verify the icon, badge, dropdown or panel, read vs unread distinction, list presentation, mark all as read, deep links to relevant content, and a fully wired notifications page with management actions such as mark as read, archive, delete, select all, and delete all. Output format: 1. Verdict: `Ready`, `Not Ready`, or `Blocked` 2. Findings: list the gaps or risks that prevent the work from being truly complete, ordered by impact 3. Missing supporting flows and states: call out anything implied by the feature but not actually implemented 4. Verification gaps: note missing tests, manual validation, or runtime checks 5. Open blockers or assumptions: only if they materially affect readiness Review rules: - Findings come first - Do not accept backend-only or UI-only slices as complete when the feature clearly requires both - Flag placeholder controls, dead-end navigation, or missing management actions - If no major gaps are found, say that explicitly and note any residual risk - Ask only the minimum clarifying questions needed to judge completeness

{ "prompt": "Follow the project standards in [copilot-instructions](../copilot-instructions.md).\n\nPreparation hook validation is mandatory for new implementations:\n- Ensure a tracker exists using [new-feature-end-to-end-implementation-template](../templates/new-feature-end-to-end-implementation-template.md)\n- Ensure tracker completion marks are updated to reflect completed work items in the reviewed change\n- If missing or incomplete, verdict must be `Blocked` or `Not Ready`\n\nReview the provided feature, code, diff, or implementation with a strict completeness standard.\n\nAssess whether the work is actually complete across:\n- Preparation process compliance (tracker/template/hook checklist)\n- Tracker completion-state accuracy (completed/in-progress/not-started marks)\n- User entry points and discovery surfaces\n- Destination pages, dialogs, panels, and linked flows\n- Backend, API, storage, and state wiring\n- Navigation and deep links between related surfaces\n- Loading, empty, error, success, offline, and disabled states\n- Permissions, validation, and edge cases\n- Operational controls needed to manage created content\n- Verification appropriate to the change\n\nUse this rule: a visible feature is not complete unless the surrounding user experience and expected follow-up actions are also complete.\n\nExample standard:\n- If a header notifications feature exists, verify the icon, badge, dropdown or panel, read vs unread distinction, list presentation, mark all as read, deep links to relevant content, and a fully wired notifications page with management actions such as mark as read, archive, delete, select all, and delete all.\n\nOutput format:\n1. Verdict: `Ready`, `Not Ready`, or `Blocked`\n2. Findings: list the gaps or risks that prevent the work from being truly complete, ordered by impact\n3. Missing supporting flows and states: call out anything implied by the feature but not actually implemented\n4. Verification gaps: note missing tests, manual validation, or runtime checks\n5. Open blockers or assumptions: only if they materially affect readiness\n\nReview rules:\n- Findings come first\n- Do not accept backend-only or UI-only slices as complete when the feature clearly requires both\n- Flag placeholder controls, dead-end navigation, or missing management actions\n- If no major gaps are found, say that explicitly and note any residual risk\n- Ask only the minimum clarifying questions needed to judge completeness", "variables": [], "notes": "Review a feature, diff, or implementation for end-to-end completeness and identify missing flows, states, controls, or wiring before it is treated as done. Arguments: What feature, diff, or implementation should be audited for completeness?.", "metadata": { "source": { "provider": "github-prompts", "repository": "https://github.com/mulawave/Afrovision", "path": ".github/prompts/implementation-completeness-review.prompt.md", "ref": "f56c0e08d53be674cd726e25031fa50274f43dbe", "url": "https://github.com/mulawave/Afrovision/blob/f56c0e08d53be674cd726e25031fa50274f43dbe/.github/prompts/implementation-completeness-review.prompt.md", "key": "mulawave/Afrovision/.github/prompts/implementation-completeness-review.prompt.md" } } }

Implementation Completeness Review

About

Install Implementation Completeness Review 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