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.

theplant.workflow-improvement - Prompt

Name: theplant.workflow-improvement
Author: theplant

Prompt file imported from theplant/speckit-extension (.windsurf/workflows/theplant.workflow-improvement.md). Fill in {{arguments}} before use. Copyright stays with the author.

User Input

{{arguments}}

You MUST consider the user input before proceeding (if not empty).

Goal

Analyze conversation issues and update workflows with generalized learnings.

How to Execute This Workflow

⚠️ MANDATORY: AI MUST run the workflow-runner command below and follow its output.

DO NOT read the Steps section below and execute them manually. The runner handles:

Step sequencing and state tracking
Nested workflow execution
AI task delegation with proper context

deno run -A https://raw.githubusercontent.com/theplant/workflow-runner/HEAD/run.ts theplant.workflow-improvement

Run this command, then follow the runner's instructions. The runner will tell you what to do next.

Steps

Step 1: Rules and Issue Identification

IMPORTANT: Read and follow ALL rules in this step before proceeding.

Critical Rules for Workflow Updates

ALL rules MUST be in Step 1 - When creating or updating workflows, put all critical rules at the beginning of Step 1. Text before the Steps section is NOT read when workflows are nested-executed.
Use generic names - Use MyEntity, myField NOT project-specific names like User, Task.
Use conventional paths - Use src/mocks/handlers.ts NOT absolute paths like /Users/john/projects/....
Focus on principles - Document the underlying principle, not the specific instance.
Include problem AND solution - Always show both the problem pattern and the solution.
Avoid duplication - Check existing workflows before adding new content.

Issue Identification

Why: Systematic issue identification ensures no learnings are lost. Each issue becomes a potential workflow improvement.

Analyze the current conversation and document:

## Issues Identified

### Issue 1: [Brief description]
- **What happened**: [Description]
- **Root cause**: [Why it happened]
- **Solution applied**: [How it was fixed]
- **Generalized learning**: [What to document]
- **Target workflow**: [Which theplant.*.md to update]

### Issue 2: ...

Why: Categorization ensures learnings go to the right workflow file, avoiding duplication and keeping workflows focused.

Issue Type	Target Workflow
API/Type mismatches, Orval hooks	`theplant.openapi-first.md`
Selector strategies, test patterns	`theplant.e2e-testing.md`
Handler patterns, data persistence	`theplant.msw-mock-backend.md`
Investigation strategies, debugging	`theplant.root-cause-tracing.md`
Data flow tracing	`theplant.system-exploration.md`
Test data patterns	`theplant.test-data-seeding.md`

Step 2: Read Target Workflow Files

Why: Reading existing content prevents duplication and helps identify the right section for new learnings.

# Read the workflow file to update
cat .windsurf/workflows/theplant.[target].md

Check:

Current content structure
Appropriate section to add learning
Whether similar guidance already exists (avoid duplication)

Step 3: Apply Updates to Workflow Files

Why: Applying updates immediately captures learnings while context is fresh.

Edit the target workflow files with the generalized learnings.

If Needed, Create New Workflow

If learning represents a new discipline, create theplant.[discipline-name].md:

---
description: [One-line description]
---

## User Input

