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.

evolve - Prompt - OpenSmartRoute

Name: evolve
Author: joaobispo2077

Prompt file imported from joaobispo2077/env (.cursor/commands/evolve.md). Copyright stays with the author.

/evolve Command

Update existing specifications with new discoveries, changes, or refinements made during development. Keep documentation aligned with reality.

Skill: Uses sdd-evolve skill for structured spec updates.

See also: .cursor/commands/_shared/agent-manual.md for full agent protocol.

Role

Documentation evolution agent: Update existing specs with new discoveries and changes while preserving context and maintaining changelog entries.

Usage

/evolve [task-id] [change-description]

Examples:

/evolve user-auth Added password strength validation after security review
/evolve checkout-flow Discovered need for guest checkout fallback
/evolve notification-system Changed from polling to WebSocket based on performance testing

Instructions

Phase 1: Analysis

Find existing specs in specs/active/[task-id]/ (check feature-brief.md, spec.md, plan.md, tasks.md)
Read all related files to understand current state and context
Categorize the change: Discovery/Refinement (Low), Addition/Modification (Medium), Removal/Architecture (High)
Assess upgrade need: Multiple major changes → suggest /upgrade, simple discovery → continue with /evolve

Phase 2: Planning

Present evolution plan with:

Task ID and file to update
Change summary, type, and impact level
Before/after diff of relevant sections
Proposed changelog entry
Recommendation (proceed or suggest upgrade)

Wait for user approval before proceeding.

Phase 3: Execution

Update spec file preserving context, adding changelog, incrementing version, updating date
Add changelog entry (feature-brief.md uses "Changelog" table, spec.md uses "Revision History" table)
Note cross-references if change affects other documents
Update status if spec was marked "Complete"

Phase 4: Downstream Propagation

Check for stale downstream documents:

List downstream files in specs/active/[task-id]/ — check for plan.md, tasks.md, todo-list.md
Assess impact using the change category:
- Discovery/Refinement → downstream docs usually unaffected
- Addition/Modification → plan.md and tasks.md likely stale
- Removal/Architecture → all downstream docs stale

Add staleness marker to affected files (insert at top of file):

> **[STALE]** — Upstream spec updated on [DATE]. Review needed.
> Change: [Brief description] (spec.md v[VERSION])

Report affected files in the evolution summary output

Phase 5: Verification

Verify before final output:

Spec file updated, changelog added, version incremented
Context preserved, cross-references noted
Staleness markers added to affected downstream files
Read file back to confirm changes applied

Output

End response with:

✅ Spec evolved: `specs/active/[task-id]/[file]`

**Change:** [Type] | Impact: [Level] | Version: [old] → [new]
**Changelog:** | [version] | [date] | [description] | [reason] |
**Downstream impact:** [List of files marked STALE, or "None"]
**Cross-references:** [Other files that may need updates]
**Next steps:** Review spec, update stale downstream docs, or consider `/upgrade` for major changes

Change Types

Discovery (Low): Small findings → Add to constraints
Refinement (Low): Clarifying requirements → Update with specific detail
Addition (Medium): New requirement → Add, note as post-initial
Modification (Medium): Changed approach → Update, document rationale
Removal (High): Descoping → Move to out-of-scope, document reason

When to Suggest Upgrade

Suggest /upgrade when change fundamentally alters approach, multiple related changes needed, brief insufficient, or architecture needs redesign.

Troubleshooting

Multiple spec files: Ask which to update
Change conflicts: Highlight contradiction and ask if both should be updated
Missing changelog: Add changelog section to older specs

Related Commands

/brief [task-id] - Create initial brief
/upgrade [task-id] - Expand to full SDD 6.0
/refine [task-id] - Interactive refinement session
/specify [task-id] - Create detailed specification
/plan [task-id] - Update technical plan

Install evolve 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.

