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.

speckit.bugfix.report - Prompt

Name: speckit.bugfix.report
Author: eitatech

Prompt file imported from eitatech/gatomia-vscode (.windsurf/workflows/speckit.bugfix.report.md). Fill in {{arguments}} before use. Copyright stays with the author.

Report Bug

Capture a bug discovered during implementation and trace it back to the relevant specification artifacts. Produces a structured bug report that maps the issue to spec requirements, plan sections, and tasks.

User Input

{{arguments}}

You MUST consider the user input before proceeding (if not empty). The user describes the bug — what went wrong, error messages, unexpected behavior, or a gap discovered during implementation.

Prerequisites

Verify a spec-kit project exists by checking for .specify/ directory
Locate the current feature's spec directory (by branch name or most recently modified)
Verify at least spec.md exists

Outline

Load artifacts: Read from the current feature directory:
- Required: spec.md (the specification)
- Optional: plan.md, tasks.md, research.md, data-model.md

Analyze the bug: From the user's description, classify the bug:

Bug Type	Description	Example
Spec gap	Requirement missing from spec	Auth flow doesn't handle expired tokens
Spec conflict	Two requirements contradict	"Must be stateless" vs "Must track sessions"
Implementation drift	Code diverges from spec	Spec says REST, code uses GraphQL
Untested flow	Edge case not covered in success criteria	Concurrent user updates not handled
Dependency issue	External dependency behaves differently than assumed	API response format changed

Trace to artifacts: Map the bug to specific sections in each artifact:
- spec.md: Which user story, requirement, or success criterion is affected?
- plan.md: Which plan section covers this area?
- tasks.md: Which task(s) relate to this area? Are any marked complete that shouldn't be?

Generate bug report: Output a structured report:

# Bug Report: [Short Title]

**Type**: [Spec gap | Spec conflict | Implementation drift | Untested flow | Dependency issue]
**Severity**: [Critical | High | Medium | Low]
**Feature**: [Feature name/branch]
**Reported**: [DATE]

