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.

plan-story - Prompt - OpenSmartRoute

Name: plan-story
Author: VEaswaran

Prompt file imported from VEaswaran/MonoFluxDemoApplication (.windsurf/workflows/plan-story.md). Copyright stays with the author.

/plan-story

Trigger: /plan-story Description: Plan a user story — break it into tasks, identify affected Spring Boot components, scaffold branches and directories.

Pre-conditions (both must be met):

/story-intake must show status ✅ READY TO DEVELOP

/architecture-review must show status ✅ Architecture Confirmed with a signed ADR

If either has not been run, run them now. No story is planned without both gates.

Steps

0. Verify Pre-Conditions

# Check story intake completed
ls story-intake-report-[STORY-ID].md 2>/dev/null || echo "MISSING — run /story-intake"

# Check architecture review completed
ls docs/adr/ADR-[STORY-ID]-*.md 2>/dev/null || echo "MISSING — run /architecture-review"

If either file is missing:

🔴 STOP — Required pre-conditions not met for [STORY-ID].
  Missing: [story-intake-report / ADR file]
  Run the missing workflow first, then return to /plan-story.

1. Load Story Details from Intake Report and ADR

Read both source documents:

From story-intake-report-[STORY-ID].md:

Story ID, title, and confirmed description
All confirmed ACs (only those marked ✅ or confirmed in-scope by PO)
Technical dependency findings (what exists vs what must be created)
Feature flag decision from the intake report

From docs/adr/ADR-[STORY-ID]-*.md:

Confirmed communication pattern (REST / gRPC / GraphQL / Kafka / Hybrid)
Reactive vs blocking decision (WebFlux / MVC)
Resilience patterns required (CB / Bulkhead / Rate Limiter)
DB access pattern (JPA / R2DBC)
Implementation constraints checklist — these become mandatory tasks

Do not re-ask for any information already present in either document.

2. Decompose Story into Tasks

Break the story into clearly scoped tasks:

Identify API layer changes (Controller, DTO, Request/Response models)
Identify Service layer changes (business logic, orchestration)
Identify Repository/persistence changes (JPA entity, queries)
Identify Integration points (Kafka events, external HTTP clients via FeignClient)
Identify Spock test files to create or update (unit + integration)
Identify Docker Compose changes needed (new env vars, new services, health checks)
Identify Feature flag requirement — does this story add new observable behaviour? Answer YES if any of the following are introduced:
- A new API endpoint
- A new Kafka producer or consumer
- A change to an existing business rule or algorithm
- An integration with a new external service Answer NO only for pure refactoring, test-only changes, or config changes.

Output a task checklist in this format:

## [PROJ-123] Story Title

### Acceptance Criteria
- [ ] AC1
- [ ] AC2

### Architecture (from ADR)
- Communication: [REST/gRPC/GraphQL/Kafka/Hybrid]
- Reactive:      [WebFlux Mono/Flux / Spring MVC]
- Resilience:    [Circuit Breaker / Bulkhead / Rate Limiter / Retry]
- DB access:     [JPA / R2DBC]
- Async:         [Kafka / synchronous]

### Tasks
- [ ] PROJ-123-1: Scaffold [WebFlux/MVC] controller with [REST/gRPC/GraphQL] endpoint
- [ ] PROJ-123-2: Implement service logic using [Mono/Flux / blocking]
- [ ] PROJ-123-3: Add/update repository method using [JPA / R2DBC]
- [ ] PROJ-123-4: Configure Resilience4j [CB / Bulkhead] for [dependency name]
- [ ] PROJ-123-5: Configure Kafka producer/consumer if async pattern selected
- [ ] PROJ-123-6: Write Spock specs — happy path, CB open, fallback, flag ON/OFF
- [ ] PROJ-123-7: Verify JaCoCo coverage threshold (min 80%)
- [ ] PROJ-123-8: Update docker-compose.yml if required
- [ ] PROJ-123-9: Feature flag — [YES: register flag + wrap impl / NO: not required]

### ADR Constraints (must not be violated during implementation)
- [ ] [Constraint 1 from ADR — e.g. no blocking operators on WebFlux thread]
- [ ] [Constraint 2 from ADR — e.g. all FeignClient calls behind @CircuitBreaker]
- [ ] [Constraint 3 from ADR — e.g. POST returns 202 Accepted, processing via Kafka]