# /evolve Command Update existing specifications with new discoveries, changes, or refinements made during development. Keep documentation aligned with reality. **Skill:** Uses `sdd-evolve` skill for structured spec updates. **See also:** `.cursor/commands/_shared/agent-manual.md` for full agent protocol. --- ## Role **Documentation evolution agent:** Update existing specs with new discoveries and changes while preserving context and maintaining changelog entries. --- ## Usage ``` /evolve [task-id] [change-description] ``` **Examples:** - `/evolve user-auth Added password strength validation after security review` - `/evolve checkout-flow Discovered need for guest checkout fallback` - `/evolve notification-system Changed from polling to WebSocket based on performance testing` --- ## Instructions ### Phase 1: Analysis 1. **Find existing specs** in `specs/active/[task-id]/` (check feature-brief.md, spec.md, plan.md, tasks.md) 2. **Read all related files** to understand current state and context 3. **Categorize the change**: Discovery/Refinement (Low), Addition/Modification (Medium), Removal/Architecture (High) 4. **Assess upgrade need**: Multiple major changes → suggest `/upgrade`, simple discovery → continue with `/evolve` ### Phase 2: Planning Present evolution plan with: - Task ID and file to update - Change summary, type, and impact level - Before/after diff of relevant sections - Proposed changelog entry - Recommendation (proceed or suggest upgrade) **Wait for user approval before proceeding.** ### Phase 3: Execution 1. **Update spec file** preserving context, adding changelog, incrementing version, updating date 2. **Add changelog entry** (feature-brief.md uses "Changelog" table, spec.md uses "Revision History" table) 3. **Note cross-references** if change affects other documents 4. **Update status** if spec was marked "Complete" ### Phase 4: Downstream Propagation Check for stale downstream documents: 1. **List downstream files** in `specs/active/[task-id]/` — check for `plan.md`, `tasks.md`, `todo-list.md` 2. **Assess impact** using the change category: - Discovery/Refinement → downstream docs usually unaffected - Addition/Modification → `plan.md` and `tasks.md` likely stale - Removal/Architecture → all downstream docs stale 3. **Add staleness marker** to affected files (insert at top of file): ``` > **[STALE]** — Upstream spec updated on [DATE]. Review needed. > Change: [Brief description] (spec.md v[VERSION]) ``` 4. **Report affected files** in the evolution summary output ### Phase 5: Verification Verify before final output: - Spec file updated, changelog added, version incremented - Context preserved, cross-references noted - Staleness markers added to affected downstream files - **Read file back to confirm changes applied** --- ## Output End response with: ``` ✅ Spec evolved: `specs/active/[task-id]/[file]` **Change:** [Type] | Impact: [Level] | Version: [old] → [new] **Changelog:** | [version] | [date] | [description] | [reason] | **Downstream impact:** [List of files marked STALE, or "None"] **Cross-references:** [Other files that may need updates] **Next steps:** Review spec, update stale downstream docs, or consider `/upgrade` for major changes ``` --- ## Change Types - **Discovery** (Low): Small findings → Add to constraints - **Refinement** (Low): Clarifying requirements → Update with specific detail - **Addition** (Medium): New requirement → Add, note as post-initial - **Modification** (Medium): Changed approach → Update, document rationale - **Removal** (High): Descoping → Move to out-of-scope, document reason --- ## When to Suggest Upgrade Suggest `/upgrade` when change fundamentally alters approach, multiple related changes needed, brief insufficient, or architecture needs redesign. --- ## Troubleshooting - **Multiple spec files**: Ask which to update - **Change conflicts**: Highlight contradiction and ask if both should be updated - **Missing changelog**: Add changelog section to older specs --- ## Related Commands - `/brief [task-id]` - Create initial brief - `/upgrade [task-id]` - Expand to full SDD 6.0 - `/refine [task-id]` - Interactive refinement session - `/specify [task-id]` - Create detailed specification - `/plan [task-id]` - Update technical plan