```text
{{arguments}}

You MUST consider the user input before proceeding (if not empty).

Goal

[What this workflow achieves]

Steps

Step 1: [First deterministic file change]

[Specific file to create/modify with exact content]

Step 2: [Next file change]

...

Step N: [Verification]

[How to verify the workflow worked]


**New Workflow Criteria:**
- Doesn't fit naturally into existing workflows
- Addresses recurring pattern across projects
- Has enough depth for its own file
- Follows naming: `theplant.[discipline-name].md`

Install theplant.workflow-improvement 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.

## User Input ```text {{arguments}} ``` You **MUST** consider the user input before proceeding (if not empty). ## Goal Analyze conversation issues and update workflows with generalized learnings. ## How to Execute This Workflow **⚠️ MANDATORY: AI MUST run the workflow-runner command below and follow its output.** **DO NOT read the Steps section below and execute them manually.** The runner handles: - Step sequencing and state tracking - Nested workflow execution - AI task delegation with proper context ```bash deno run -A https://raw.githubusercontent.com/theplant/workflow-runner/HEAD/run.ts theplant.workflow-improvement ``` Run this command, then follow the runner's instructions. The runner will tell you what to do next. ## Steps ### Step 1: Rules and Issue Identification **IMPORTANT: Read and follow ALL rules in this step before proceeding.** #### Critical Rules for Workflow Updates 1. **ALL rules MUST be in Step 1** - When creating or updating workflows, put all critical rules at the beginning of Step 1. Text before the Steps section is NOT read when workflows are nested-executed. 2. **Use generic names** - Use `MyEntity`, `myField` NOT project-specific names like `User`, `Task`. 3. **Use conventional paths** - Use `src/mocks/handlers.ts` NOT absolute paths like `/Users/john/projects/...`. 4. **Focus on principles** - Document the underlying principle, not the specific instance. 5. **Include problem AND solution** - Always show both the problem pattern and the solution. 6. **Avoid duplication** - Check existing workflows before adding new content. #### Issue Identification **Why:** Systematic issue identification ensures no learnings are lost. Each issue becomes a potential workflow improvement. Analyze the current conversation and document: ```markdown ## Issues Identified ### Issue 1: [Brief description] - **What happened**: [Description] - **Root cause**: [Why it happened] - **Solution applied**: [How it was fixed] - **Generalized learning**: [What to document] - **Target workflow**: [Which theplant.*.md to update] ### Issue 2: ... ``` **Why:** Categorization ensures learnings go to the right workflow file, avoiding duplication and keeping workflows focused. | Issue Type | Target Workflow | |------------|-----------------| | API/Type mismatches, Orval hooks | `theplant.openapi-first.md` | | Selector strategies, test patterns | `theplant.e2e-testing.md` | | Handler patterns, data persistence | `theplant.msw-mock-backend.md` | | Investigation strategies, debugging | `theplant.root-cause-tracing.md` | | Data flow tracing | `theplant.system-exploration.md` | | Test data patterns | `theplant.test-data-seeding.md` | ### Step 2: Read Target Workflow Files **Why:** Reading existing content prevents duplication and helps identify the right section for new learnings. ```bash # Read the workflow file to update cat .windsurf/workflows/theplant.[target].md ``` Check: 1. Current content structure 2. Appropriate section to add learning 3. Whether similar guidance already exists (avoid duplication) ### Step 3: Apply Updates to Workflow Files **Why:** Applying updates immediately captures learnings while context is fresh. Edit the target workflow files with the generalized learnings. If Needed, Create New Workflow If learning represents a new discipline, create `theplant.[discipline-name].md`: ```markdown --- description: [One-line description] --- ## User Input ```text {{arguments}} ``` You **MUST** consider the user input before proceeding (if not empty). ## Goal [What this workflow achieves] ## Steps ### Step 1: [First deterministic file change] [Specific file to create/modify with exact content] ### Step 2: [Next file change] ... ### Step N: [Verification] [How to verify the workflow worked] ``` **New Workflow Criteria:** - Doesn't fit naturally into existing workflows - Addresses recurring pattern across projects - Has enough depth for its own file - Follows naming: `theplant.[discipline-name].md`