### Feature Flag Decision
- Requires flag: YES / NO
- Proposed flag key: feature.[domain].[story-id]-[short-description]
- Flag OFF behaviour: [description]

### Affected Modules
- service: [module name]
- packages: [list key packages]

### Out of Scope
- [anything explicitly excluded]

3. Create Feature Branch

git checkout main && git pull
git checkout -b feature/PROJ-123-short-description

4. Scaffold Test Directory

Ensure the Spock test directories exist for this module:

mkdir -p src/test/groovy/[package]/service
mkdir -p src/test/groovy/[package]/controller
mkdir -p src/test/groovy/[package]/repository

5. Summary

Print the full task checklist and confirm with the user before proceeding.

If Feature Flag Decision = YES → Next step: run /feature-flag before /review-story If Feature Flag Decision = NO → Next step: run /review-story

Install plan-story 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.

# /plan-story **Trigger:** `/plan-story` **Description:** Plan a user story — break it into tasks, identify affected Spring Boot components, scaffold branches and directories. > **Pre-conditions (both must be met):** > 1. `/story-intake` must show status `✅ READY TO DEVELOP` > 2. `/architecture-review` must show status `✅ Architecture Confirmed` with a signed ADR > > If either has not been run, run them now. No story is planned without both gates. --- ## Steps ### 0. Verify Pre-Conditions ```bash # Check story intake completed ls story-intake-report-[STORY-ID].md 2>/dev/null || echo "MISSING — run /story-intake" # Check architecture review completed ls docs/adr/ADR-[STORY-ID]-*.md 2>/dev/null || echo "MISSING — run /architecture-review" ``` If either file is missing: ``` 🔴 STOP — Required pre-conditions not met for [STORY-ID]. Missing: [story-intake-report / ADR file] Run the missing workflow first, then return to /plan-story. ``` ### 1. Load Story Details from Intake Report and ADR Read both source documents: **From `story-intake-report-[STORY-ID].md`:** - Story ID, title, and confirmed description - All confirmed ACs (only those marked ✅ or confirmed in-scope by PO) - Technical dependency findings (what exists vs what must be created) - Feature flag decision from the intake report **From `docs/adr/ADR-[STORY-ID]-*.md`:** - Confirmed communication pattern (REST / gRPC / GraphQL / Kafka / Hybrid) - Reactive vs blocking decision (WebFlux / MVC) - Resilience patterns required (CB / Bulkhead / Rate Limiter) - DB access pattern (JPA / R2DBC) - Implementation constraints checklist — these become mandatory tasks Do not re-ask for any information already present in either document. ### 2. Decompose Story into Tasks Break the story into clearly scoped tasks: - Identify **API layer** changes (Controller, DTO, Request/Response models) - Identify **Service layer** changes (business logic, orchestration) - Identify **Repository/persistence** changes (JPA entity, queries) - Identify **Integration points** (Kafka events, external HTTP clients via FeignClient) - Identify **Spock test files** to create or update (unit + integration) - Identify **Docker Compose** changes needed (new env vars, new services, health checks) - Identify **Feature flag requirement** — does this story add new observable behaviour? Answer YES if any of the following are introduced: - A new API endpoint - A new Kafka producer or consumer - A change to an existing business rule or algorithm - An integration with a new external service Answer NO only for pure refactoring, test-only changes, or config changes. Output a task checklist in this format: ``` ## [PROJ-123] Story Title ### Acceptance Criteria - [ ] AC1 - [ ] AC2 ### Architecture (from ADR) - Communication: [REST/gRPC/GraphQL/Kafka/Hybrid] - Reactive: [WebFlux Mono/Flux / Spring MVC] - Resilience: [Circuit Breaker / Bulkhead / Rate Limiter / Retry] - DB access: [JPA / R2DBC] - Async: [Kafka / synchronous] ### Tasks - [ ] PROJ-123-1: Scaffold [WebFlux/MVC] controller with [REST/gRPC/GraphQL] endpoint - [ ] PROJ-123-2: Implement service logic using [Mono/Flux / blocking] - [ ] PROJ-123-3: Add/update repository method using [JPA / R2DBC] - [ ] PROJ-123-4: Configure Resilience4j [CB / Bulkhead] for [dependency name] - [ ] PROJ-123-5: Configure Kafka producer/consumer if async pattern selected - [ ] PROJ-123-6: Write Spock specs — happy path, CB open, fallback, flag ON/OFF - [ ] PROJ-123-7: Verify JaCoCo coverage threshold (min 80%) - [ ] PROJ-123-8: Update docker-compose.yml if required - [ ] PROJ-123-9: Feature flag — [YES: register flag + wrap impl / NO: not required] ### ADR Constraints (must not be violated during implementation) - [ ] [Constraint 1 from ADR — e.g. no blocking operators on WebFlux thread] - [ ] [Constraint 2 from ADR — e.g. all FeignClient calls behind @CircuitBreaker] - [ ] [Constraint 3 from ADR — e.g. POST returns 202 Accepted, processing via Kafka] ### Feature Flag Decision - Requires flag: YES / NO - Proposed flag key: feature.[domain].[story-id]-[short-description] - Flag OFF behaviour: [description] ### Affected Modules - service: [module name] - packages: [list key packages] ### Out of Scope - [anything explicitly excluded] ``` ### 3. Create Feature Branch ```bash git checkout main && git pull git checkout -b feature/PROJ-123-short-description ``` ### 4. Scaffold Test Directory Ensure the Spock test directories exist for this module: ```bash mkdir -p src/test/groovy/[package]/service mkdir -p src/test/groovy/[package]/controller mkdir -p src/test/groovy/[package]/repository ``` ### 5. Summary Print the full task checklist and confirm with the user before proceeding. If **Feature Flag Decision = YES** → Next step: run `/feature-flag` before `/review-story` If **Feature Flag Decision = NO** → Next step: run `/review-story`

