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.

fix-issue - Prompt - OpenSmartRoute

Name: fix-issue
Author: manhthien2005

Prompt file imported from manhthien2005/Meep (.windsurf/workflows/fix-issue.md). Copyright stays with the author.

/fix-issue — Targeted Issue Resolution

End-to-end fix for a specific issue: GitHub issue, Crashlytics report, user complaint, or a clear bug with reproduction steps.

Pre-flight

Invoke skills: systematic-debugging (primary), tdd, karpathy-guidelines.
Get issue details:
- Link / ID / description of the issue.
- Repro steps (who? doing what? expected vs actual?).
- Stack trace / error log if available.
- Affected version / platform / device.
New branch:
```
git checkout -b fix/<short-description>
```

Step 1: Understand the issue

1.1 Read carefully

Read the full issue description, comments, related issues.
Read the error message / stack trace line by line.
Identify affected component(s): UI? data layer? rule? Function?

1.2 Reproduce locally

Have you reproduced the issue on your machine?
If you can't reproduce → gather more info before attempting a fix:
- User device model, OS version.
- Account state (logged in? friend list?).
- Network conditions.
- App version, build flavor.

DO NOT fix an issue you can't reproduce, unless:

Stack trace + logs clearly identify the root cause.
The user has verified reproduction and confirmed.

Step 2: Root cause analysis

→ Apply skill systematic-debugging Phases 1-3 (read errors carefully → reproduce → check recent changes → trace data flow → form hypothesis).

Meep-specific entry points (which layer to suspect first):

git log -n 20 --oneline -- <affected files>
git blame <file> | grep <line>

Symptom	First check
Crashlytics: `setState() after dispose`	Riverpod migration vs `mounted` guard
Firestore query empty in prod, OK in emulator	Rules → index → field-name typo
FCM not delivered	Token registration → topic → payload → fg/bg state
Auth token expired loop	Refresh handler in `AuthRepository` boundary

Step 3: Plan a minimal fix

Karpathy guideline: surgical changes.

Identify the minimal change to address the root cause.
DON'T bundle:
- Refactors of unrelated files "while I'm here".
- "While I'm here" cleanup.
- Other bug fixes opportunistically.
Consider side effects: will this fix break old tests / other features?

If small (≤ 20 lines): implement directly. If big (multi-file, architectural): consider running mini /spec or discussing with the user first.

Step 4: Implement (TDD)

→ Apply skill tdd "Bug fix → reproduction test" section: write failing test that reproduces → verify FAIL with the right symptom → minimal fix → verify PASS → revert fix → verify FAIL again (proof) → restore → verify PASS → commit.