## Description
[User's bug description, clarified and structured]

## Artifact Traceability

### spec.md
- **Affected user story**: [Story N — title]
- **Affected requirements**: [List specific requirements]
- **Gap identified**: [What is missing or wrong in the spec]

### plan.md
- **Affected sections**: [List plan sections]
- **Impact**: [What needs to change in the plan]

### tasks.md
- **Affected tasks**: [Task IDs and descriptions]
- **False completions**: [Tasks marked done that need reopening]
- **Missing tasks**: [New tasks needed to fix the bug]

## Root Cause Analysis
[Why this bug exists — was it a spec oversight, changed requirement, or implementation error?]

## Recommended Fix
1. Run `/speckit.bugfix.patch` to update spec artifacts
2. Run `/speckit.bugfix.verify` to confirm consistency
3. Resume `/speckit.implement` to apply the code fix

Save report: Write the bug report to specs/{feature}/bugs/BUG-{NNN}.md where {NNN} is the next sequential bug number. Create the bugs/ directory if it does not exist.
Report: Output the bug report and suggest next steps.

Rules

Always trace to artifacts — every bug must map to at least one spec section
Never modify spec artifacts — this command only reports, use /speckit.bugfix.patch to make changes
Sequential numbering — bug reports are numbered BUG-001, BUG-002, etc.
Classify accurately — distinguish between spec gaps (missing requirements) and implementation drift (code doesn't match spec)
Be specific — reference exact user story numbers, requirement text, and task IDs

Install speckit.bugfix.report 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.

# Report Bug Capture a bug discovered during implementation and trace it back to the relevant specification artifacts. Produces a structured bug report that maps the issue to spec requirements, plan sections, and tasks. ## User Input ```text {{arguments}} ``` You **MUST** consider the user input before proceeding (if not empty). The user describes the bug — what went wrong, error messages, unexpected behavior, or a gap discovered during implementation. ## Prerequisites 1. Verify a spec-kit project exists by checking for `.specify/` directory 2. Locate the current feature's spec directory (by branch name or most recently modified) 3. Verify at least `spec.md` exists ## Outline 1. **Load artifacts**: Read from the current feature directory: - **Required**: `spec.md` (the specification) - **Optional**: `plan.md`, `tasks.md`, `research.md`, `data-model.md` 2. **Analyze the bug**: From the user's description, classify the bug: | Bug Type | Description | Example | |----------|-------------|---------| | Spec gap | Requirement missing from spec | Auth flow doesn't handle expired tokens | | Spec conflict | Two requirements contradict | "Must be stateless" vs "Must track sessions" | | Implementation drift | Code diverges from spec | Spec says REST, code uses GraphQL | | Untested flow | Edge case not covered in success criteria | Concurrent user updates not handled | | Dependency issue | External dependency behaves differently than assumed | API response format changed | 3. **Trace to artifacts**: Map the bug to specific sections in each artifact: - **spec.md**: Which user story, requirement, or success criterion is affected? - **plan.md**: Which plan section covers this area? - **tasks.md**: Which task(s) relate to this area? Are any marked complete that shouldn't be? 4. **Generate bug report**: Output a structured report: ```markdown # Bug Report: [Short Title] **Type**: [Spec gap | Spec conflict | Implementation drift | Untested flow | Dependency issue] **Severity**: [Critical | High | Medium | Low] **Feature**: [Feature name/branch] **Reported**: [DATE] ## Description [User's bug description, clarified and structured] ## Artifact Traceability ### spec.md - **Affected user story**: [Story N — title] - **Affected requirements**: [List specific requirements] - **Gap identified**: [What is missing or wrong in the spec] ### plan.md - **Affected sections**: [List plan sections] - **Impact**: [What needs to change in the plan] ### tasks.md - **Affected tasks**: [Task IDs and descriptions] - **False completions**: [Tasks marked done that need reopening] - **Missing tasks**: [New tasks needed to fix the bug] ## Root Cause Analysis [Why this bug exists — was it a spec oversight, changed requirement, or implementation error?] ## Recommended Fix 1. Run `/speckit.bugfix.patch` to update spec artifacts 2. Run `/speckit.bugfix.verify` to confirm consistency 3. Resume `/speckit.implement` to apply the code fix ``` 5. **Save report**: Write the bug report to `specs/{feature}/bugs/BUG-{NNN}.md` where `{NNN}` is the next sequential bug number. Create the `bugs/` directory if it does not exist. 6. **Report**: Output the bug report and suggest next steps. ## Rules - **Always trace to artifacts** — every bug must map to at least one spec section - **Never modify spec artifacts** — this command only reports, use `/speckit.bugfix.patch` to make changes - **Sequential numbering** — bug reports are numbered BUG-001, BUG-002, etc. - **Classify accurately** — distinguish between spec gaps (missing requirements) and implementation drift (code doesn't match spec) - **Be specific** — reference exact user story numbers, requirement text, and task IDs

{ "prompt": "\n\n# Report Bug\n\nCapture a bug discovered during implementation and trace it back to the relevant specification artifacts. Produces a structured bug report that maps the issue to spec requirements, plan sections, and tasks.\n\n## User Input\n\n```text\n{{arguments}}\n```\n\nYou **MUST** consider the user input before proceeding (if not empty). The user describes the bug — what went wrong, error messages, unexpected behavior, or a gap discovered during implementation.\n\n## Prerequisites\n\n1. Verify a spec-kit project exists by checking for `.specify/` directory\n2. Locate the current feature's spec directory (by branch name or most recently modified)\n3. Verify at least `spec.md` exists\n\n## Outline\n\n1. **Load artifacts**: Read from the current feature directory:\n - **Required**: `spec.md` (the specification)\n - **Optional**: `plan.md`, `tasks.md`, `research.md`, `data-model.md`\n\n2. **Analyze the bug**: From the user's description, classify the bug:\n\n | Bug Type | Description | Example |\n |----------|-------------|---------|\n | Spec gap | Requirement missing from spec | Auth flow doesn't handle expired tokens |\n | Spec conflict | Two requirements contradict | \"Must be stateless\" vs \"Must track sessions\" |\n | Implementation drift | Code diverges from spec | Spec says REST, code uses GraphQL |\n | Untested flow | Edge case not covered in success criteria | Concurrent user updates not handled |\n | Dependency issue | External dependency behaves differently than assumed | API response format changed |\n\n3. **Trace to artifacts**: Map the bug to specific sections in each artifact:\n - **spec.md**: Which user story, requirement, or success criterion is affected?\n - **plan.md**: Which plan section covers this area?\n - **tasks.md**: Which task(s) relate to this area? Are any marked complete that shouldn't be?\n\n4. **Generate bug report**: Output a structured report:\n\n ```markdown\n # Bug Report: [Short Title]\n\n **Type**: [Spec gap | Spec conflict | Implementation drift | Untested flow | Dependency issue]\n **Severity**: [Critical | High | Medium | Low]\n **Feature**: [Feature name/branch]\n **Reported**: [DATE]\n\n ## Description\n [User's bug description, clarified and structured]\n\n ## Artifact Traceability\n\n ### spec.md\n - **Affected user story**: [Story N — title]\n - **Affected requirements**: [List specific requirements]\n - **Gap identified**: [What is missing or wrong in the spec]\n\n ### plan.md\n - **Affected sections**: [List plan sections]\n - **Impact**: [What needs to change in the plan]\n\n ### tasks.md\n - **Affected tasks**: [Task IDs and descriptions]\n - **False completions**: [Tasks marked done that need reopening]\n - **Missing tasks**: [New tasks needed to fix the bug]\n\n ## Root Cause Analysis\n [Why this bug exists — was it a spec oversight, changed requirement, or implementation error?]\n\n ## Recommended Fix\n 1. Run `/speckit.bugfix.patch` to update spec artifacts\n 2. Run `/speckit.bugfix.verify` to confirm consistency\n 3. Resume `/speckit.implement` to apply the code fix\n ```\n\n5. **Save report**: Write the bug report to `specs/{feature}/bugs/BUG-{NNN}.md` where `{NNN}` is the next sequential bug number. Create the `bugs/` directory if it does not exist.\n\n6. **Report**: Output the bug report and suggest next steps.\n\n## Rules\n\n- **Always trace to artifacts** — every bug must map to at least one spec section\n- **Never modify spec artifacts** — this command only reports, use `/speckit.bugfix.patch` to make changes\n- **Sequential numbering** — bug reports are numbered BUG-001, BUG-002, etc.\n- **Classify accurately** — distinguish between spec gaps (missing requirements) and implementation drift (code doesn't match spec)\n- **Be specific** — reference exact user story numbers, requirement text, and task IDs", "variables": [ "arguments" ], "notes": "Capture a bug and trace it back to the relevant spec, plan, and task artifacts", "metadata": { "source": { "provider": "github-windsurf-workflows", "repository": "https://github.com/eitatech/gatomia-vscode", "path": ".windsurf/workflows/speckit.bugfix.report.md", "ref": "081a9aadc7c7680b5b2b4f728042dc2a9f7e8dcc", "url": "https://github.com/eitatech/gatomia-vscode/blob/081a9aadc7c7680b5b2b4f728042dc2a9f7e8dcc/.windsurf/workflows/speckit.bugfix.report.md", "key": "eitatech/gatomia-vscode/.windsurf/workflows/speckit.bugfix.report.md" } } }

speckit.bugfix.report

About

Report Bug

User Input

Prerequisites

Outline

Rules

Install speckit.bugfix.report 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