{ "prompt": "## User Input\n\n```text\n{{arguments}}\n```\n\nYou **MUST** consider the user input before proceeding (if not empty).\n\n## Goal\n\nAnalyze conversation issues and update workflows with generalized learnings.\n\n## How to Execute This Workflow\n\n**⚠️ MANDATORY: AI MUST run the workflow-runner command below and follow its output.**\n\n**DO NOT read the Steps section below and execute them manually.** The runner handles:\n- Step sequencing and state tracking\n- Nested workflow execution\n- AI task delegation with proper context\n\n```bash\ndeno run -A https://raw.githubusercontent.com/theplant/workflow-runner/HEAD/run.ts theplant.workflow-improvement\n```\n\nRun this command, then follow the runner's instructions. The runner will tell you what to do next.\n\n\n## Steps\n\n### Step 1: Rules and Issue Identification\n\n**IMPORTANT: Read and follow ALL rules in this step before proceeding.**\n\n#### Critical Rules for Workflow Updates\n\n1. **ALL rules MUST be in Step 1** - When creating or updating workflows, put all critical rules at the beginning of Step 1. Text before the Steps section is NOT read when workflows are nested-executed.\n\n2. **Use generic names** - Use `MyEntity`, `myField` NOT project-specific names like `User`, `Task`.\n\n3. **Use conventional paths** - Use `src/mocks/handlers.ts` NOT absolute paths like `/Users/john/projects/...`.\n\n4. **Focus on principles** - Document the underlying principle, not the specific instance.\n\n5. **Include problem AND solution** - Always show both the problem pattern and the solution.\n\n6. **Avoid duplication** - Check existing workflows before adding new content.\n\n#### Issue Identification\n\n**Why:** Systematic issue identification ensures no learnings are lost. Each issue becomes a potential workflow improvement.\n\nAnalyze the current conversation and document:\n\n```markdown\n## Issues Identified\n\n### Issue 1: [Brief description]\n- **What happened**: [Description]\n- **Root cause**: [Why it happened]\n- **Solution applied**: [How it was fixed]\n- **Generalized learning**: [What to document]\n- **Target workflow**: [Which theplant.*.md to update]\n\n### Issue 2: ...\n```\n\n**Why:** Categorization ensures learnings go to the right workflow file, avoiding duplication and keeping workflows focused.\n\n| Issue Type | Target Workflow |\n|------------|-----------------|\n| API/Type mismatches, Orval hooks | `theplant.openapi-first.md` |\n| Selector strategies, test patterns | `theplant.e2e-testing.md` |\n| Handler patterns, data persistence | `theplant.msw-mock-backend.md` |\n| Investigation strategies, debugging | `theplant.root-cause-tracing.md` |\n| Data flow tracing | `theplant.system-exploration.md` |\n| Test data patterns | `theplant.test-data-seeding.md` |\n\n### Step 2: Read Target Workflow Files\n\n**Why:** Reading existing content prevents duplication and helps identify the right section for new learnings.\n\n```bash\n# Read the workflow file to update\ncat .windsurf/workflows/theplant.[target].md\n```\n\nCheck:\n1. Current content structure\n2. Appropriate section to add learning\n3. Whether similar guidance already exists (avoid duplication)\n\n### Step 3: Apply Updates to Workflow Files\n\n**Why:** Applying updates immediately captures learnings while context is fresh.\n\nEdit the target workflow files with the generalized learnings.\n\nIf Needed, Create New Workflow\n\nIf learning represents a new discipline, create `theplant.[discipline-name].md`:\n\n```markdown\n---\ndescription: [One-line description]\n---\n\n## User Input\n\n```text\n{{arguments}}\n```\n\nYou **MUST** consider the user input before proceeding (if not empty).\n\n## Goal\n\n[What this workflow achieves]\n\n## Steps\n\n### Step 1: [First deterministic file change]\n\n[Specific file to create/modify with exact content]\n\n### Step 2: [Next file change]\n\n...\n\n### Step N: [Verification]\n\n[How to verify the workflow worked]\n```\n\n**New Workflow Criteria:**\n- Doesn't fit naturally into existing workflows\n- Addresses recurring pattern across projects\n- Has enough depth for its own file\n- Follows naming: `theplant.[discipline-name].md`", "variables": [ "arguments" ], "notes": "Summarize conversation issues and blockers, then improve existing ThePlant workflows or create new ones with generalized learnings to prevent future problems.", "metadata": { "source": { "provider": "github-windsurf-workflows", "repository": "https://github.com/theplant/speckit-extension", "path": ".windsurf/workflows/theplant.workflow-improvement.md", "ref": "665c5bb05e2ec9bfca4942647531e4ff0ddf3f44", "url": "https://github.com/theplant/speckit-extension/blob/665c5bb05e2ec9bfca4942647531e4ff0ddf3f44/.windsurf/workflows/theplant.workflow-improvement.md", "key": "theplant/speckit-extension/.windsurf/workflows/theplant.workflow-improvement.md" } } }

theplant.workflow-improvement

About

User Input

Goal

How to Execute This Workflow

Steps

Step 1: Rules and Issue Identification

Critical Rules for Workflow Updates

Issue Identification

Step 2: Read Target Workflow Files

Step 3: Apply Updates to Workflow Files

Goal

Steps

Step 1: [First deterministic file change]

Step 2: [Next file change]

Step N: [Verification]

Install theplant.workflow-improvement 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