Name the test regression: <issue title> (#<id>) so it's traceable later. Without the revert step (proof the test catches the bug), the test might pass for the wrong reason.

Step 5: Verify the fix end-to-end

Beyond unit tests:

Mobile fix

Run the app on a real device (not just the simulator if device-specific).
Repro the original steps → confirm bug gone.
Smoke-test related features for no regression.

BE / Functions fix

Deploy to emulator → run integration tests.
Check logs have no new errors.
Test with edge cases from the original issue.

Apply skill `verification-before-completion`

Don't claim "fixed" until:

✅ Unit tests pass.
✅ Original reproduction steps → bug gone.
✅ Full test suite passes.
✅ Lint clean.

Step 6: Commit

Conventional Commits with the issue reference:

git add <files>
git commit -m "fix(<scope>): <description>

Root cause: <short — what was wrong>
Fix: <approach>
Test: regression test in <test file>

Closes #<issue-id>"

Step 7: PR / merge

Self-review first

Apply workflow /review:

git diff develop...HEAD
flutter analyze
flutter test

Open a PR (if your workflow uses PRs)

PR description template:

## Issue
Closes #<id>

## Root cause
<1-2 sentences>

## Fix
<approach + why this approach>

## Test
- Regression test: `<test file>`
- Manual repro: <steps + expected>

## Verification
- [ ] `flutter test` passes
- [ ] `flutter analyze` clean
- [ ] Manual repro confirmed bug gone
- [ ] Smoke-tested related features

Step 8: Post-merge

Confirm the fix deployed successfully (if CI/CD triggered).
Monitor Crashlytics / logs for 24h to spot regressions.
Close the issue with a comment confirming the fix is verified.

When the issue isn't a bug

Sometimes "issue" is actually:

Feature request in disguise → push back, suggest creating a spec via /spec.
User misunderstanding → reply explaining expected behavior, don't change code.
Documentation gap → fix the doc, don't fix code.

Don't force-fix when it isn't a bug — clarify with the user first.

Anti-patterns

Anti-pattern	Problem
Fix without reproducing	Might fix the wrong thing
Fix multiple issues in one commit	Can't revert granularly
Skip the regression test	Bug can recur silently
Fix the symptom, not the root cause	Similar issues appear elsewhere
"While I'm here" refactor	Hard-to-review diff, scope creep
Skip verification, trust the unit test	Might be testing the wrong thing

Output

✅ Branch fix/<name> with clean commits.
✅ Regression test guarding against recurrence.
✅ Original reproduction steps → bug gone (verified).
✅ Issue closed with a link to the fix commit/PR.

Install fix-issue 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.

# /fix-issue — Targeted Issue Resolution End-to-end fix for a specific issue: GitHub issue, Crashlytics report, user complaint, or a clear bug with reproduction steps. ## Pre-flight 1. **Invoke skills:** `systematic-debugging` (primary), `tdd`, `karpathy-guidelines`. 2. **Get issue details:** - Link / ID / description of the issue. - Repro steps (who? doing what? expected vs actual?). - Stack trace / error log if available. - Affected version / platform / device. 3. **New branch:** ```bash git checkout -b fix/<short-description> ``` ## Step 1: Understand the issue ### 1.1 Read carefully - Read the full issue description, comments, related issues. - Read the error message / stack trace line by line. - Identify affected component(s): UI? data layer? rule? Function? ### 1.2 Reproduce locally - Have you reproduced the issue on your machine? - If you can't reproduce → gather more info before attempting a fix: - User device model, OS version. - Account state (logged in? friend list?). - Network conditions. - App version, build flavor. **DO NOT fix** an issue you can't reproduce, unless: - Stack trace + logs clearly identify the root cause. - The user has verified reproduction and confirmed. ## Step 2: Root cause analysis **→ Apply skill `systematic-debugging`** Phases 1-3 (read errors carefully → reproduce → check recent changes → trace data flow → form hypothesis). Meep-specific entry points (which layer to suspect first): ```bash git log -n 20 --oneline -- <affected files> git blame <file> | grep <line> ``` | Symptom | First check | |---|---| | Crashlytics: `setState() after dispose` | Riverpod migration vs `mounted` guard | | Firestore query empty in prod, OK in emulator | Rules → index → field-name typo | | FCM not delivered | Token registration → topic → payload → fg/bg state | | Auth token expired loop | Refresh handler in `AuthRepository` boundary | ## Step 3: Plan a minimal fix **Karpathy guideline: surgical changes.** - Identify the **minimal change** to address the root cause. - DON'T bundle: - Refactors of unrelated files "while I'm here". - "While I'm here" cleanup. - Other bug fixes opportunistically. - Consider side effects: will this fix break old tests / other features? If small (≤ 20 lines): implement directly. If big (multi-file, architectural): consider running mini `/spec` or discussing with the user first. ## Step 4: Implement (TDD) **→ Apply skill `tdd`** "Bug fix → reproduction test" section: write failing test that reproduces → verify FAIL with the right symptom → minimal fix → verify PASS → revert fix → verify FAIL again (proof) → restore → verify PASS → commit. Name the test `regression: <issue title> (#<id>)` so it's traceable later. Without the revert step (proof the test catches the bug), the test might pass for the wrong reason. ## Step 5: Verify the fix end-to-end Beyond unit tests: ### Mobile fix - Run the app on a real device (not just the simulator if device-specific). - Repro the original steps → confirm bug gone. - Smoke-test related features for no regression. ### BE / Functions fix - Deploy to emulator → run integration tests. - Check logs have no new errors. - Test with edge cases from the original issue. ### Apply skill `verification-before-completion` Don't claim "fixed" until: - ✅ Unit tests pass. - ✅ Original reproduction steps → bug gone. - ✅ Full test suite passes. - ✅ Lint clean. ## Step 6: Commit Conventional Commits with the issue reference: ```bash git add <files> git commit -m "fix(<scope>): <description> Root cause: <short — what was wrong> Fix: <approach> Test: regression test in <test file> Closes #<issue-id>" ``` ## Step 7: PR / merge ### Self-review first Apply workflow `/review`: ```bash git diff develop...HEAD flutter analyze flutter test ``` ### Open a PR (if your workflow uses PRs) PR description template: ```markdown ## Issue Closes #<id> ## Root cause <1-2 sentences> ## Fix <approach + why this approach> ## Test - Regression test: `<test file>` - Manual repro: <steps + expected> ## Verification - [ ] `flutter test` passes - [ ] `flutter analyze` clean - [ ] Manual repro confirmed bug gone - [ ] Smoke-tested related features ``` ## Step 8: Post-merge - Confirm the fix deployed successfully (if CI/CD triggered). - Monitor Crashlytics / logs for 24h to spot regressions. - Close the issue with a comment confirming the fix is verified. ## When the issue isn't a bug Sometimes "issue" is actually: - **Feature request in disguise** → push back, suggest creating a spec via `/spec`. - **User misunderstanding** → reply explaining expected behavior, don't change code. - **Documentation gap** → fix the doc, don't fix code. Don't force-fix when it isn't a bug — clarify with the user first. ## Anti-patterns | Anti-pattern | Problem | |---|---| | Fix without reproducing | Might fix the wrong thing | | Fix multiple issues in one commit | Can't revert granularly | | Skip the regression test | Bug can recur silently | | Fix the symptom, not the root cause | Similar issues appear elsewhere | | "While I'm here" refactor | Hard-to-review diff, scope creep | | Skip verification, trust the unit test | Might be testing the wrong thing | ## Output - ✅ Branch `fix/<name>` with clean commits. - ✅ Regression test guarding against recurrence. - ✅ Original reproduction steps → bug gone (verified). - ✅ Issue closed with a link to the fix commit/PR.

{ "prompt": "# /fix-issue — Targeted Issue Resolution\n\nEnd-to-end fix for a specific issue: GitHub issue, Crashlytics report, user complaint, or a clear bug with reproduction steps.\n\n## Pre-flight\n\n1. **Invoke skills:** `systematic-debugging` (primary), `tdd`, `karpathy-guidelines`.\n2. **Get issue details:**\n - Link / ID / description of the issue.\n - Repro steps (who? doing what? expected vs actual?).\n - Stack trace / error log if available.\n - Affected version / platform / device.\n3. **New branch:**\n ```bash\n git checkout -b fix/<short-description>\n ```\n\n## Step 1: Understand the issue\n\n### 1.1 Read carefully\n\n- Read the full issue description, comments, related issues.\n- Read the error message / stack trace line by line.\n- Identify affected component(s): UI? data layer? rule? Function?\n\n### 1.2 Reproduce locally\n\n- Have you reproduced the issue on your machine?\n- If you can't reproduce → gather more info before attempting a fix:\n - User device model, OS version.\n - Account state (logged in? friend list?).\n - Network conditions.\n - App version, build flavor.\n\n**DO NOT fix** an issue you can't reproduce, unless:\n- Stack trace + logs clearly identify the root cause.\n- The user has verified reproduction and confirmed.\n\n## Step 2: Root cause analysis\n\n**→ Apply skill `systematic-debugging`** Phases 1-3 (read errors carefully → reproduce → check recent changes → trace data flow → form hypothesis).\n\nMeep-specific entry points (which layer to suspect first):\n\n```bash\ngit log -n 20 --oneline -- <affected files>\ngit blame <file> | grep <line>\n```\n\n| Symptom | First check |\n|---|---|\n| Crashlytics: `setState() after dispose` | Riverpod migration vs `mounted` guard |\n| Firestore query empty in prod, OK in emulator | Rules → index → field-name typo |\n| FCM not delivered | Token registration → topic → payload → fg/bg state |\n| Auth token expired loop | Refresh handler in `AuthRepository` boundary |\n\n## Step 3: Plan a minimal fix\n\n**Karpathy guideline: surgical changes.**\n\n- Identify the **minimal change** to address the root cause.\n- DON'T bundle:\n - Refactors of unrelated files \"while I'm here\".\n - \"While I'm here\" cleanup.\n - Other bug fixes opportunistically.\n- Consider side effects: will this fix break old tests / other features?\n\nIf small (≤ 20 lines): implement directly.\nIf big (multi-file, architectural): consider running mini `/spec` or discussing with the user first.\n\n## Step 4: Implement (TDD)\n\n**→ Apply skill `tdd`** \"Bug fix → reproduction test\" section: write failing test that reproduces → verify FAIL with the right symptom → minimal fix → verify PASS → revert fix → verify FAIL again (proof) → restore → verify PASS → commit.\n\nName the test `regression: <issue title> (#<id>)` so it's traceable later. Without the revert step (proof the test catches the bug), the test might pass for the wrong reason.\n\n## Step 5: Verify the fix end-to-end\n\nBeyond unit tests:\n\n### Mobile fix\n\n- Run the app on a real device (not just the simulator if device-specific).\n- Repro the original steps → confirm bug gone.\n- Smoke-test related features for no regression.\n\n### BE / Functions fix\n\n- Deploy to emulator → run integration tests.\n- Check logs have no new errors.\n- Test with edge cases from the original issue.\n\n### Apply skill `verification-before-completion`\n\nDon't claim \"fixed\" until:\n- ✅ Unit tests pass.\n- ✅ Original reproduction steps → bug gone.\n- ✅ Full test suite passes.\n- ✅ Lint clean.\n\n## Step 6: Commit\n\nConventional Commits with the issue reference:\n\n```bash\ngit add <files>\ngit commit -m \"fix(<scope>): <description>\n\nRoot cause: <short — what was wrong>\nFix: <approach>\nTest: regression test in <test file>\n\nCloses #<issue-id>\"\n```\n\n## Step 7: PR / merge\n\n### Self-review first\n\nApply workflow `/review`:\n\n```bash\ngit diff develop...HEAD\nflutter analyze\nflutter test\n```\n\n### Open a PR (if your workflow uses PRs)\n\nPR description template:\n\n```markdown\n## Issue\nCloses #<id>\n\n## Root cause\n<1-2 sentences>\n\n## Fix\n<approach + why this approach>\n\n## Test\n- Regression test: `<test file>`\n- Manual repro: <steps + expected>\n\n## Verification\n- [ ] `flutter test` passes\n- [ ] `flutter analyze` clean\n- [ ] Manual repro confirmed bug gone\n- [ ] Smoke-tested related features\n```\n\n## Step 8: Post-merge\n\n- Confirm the fix deployed successfully (if CI/CD triggered).\n- Monitor Crashlytics / logs for 24h to spot regressions.\n- Close the issue with a comment confirming the fix is verified.\n\n## When the issue isn't a bug\n\nSometimes \"issue\" is actually:\n\n- **Feature request in disguise** → push back, suggest creating a spec via `/spec`.\n- **User misunderstanding** → reply explaining expected behavior, don't change code.\n- **Documentation gap** → fix the doc, don't fix code.\n\nDon't force-fix when it isn't a bug — clarify with the user first.\n\n## Anti-patterns\n\n| Anti-pattern | Problem |\n|---|---|\n| Fix without reproducing | Might fix the wrong thing |\n| Fix multiple issues in one commit | Can't revert granularly |\n| Skip the regression test | Bug can recur silently |\n| Fix the symptom, not the root cause | Similar issues appear elsewhere |\n| \"While I'm here\" refactor | Hard-to-review diff, scope creep |\n| Skip verification, trust the unit test | Might be testing the wrong thing |\n\n## Output\n\n- ✅ Branch `fix/<name>` with clean commits.\n- ✅ Regression test guarding against recurrence.\n- ✅ Original reproduction steps → bug gone (verified).\n- ✅ Issue closed with a link to the fix commit/PR.", "variables": [], "notes": "Fix a specific issue (link/description/Crashlytics report) end-to-end — analyze, plan minimal fix, implement, test.", "metadata": { "source": { "provider": "github-windsurf-workflows", "repository": "https://github.com/manhthien2005/Meep", "path": ".windsurf/workflows/fix-issue.md", "ref": "cbdc59e7eb9d1405154b910ec9ca4376ab3465ac", "url": "https://github.com/manhthien2005/Meep/blob/cbdc59e7eb9d1405154b910ec9ca4376ab3465ac/.windsurf/workflows/fix-issue.md", "key": "manhthien2005/Meep/.windsurf/workflows/fix-issue.md" } } }

fix-issue

About

/fix-issue — Targeted Issue Resolution

Pre-flight

Step 1: Understand the issue

1.1 Read carefully

1.2 Reproduce locally

Step 2: Root cause analysis

Step 3: Plan a minimal fix

Step 4: Implement (TDD)

Step 5: Verify the fix end-to-end

Mobile fix

BE / Functions fix

Apply skill `verification-before-completion`

Step 6: Commit

Step 7: PR / merge

Self-review first

Open a PR (if your workflow uses PRs)

Step 8: Post-merge

When the issue isn't a bug

Anti-patterns

Output

Install fix-issue 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

About

/fix-issue — Targeted Issue Resolution

Pre-flight

Step 1: Understand the issue

1.1 Read carefully

1.2 Reproduce locally

Step 2: Root cause analysis

Step 3: Plan a minimal fix

Step 4: Implement (TDD)

Step 5: Verify the fix end-to-end

Mobile fix

BE / Functions fix

Apply skill verification-before-completion

Step 6: Commit

Step 7: PR / merge

Self-review first

Open a PR (if your workflow uses PRs)

Step 8: Post-merge

When the issue isn't a bug

Anti-patterns

Output

Install fix-issue 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

Apply skill `verification-before-completion`