{ "prompt": "# /plan-story\n**Trigger:** `/plan-story`\n**Description:** Plan a user story — break it into tasks, identify affected Spring Boot components, scaffold branches and directories.\n\n> **Pre-conditions (both must be met):**\n> 1. `/story-intake` must show status `✅ READY TO DEVELOP`\n> 2. `/architecture-review` must show status `✅ Architecture Confirmed` with a signed ADR\n>\n> If either has not been run, run them now. No story is planned without both gates.\n\n---\n\n## Steps\n\n### 0. Verify Pre-Conditions\n```bash\n# Check story intake completed\nls story-intake-report-[STORY-ID].md 2>/dev/null || echo \"MISSING — run /story-intake\"\n\n# Check architecture review completed\nls docs/adr/ADR-[STORY-ID]-*.md 2>/dev/null || echo \"MISSING — run /architecture-review\"\n```\n\nIf either file is missing:\n```\n🔴 STOP — Required pre-conditions not met for [STORY-ID].\n Missing: [story-intake-report / ADR file]\n Run the missing workflow first, then return to /plan-story.\n```\n\n### 1. Load Story Details from Intake Report and ADR\nRead both source documents:\n\n**From `story-intake-report-[STORY-ID].md`:**\n- Story ID, title, and confirmed description\n- All confirmed ACs (only those marked ✅ or confirmed in-scope by PO)\n- Technical dependency findings (what exists vs what must be created)\n- Feature flag decision from the intake report\n\n**From `docs/adr/ADR-[STORY-ID]-*.md`:**\n- Confirmed communication pattern (REST / gRPC / GraphQL / Kafka / Hybrid)\n- Reactive vs blocking decision (WebFlux / MVC)\n- Resilience patterns required (CB / Bulkhead / Rate Limiter)\n- DB access pattern (JPA / R2DBC)\n- Implementation constraints checklist — these become mandatory tasks\n\nDo not re-ask for any information already present in either document.\n\n### 2. Decompose Story into Tasks\nBreak the story into clearly scoped tasks:\n- Identify **API layer** changes (Controller, DTO, Request/Response models)\n- Identify **Service layer** changes (business logic, orchestration)\n- Identify **Repository/persistence** changes (JPA entity, queries)\n- Identify **Integration points** (Kafka events, external HTTP clients via FeignClient)\n- Identify **Spock test files** to create or update (unit + integration)\n- Identify **Docker Compose** changes needed (new env vars, new services, health checks)\n- Identify **Feature flag requirement** — does this story add new observable behaviour?\n Answer YES if any of the following are introduced:\n - A new API endpoint\n - A new Kafka producer or consumer\n - A change to an existing business rule or algorithm\n - An integration with a new external service\n Answer NO only for pure refactoring, test-only changes, or config changes.\n\nOutput a task checklist in this format:\n```\n## [PROJ-123] Story Title\n\n### Acceptance Criteria\n- [ ] AC1\n- [ ] AC2\n\n### Architecture (from ADR)\n- Communication: [REST/gRPC/GraphQL/Kafka/Hybrid]\n- Reactive: [WebFlux Mono/Flux / Spring MVC]\n- Resilience: [Circuit Breaker / Bulkhead / Rate Limiter / Retry]\n- DB access: [JPA / R2DBC]\n- Async: [Kafka / synchronous]\n\n### Tasks\n- [ ] PROJ-123-1: Scaffold [WebFlux/MVC] controller with [REST/gRPC/GraphQL] endpoint\n- [ ] PROJ-123-2: Implement service logic using [Mono/Flux / blocking]\n- [ ] PROJ-123-3: Add/update repository method using [JPA / R2DBC]\n- [ ] PROJ-123-4: Configure Resilience4j [CB / Bulkhead] for [dependency name]\n- [ ] PROJ-123-5: Configure Kafka producer/consumer if async pattern selected\n- [ ] PROJ-123-6: Write Spock specs — happy path, CB open, fallback, flag ON/OFF\n- [ ] PROJ-123-7: Verify JaCoCo coverage threshold (min 80%)\n- [ ] PROJ-123-8: Update docker-compose.yml if required\n- [ ] PROJ-123-9: Feature flag — [YES: register flag + wrap impl / NO: not required]\n\n### ADR Constraints (must not be violated during implementation)\n- [ ] [Constraint 1 from ADR — e.g. no blocking operators on WebFlux thread]\n- [ ] [Constraint 2 from ADR — e.g. all FeignClient calls behind @CircuitBreaker]\n- [ ] [Constraint 3 from ADR — e.g. POST returns 202 Accepted, processing via Kafka]\n\n### Feature Flag Decision\n- Requires flag: YES / NO\n- Proposed flag key: feature.[domain].[story-id]-[short-description]\n- Flag OFF behaviour: [description]\n\n### Affected Modules\n- service: [module name]\n- packages: [list key packages]\n\n### Out of Scope\n- [anything explicitly excluded]\n```\n\n### 3. Create Feature Branch\n```bash\ngit checkout main && git pull\ngit checkout -b feature/PROJ-123-short-description\n```\n\n### 4. Scaffold Test Directory\nEnsure the Spock test directories exist for this module:\n```bash\nmkdir -p src/test/groovy/[package]/service\nmkdir -p src/test/groovy/[package]/controller\nmkdir -p src/test/groovy/[package]/repository\n```\n\n### 5. Summary\nPrint the full task checklist and confirm with the user before proceeding.\n\nIf **Feature Flag Decision = YES** → Next step: run `/feature-flag` before `/review-story`\nIf **Feature Flag Decision = NO** → Next step: run `/review-story`", "variables": [], "notes": "If either file is missing: ``` 🔴 STOP — Required pre-conditions not met for [STORY-ID]. Missing: [story-intake-report / ADR file] Run the missing workflow first, then return to /plan-story. ```", "metadata": { "source": { "provider": "github-windsurf-workflows", "repository": "https://github.com/VEaswaran/MonoFluxDemoApplication", "path": ".windsurf/workflows/plan-story.md", "ref": "0e5e342ab8a6646bcb5733598d27c7761b997a59", "url": "https://github.com/VEaswaran/MonoFluxDemoApplication/blob/0e5e342ab8a6646bcb5733598d27c7761b997a59/.windsurf/workflows/plan-story.md", "key": "VEaswaran/MonoFluxDemoApplication/.windsurf/workflows/plan-story.md" } } }

plan-story

About

/plan-story

Steps

0. Verify Pre-Conditions

1. Load Story Details from Intake Report and ADR

2. Decompose Story into Tasks

3. Create Feature Branch

4. Scaffold Test Directory

5. Summary

Install plan-story 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