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.

write-integration-tests - Prompt

Name: write-integration-tests
Author: cdalsoniii

Prompt file imported from cdalsoniii/brightpath-coder (.cursor/commands/write-integration-tests.md). Copyright stays with the author.

Write Integration Tests

Overview

Generate integration tests with proper fixtures and teardown to validate cross-boundary interactions between components.

Steps

Identify integration points
- Map dependencies between modules/services
- Identify database interactions, API calls, message queue operations
- Determine which boundaries need integration testing
- Document expected integration behaviors
Set up test fixtures and test database
- Create test database schema (separate from production)
- Implement database migrations/seeding for test data
- Set up test containers or in-memory databases
- Configure test environment variables and connections
Write tests for cross-boundary interactions
- Test database CRUD operations with real database
- Verify API client-server communication
- Test message queue producer-consumer flows
- Validate authentication/authorization across layers
- Test transaction boundaries and rollback scenarios
Verify error handling across boundaries
- Test network failures and timeouts
- Verify database connection failures
- Test invalid data propagation between layers
- Ensure proper error transformation and logging
Clean up resources
- Implement teardown hooks to clean test data
- Reset database state between tests
- Close connections and release resources
- Use test fixtures with automatic cleanup (before/after hooks)

Checklist

Test database is isolated from production
Test fixtures properly set up and tear down
Cross-boundary interactions are validated
Error scenarios across boundaries are tested
Resources are properly cleaned up after tests
Tests are independent and can run in any order
Integration tests are tagged/grouped separately from unit tests

References

Rule: .cursor/rules/022-integration-testing.mdc
Rule: .cursor/rules/testing-standards.mdc
Plan: .cursor/plans/test_strategy_quality_assurance.plan.md
Agent: .cursor/agents/test-engineer.md

Install write-integration-tests 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.

# Write Integration Tests ## Overview Generate integration tests with proper fixtures and teardown to validate cross-boundary interactions between components. ## Steps 1. **Identify integration points** - Map dependencies between modules/services - Identify database interactions, API calls, message queue operations - Determine which boundaries need integration testing - Document expected integration behaviors 2. **Set up test fixtures and test database** - Create test database schema (separate from production) - Implement database migrations/seeding for test data - Set up test containers or in-memory databases - Configure test environment variables and connections 3. **Write tests for cross-boundary interactions** - Test database CRUD operations with real database - Verify API client-server communication - Test message queue producer-consumer flows - Validate authentication/authorization across layers - Test transaction boundaries and rollback scenarios 4. **Verify error handling across boundaries** - Test network failures and timeouts - Verify database connection failures - Test invalid data propagation between layers - Ensure proper error transformation and logging 5. **Clean up resources** - Implement teardown hooks to clean test data - Reset database state between tests - Close connections and release resources - Use test fixtures with automatic cleanup (before/after hooks) ## Checklist - [ ] Test database is isolated from production - [ ] Test fixtures properly set up and tear down - [ ] Cross-boundary interactions are validated - [ ] Error scenarios across boundaries are tested - [ ] Resources are properly cleaned up after tests - [ ] Tests are independent and can run in any order - [ ] Integration tests are tagged/grouped separately from unit tests ## References - Rule: `.cursor/rules/022-integration-testing.mdc` - Rule: `.cursor/rules/testing-standards.mdc` - Plan: `.cursor/plans/test_strategy_quality_assurance.plan.md` - Agent: `.cursor/agents/test-engineer.md`

{ "prompt": "# Write Integration Tests\n\n## Overview\nGenerate integration tests with proper fixtures and teardown to validate cross-boundary interactions between components.\n\n## Steps\n\n1. **Identify integration points**\n - Map dependencies between modules/services\n - Identify database interactions, API calls, message queue operations\n - Determine which boundaries need integration testing\n - Document expected integration behaviors\n\n2. **Set up test fixtures and test database**\n - Create test database schema (separate from production)\n - Implement database migrations/seeding for test data\n - Set up test containers or in-memory databases\n - Configure test environment variables and connections\n\n3. **Write tests for cross-boundary interactions**\n - Test database CRUD operations with real database\n - Verify API client-server communication\n - Test message queue producer-consumer flows\n - Validate authentication/authorization across layers\n - Test transaction boundaries and rollback scenarios\n\n4. **Verify error handling across boundaries**\n - Test network failures and timeouts\n - Verify database connection failures\n - Test invalid data propagation between layers\n - Ensure proper error transformation and logging\n\n5. **Clean up resources**\n - Implement teardown hooks to clean test data\n - Reset database state between tests\n - Close connections and release resources\n - Use test fixtures with automatic cleanup (before/after hooks)\n\n## Checklist\n\n- [ ] Test database is isolated from production\n- [ ] Test fixtures properly set up and tear down\n- [ ] Cross-boundary interactions are validated\n- [ ] Error scenarios across boundaries are tested\n- [ ] Resources are properly cleaned up after tests\n- [ ] Tests are independent and can run in any order\n- [ ] Integration tests are tagged/grouped separately from unit tests\n\n## References\n\n- Rule: `.cursor/rules/022-integration-testing.mdc`\n- Rule: `.cursor/rules/testing-standards.mdc`\n- Plan: `.cursor/plans/test_strategy_quality_assurance.plan.md`\n- Agent: `.cursor/agents/test-engineer.md`", "variables": [], "notes": "1. **Identify integration points** - Map dependencies between modules/services - Identify database interactions, API calls, message queue operations - Determine which boundaries need integration testing - Document expected integration behaviors", "metadata": { "source": { "provider": "github-cursor-commands", "repository": "https://github.com/cdalsoniii/brightpath-coder", "path": ".cursor/commands/write-integration-tests.md", "ref": "6fab58a589619342c36cd1f983a53f36671c7a20", "url": "https://github.com/cdalsoniii/brightpath-coder/blob/6fab58a589619342c36cd1f983a53f36671c7a20/.cursor/commands/write-integration-tests.md", "key": "cdalsoniii/brightpath-coder/.cursor/commands/write-integration-tests.md" } } }

write-integration-tests

About

Write Integration Tests

Overview

Steps

Checklist

References

Install write-integration-tests 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