{ "prompt": "# /evolve Command\n\nUpdate existing specifications with new discoveries, changes, or refinements made during development. Keep documentation aligned with reality.\n\n**Skill:** Uses `sdd-evolve` skill for structured spec updates.\n\n**See also:** `.cursor/commands/_shared/agent-manual.md` for full agent protocol.\n\n---\n\n## Role\n\n**Documentation evolution agent:** Update existing specs with new discoveries and changes while preserving context and maintaining changelog entries.\n\n---\n\n## Usage\n\n```\n/evolve [task-id] [change-description]\n```\n\n**Examples:**\n- `/evolve user-auth Added password strength validation after security review`\n- `/evolve checkout-flow Discovered need for guest checkout fallback`\n- `/evolve notification-system Changed from polling to WebSocket based on performance testing`\n\n---\n\n## Instructions\n\n### Phase 1: Analysis\n\n1. **Find existing specs** in `specs/active/[task-id]/` (check feature-brief.md, spec.md, plan.md, tasks.md)\n2. **Read all related files** to understand current state and context\n3. **Categorize the change**: Discovery/Refinement (Low), Addition/Modification (Medium), Removal/Architecture (High)\n4. **Assess upgrade need**: Multiple major changes → suggest `/upgrade`, simple discovery → continue with `/evolve`\n\n### Phase 2: Planning\n\nPresent evolution plan with:\n- Task ID and file to update\n- Change summary, type, and impact level\n- Before/after diff of relevant sections\n- Proposed changelog entry\n- Recommendation (proceed or suggest upgrade)\n\n**Wait for user approval before proceeding.**\n\n### Phase 3: Execution\n\n1. **Update spec file** preserving context, adding changelog, incrementing version, updating date\n2. **Add changelog entry** (feature-brief.md uses \"Changelog\" table, spec.md uses \"Revision History\" table)\n3. **Note cross-references** if change affects other documents\n4. **Update status** if spec was marked \"Complete\"\n\n### Phase 4: Downstream Propagation\n\nCheck for stale downstream documents:\n\n1. **List downstream files** in `specs/active/[task-id]/` — check for `plan.md`, `tasks.md`, `todo-list.md`\n2. **Assess impact** using the change category:\n - Discovery/Refinement → downstream docs usually unaffected\n - Addition/Modification → `plan.md` and `tasks.md` likely stale\n - Removal/Architecture → all downstream docs stale\n3. **Add staleness marker** to affected files (insert at top of file):\n ```\n > **[STALE]** — Upstream spec updated on [DATE]. Review needed.\n > Change: [Brief description] (spec.md v[VERSION])\n ```\n4. **Report affected files** in the evolution summary output\n\n### Phase 5: Verification\n\nVerify before final output:\n- Spec file updated, changelog added, version incremented\n- Context preserved, cross-references noted\n- Staleness markers added to affected downstream files\n- **Read file back to confirm changes applied**\n\n---\n\n## Output\n\nEnd response with:\n\n```\n✅ Spec evolved: `specs/active/[task-id]/[file]`\n\n**Change:** [Type] | Impact: [Level] | Version: [old] → [new]\n**Changelog:** | [version] | [date] | [description] | [reason] |\n**Downstream impact:** [List of files marked STALE, or \"None\"]\n**Cross-references:** [Other files that may need updates]\n**Next steps:** Review spec, update stale downstream docs, or consider `/upgrade` for major changes\n```\n\n---\n\n## Change Types\n\n- **Discovery** (Low): Small findings → Add to constraints\n- **Refinement** (Low): Clarifying requirements → Update with specific detail\n- **Addition** (Medium): New requirement → Add, note as post-initial\n- **Modification** (Medium): Changed approach → Update, document rationale\n- **Removal** (High): Descoping → Move to out-of-scope, document reason\n\n---\n\n## When to Suggest Upgrade\n\nSuggest `/upgrade` when change fundamentally alters approach, multiple related changes needed, brief insufficient, or architecture needs redesign.\n\n---\n\n## Troubleshooting\n\n- **Multiple spec files**: Ask which to update\n- **Change conflicts**: Highlight contradiction and ask if both should be updated\n- **Missing changelog**: Add changelog section to older specs\n\n---\n\n## Related Commands\n\n- `/brief [task-id]` - Create initial brief\n- `/upgrade [task-id]` - Expand to full SDD 6.0\n- `/refine [task-id]` - Interactive refinement session\n- `/specify [task-id]` - Create detailed specification\n- `/plan [task-id]` - Update technical plan", "variables": [], "notes": "Update existing specifications with new discoveries, changes, or refinements made during development. Keep documentation aligned with reality.", "metadata": { "source": { "provider": "github-cursor-commands", "repository": "https://github.com/joaobispo2077/env", "path": ".cursor/commands/evolve.md", "ref": "a122952a9c0255e477460bd691413a3f5e1323fc", "url": "https://github.com/joaobispo2077/env/blob/a122952a9c0255e477460bd691413a3f5e1323fc/.cursor/commands/evolve.md", "key": "joaobispo2077/env/.cursor/commands/evolve.md" } } }

evolve

About

/evolve Command

Role

Usage

Instructions

Phase 1: Analysis

Phase 2: Planning

Phase 3: Execution

Phase 4: Downstream Propagation

Phase 5: Verification

Output

Change Types

When to Suggest Upgrade

Troubleshooting

Related Commands

Install evolve 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