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.

implement - Prompt - OpenSmartRoute

Name: implement
Author: ryandt33

Prompt file imported from ryandt33/raptscallions (.claude/commands/developer/implement.md). Fill in {{arguments}} before use. Copyright stays with the author.

Implement

Write implementation code to pass the tests (TDD green phase).

Usage

/implement E01-T001

Process

Load the developer agent: @developer
Read the task at backlog/tasks/{epic}/{task-id}.md
Read the spec at backlog/docs/specs/{epic}/{task-id}-spec.md
Read existing test files
Write implementation code
Run pnpm test - all tests must pass
Run pnpm lint - must pass
Run pnpm typecheck - must pass
Update task workflow_state to IMPLEMENTED
Update code_files in task frontmatter

CRITICAL: Test-API Mismatch Detection

⚠️ If you discover that tests were written with incorrect assumptions about a library's actual API:

DO NOT:

Hack the implementation to satisfy bad tests
Add wrapper code just to make tests pass
Expose internal details that wouldn't otherwise be needed
Write Object.assign tricks or other test-only methods

INSTEAD:

Set workflow_state: TESTS_REVISION_NEEDED
Document the mismatch in History table
Add detailed feedback in Reviews section explaining:
- What the test expected
- What the library actually provides
- Suggested test approach
DO NOT implement anything

Signs of a test-API mismatch:

You're adding code just to satisfy test expectations, not feature requirements
You're creating wrappers around library APIs
The "minimum code to pass" is more than the actual feature needs
Library documentation doesn't match what tests expect

Example:

Tests expect `users._` property but Drizzle tables don't have this.
→ Set workflow_state to TESTS_REVISION_NEEDED
→ Explain in Reviews section what Drizzle actually provides
→ Tests will be rewritten to use correct API

This ensures clean code without "testability hacks."

CRITICAL: Test Coherence Issues

⚠️ Tests can be technically valid (use real APIs, compile correctly) but still be fundamentally flawed.

Reject tests that are internally contradictory or don't reflect the spec. Do NOT contort your implementation to satisfy poorly designed tests.

When to Reject for Coherence Issues

1. Internally Contradictory Tests

Different test cases have mutually exclusive expectations that can only be satisfied by bizarre conditional logic.

Signs:

You're adding conditions like if (A && B && !C) that have no basis in requirements
Test case 1 passes without X, but test case 4 fails without X under slightly different conditions
You can't explain WHY the logic works, only that it makes tests pass

Example of bad implementation forced by contradictory tests:

// ❌ This logic exists only to satisfy contradictory tests
// Why these three conditions together? No spec justification.
if (hasFetchDepth && hasTimeout && !stalenessStep) {
  errors.push('Missing artifact');
}

2. Tests That Don't Reflect the Spec

Tests encode requirements that don't exist in the acceptance criteria, or contradict them.

Signs:

You're implementing behavior not mentioned in any AC
The spec says "always require X" but tests only require X in specific scenarios
You can't trace test assertions back to spec requirements

3. Tests Written Incrementally Without Reconciliation

Later tests were added without checking if they conflict with earlier tests.

Signs:

Early tests pass with minimal config
Later tests add requirements that early tests don't have
No test covers the "full happy path" that satisfies all requirements

The Rejection Rule

If you find yourself writing logic that:

You cannot justify from the spec
You cannot explain without saying "because the tests expect it"
Creates coupling between unrelated concerns
Would fail code review for being "magic" or "unexplainable"

→ Reject the tests. Do NOT implement.

Rejection Process

Set workflow_state: TESTS_REVISION_NEEDED
Add History entry explaining the coherence issues
Add detailed feedback in Reviews section:
- Which specific tests contradict each other (with line numbers)
- What the spec actually requires
- What clean implementation would look like
- Request that tests be reconciled before implementation continues

Example feedback:

### Test Revision Required (Developer)

**Date:** 2026-01-14
**Reason:** Test Coherence Issues

**Problem:**
Tests are internally contradictory. Cannot implement clean logic that satisfies all tests.

**Contradictions:**
- Test at line 19-43: Workflow WITHOUT fetch-depth → expects valid: true
- Test at line 63-85: Workflow WITHOUT fetch-depth → expects error about fetch-depth
- Test at line 411-439: Workflow WITH fetch-depth + timeout → expects artifact error

**Spec says (AC8):** "Build artifacts available for preview" - implies always required.

**What I'd have to implement:**
```typescript
// Bizarre coupling with no spec basis
if (hasFetchDepth && hasTimeout && !stalenessStep && !artifactStep) {
  errors.push('Missing artifact');
}

What clean implementation would be:

// Simple, matches AC8
if (!artifactStep) {
  errors.push('Missing artifact upload step');
}

Request: Please reconcile test cases so requirements are consistent. Either artifact is always required (per AC8) or clarify when it's optional.


## Arguments

- `{{arguments}}` - The task ID (e.g., E01-T001)

## Next Step

Based on the task workflow:

**Development workflow:**
- If task has `frontend` label: Run `/designer:review-ui {task-id}`
- Otherwise: Run `/reviewer:review-code {task-id}`

**Schema workflow:**
Run `/reviewer:review-migration {task-id}` - Migration safety review

**Infrastructure workflow (standard):**
Run `/reviewer:review-code {task-id}` - Code review

**Infrastructure workflow (simple - `infra:simple`):**
Run `/writer:update-docs {task-id}` - Update documentation

**Bugfix workflow (standard):**
Run `/reviewer:review-code {task-id}` - Code review

**Bugfix workflow (simple - `bugfix:simple`):**
Run `/qa:verify-fix {task-id}` - Verify bug is fixed

**Bugfix workflow (hotfix - `bugfix:hotfix`):**
Run `/developer:write-tests {task-id}` - Write regression test (after fix)

---

*Implementation varies by workflow. Check task's workflow category and variant.*

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

# Implement Write implementation code to pass the tests (TDD green phase). ## Usage ``` /implement E01-T001 ``` ## Process 1. Load the developer agent: `@developer` 2. Read the task at `backlog/tasks/{epic}/{task-id}.md` 3. Read the spec at `backlog/docs/specs/{epic}/{task-id}-spec.md` 4. Read existing test files 5. Write implementation code 6. Run `pnpm test` - all tests must pass 7. Run `pnpm lint` - must pass 8. Run `pnpm typecheck` - must pass 9. Update task `workflow_state` to `IMPLEMENTED` 10. Update `code_files` in task frontmatter ## CRITICAL: Test-API Mismatch Detection ⚠️ **If you discover that tests were written with incorrect assumptions about a library's actual API:** **DO NOT:** - Hack the implementation to satisfy bad tests - Add wrapper code just to make tests pass - Expose internal details that wouldn't otherwise be needed - Write `Object.assign` tricks or other test-only methods **INSTEAD:** 1. Set `workflow_state: TESTS_REVISION_NEEDED` 2. Document the mismatch in History table 3. Add detailed feedback in Reviews section explaining: - What the test expected - What the library actually provides - Suggested test approach 4. DO NOT implement anything **Signs of a test-API mismatch:** - You're adding code just to satisfy test expectations, not feature requirements - You're creating wrappers around library APIs - The "minimum code to pass" is more than the actual feature needs - Library documentation doesn't match what tests expect **Example:** ``` Tests expect `users._` property but Drizzle tables don't have this. → Set workflow_state to TESTS_REVISION_NEEDED → Explain in Reviews section what Drizzle actually provides → Tests will be rewritten to use correct API ``` This ensures clean code without "testability hacks." ## CRITICAL: Test Coherence Issues ⚠️ **Tests can be technically valid (use real APIs, compile correctly) but still be fundamentally flawed.** Reject tests that are internally contradictory or don't reflect the spec. Do NOT contort your implementation to satisfy poorly designed tests. ### When to Reject for Coherence Issues **1. Internally Contradictory Tests** Different test cases have mutually exclusive expectations that can only be satisfied by bizarre conditional logic. **Signs:** - You're adding conditions like `if (A && B && !C)` that have no basis in requirements - Test case 1 passes without X, but test case 4 fails without X under slightly different conditions - You can't explain WHY the logic works, only that it makes tests pass **Example of bad implementation forced by contradictory tests:** ```typescript // ❌ This logic exists only to satisfy contradictory tests // Why these three conditions together? No spec justification. if (hasFetchDepth && hasTimeout && !stalenessStep) { errors.push('Missing artifact'); } ``` **2. Tests That Don't Reflect the Spec** Tests encode requirements that don't exist in the acceptance criteria, or contradict them. **Signs:** - You're implementing behavior not mentioned in any AC - The spec says "always require X" but tests only require X in specific scenarios - You can't trace test assertions back to spec requirements **3. Tests Written Incrementally Without Reconciliation** Later tests were added without checking if they conflict with earlier tests. **Signs:** - Early tests pass with minimal config - Later tests add requirements that early tests don't have - No test covers the "full happy path" that satisfies all requirements ### The Rejection Rule **If you find yourself writing logic that:** 1. You cannot justify from the spec 2. You cannot explain without saying "because the tests expect it" 3. Creates coupling between unrelated concerns 4. Would fail code review for being "magic" or "unexplainable" **→ Reject the tests. Do NOT implement.** ### Rejection Process 1. Set `workflow_state: TESTS_REVISION_NEEDED` 2. Add History entry explaining the coherence issues 3. Add detailed feedback in Reviews section: - Which specific tests contradict each other (with line numbers) - What the spec actually requires - What clean implementation would look like - Request that tests be reconciled before implementation continues **Example feedback:** ```markdown ### Test Revision Required (Developer) **Date:** 2026-01-14 **Reason:** Test Coherence Issues **Problem:** Tests are internally contradictory. Cannot implement clean logic that satisfies all tests. **Contradictions:** - Test at line 19-43: Workflow WITHOUT fetch-depth → expects valid: true - Test at line 63-85: Workflow WITHOUT fetch-depth → expects error about fetch-depth - Test at line 411-439: Workflow WITH fetch-depth + timeout → expects artifact error **Spec says (AC8):** "Build artifacts available for preview" - implies always required. **What I'd have to implement:** ```typescript // Bizarre coupling with no spec basis if (hasFetchDepth && hasTimeout && !stalenessStep && !artifactStep) { errors.push('Missing artifact'); } ``` **What clean implementation would be:** ```typescript // Simple, matches AC8 if (!artifactStep) { errors.push('Missing artifact upload step'); } ``` **Request:** Please reconcile test cases so requirements are consistent. Either artifact is always required (per AC8) or clarify when it's optional. ``` ## Arguments - `{{arguments}}` - The task ID (e.g., E01-T001) ## Next Step Based on the task workflow: **Development workflow:** - If task has `frontend` label: Run `/designer:review-ui {task-id}` - Otherwise: Run `/reviewer:review-code {task-id}` **Schema workflow:** Run `/reviewer:review-migration {task-id}` - Migration safety review **Infrastructure workflow (standard):** Run `/reviewer:review-code {task-id}` - Code review **Infrastructure workflow (simple - `infra:simple`):** Run `/writer:update-docs {task-id}` - Update documentation **Bugfix workflow (standard):** Run `/reviewer:review-code {task-id}` - Code review **Bugfix workflow (simple - `bugfix:simple`):** Run `/qa:verify-fix {task-id}` - Verify bug is fixed **Bugfix workflow (hotfix - `bugfix:hotfix`):** Run `/developer:write-tests {task-id}` - Write regression test (after fix) --- *Implementation varies by workflow. Check task's workflow category and variant.*

{ "prompt": "# Implement\n\nWrite implementation code to pass the tests (TDD green phase).\n\n## Usage\n\n```\n/implement E01-T001\n```\n\n## Process\n\n1. Load the developer agent: `@developer`\n2. Read the task at `backlog/tasks/{epic}/{task-id}.md`\n3. Read the spec at `backlog/docs/specs/{epic}/{task-id}-spec.md`\n4. Read existing test files\n5. Write implementation code\n6. Run `pnpm test` - all tests must pass\n7. Run `pnpm lint` - must pass\n8. Run `pnpm typecheck` - must pass\n9. Update task `workflow_state` to `IMPLEMENTED`\n10. Update `code_files` in task frontmatter\n\n## CRITICAL: Test-API Mismatch Detection\n\n⚠️ **If you discover that tests were written with incorrect assumptions about a library's actual API:**\n\n**DO NOT:**\n- Hack the implementation to satisfy bad tests\n- Add wrapper code just to make tests pass\n- Expose internal details that wouldn't otherwise be needed\n- Write `Object.assign` tricks or other test-only methods\n\n**INSTEAD:**\n1. Set `workflow_state: TESTS_REVISION_NEEDED`\n2. Document the mismatch in History table\n3. Add detailed feedback in Reviews section explaining:\n - What the test expected\n - What the library actually provides\n - Suggested test approach\n4. DO NOT implement anything\n\n**Signs of a test-API mismatch:**\n- You're adding code just to satisfy test expectations, not feature requirements\n- You're creating wrappers around library APIs\n- The \"minimum code to pass\" is more than the actual feature needs\n- Library documentation doesn't match what tests expect\n\n**Example:**\n```\nTests expect `users._` property but Drizzle tables don't have this.\n→ Set workflow_state to TESTS_REVISION_NEEDED\n→ Explain in Reviews section what Drizzle actually provides\n→ Tests will be rewritten to use correct API\n```\n\nThis ensures clean code without \"testability hacks.\"\n\n## CRITICAL: Test Coherence Issues\n\n⚠️ **Tests can be technically valid (use real APIs, compile correctly) but still be fundamentally flawed.**\n\nReject tests that are internally contradictory or don't reflect the spec. Do NOT contort your implementation to satisfy poorly designed tests.\n\n### When to Reject for Coherence Issues\n\n**1. Internally Contradictory Tests**\n\nDifferent test cases have mutually exclusive expectations that can only be satisfied by bizarre conditional logic.\n\n**Signs:**\n- You're adding conditions like `if (A && B && !C)` that have no basis in requirements\n- Test case 1 passes without X, but test case 4 fails without X under slightly different conditions\n- You can't explain WHY the logic works, only that it makes tests pass\n\n**Example of bad implementation forced by contradictory tests:**\n```typescript\n// ❌ This logic exists only to satisfy contradictory tests\n// Why these three conditions together? No spec justification.\nif (hasFetchDepth && hasTimeout && !stalenessStep) {\n errors.push('Missing artifact');\n}\n```\n\n**2. Tests That Don't Reflect the Spec**\n\nTests encode requirements that don't exist in the acceptance criteria, or contradict them.\n\n**Signs:**\n- You're implementing behavior not mentioned in any AC\n- The spec says \"always require X\" but tests only require X in specific scenarios\n- You can't trace test assertions back to spec requirements\n\n**3. Tests Written Incrementally Without Reconciliation**\n\nLater tests were added without checking if they conflict with earlier tests.\n\n**Signs:**\n- Early tests pass with minimal config\n- Later tests add requirements that early tests don't have\n- No test covers the \"full happy path\" that satisfies all requirements\n\n### The Rejection Rule\n\n**If you find yourself writing logic that:**\n1. You cannot justify from the spec\n2. You cannot explain without saying \"because the tests expect it\"\n3. Creates coupling between unrelated concerns\n4. Would fail code review for being \"magic\" or \"unexplainable\"\n\n**→ Reject the tests. Do NOT implement.**\n\n### Rejection Process\n\n1. Set `workflow_state: TESTS_REVISION_NEEDED`\n2. Add History entry explaining the coherence issues\n3. Add detailed feedback in Reviews section:\n - Which specific tests contradict each other (with line numbers)\n - What the spec actually requires\n - What clean implementation would look like\n - Request that tests be reconciled before implementation continues\n\n**Example feedback:**\n```markdown\n### Test Revision Required (Developer)\n\n**Date:** 2026-01-14\n**Reason:** Test Coherence Issues\n\n**Problem:**\nTests are internally contradictory. Cannot implement clean logic that satisfies all tests.\n\n**Contradictions:**\n- Test at line 19-43: Workflow WITHOUT fetch-depth → expects valid: true\n- Test at line 63-85: Workflow WITHOUT fetch-depth → expects error about fetch-depth\n- Test at line 411-439: Workflow WITH fetch-depth + timeout → expects artifact error\n\n**Spec says (AC8):** \"Build artifacts available for preview\" - implies always required.\n\n**What I'd have to implement:**\n```typescript\n// Bizarre coupling with no spec basis\nif (hasFetchDepth && hasTimeout && !stalenessStep && !artifactStep) {\n errors.push('Missing artifact');\n}\n```\n\n**What clean implementation would be:**\n```typescript\n// Simple, matches AC8\nif (!artifactStep) {\n errors.push('Missing artifact upload step');\n}\n```\n\n**Request:** Please reconcile test cases so requirements are consistent. Either artifact is always required (per AC8) or clarify when it's optional.\n```\n\n## Arguments\n\n- `{{arguments}}` - The task ID (e.g., E01-T001)\n\n## Next Step\n\nBased on the task workflow:\n\n**Development workflow:**\n- If task has `frontend` label: Run `/designer:review-ui {task-id}`\n- Otherwise: Run `/reviewer:review-code {task-id}`\n\n**Schema workflow:**\nRun `/reviewer:review-migration {task-id}` - Migration safety review\n\n**Infrastructure workflow (standard):**\nRun `/reviewer:review-code {task-id}` - Code review\n\n**Infrastructure workflow (simple - `infra:simple`):**\nRun `/writer:update-docs {task-id}` - Update documentation\n\n**Bugfix workflow (standard):**\nRun `/reviewer:review-code {task-id}` - Code review\n\n**Bugfix workflow (simple - `bugfix:simple`):**\nRun `/qa:verify-fix {task-id}` - Verify bug is fixed\n\n**Bugfix workflow (hotfix - `bugfix:hotfix`):**\nRun `/developer:write-tests {task-id}` - Write regression test (after fix)\n\n---\n\n*Implementation varies by workflow. Check task's workflow category and variant.*", "variables": [ "arguments" ], "notes": "Implement code to pass tests (TDD green phase) Tools: Read, Write, Edit, Bash, Glob, Grep.", "metadata": { "source": { "provider": "github-claude-commands", "repository": "https://github.com/ryandt33/raptscallions", "path": ".claude/commands/developer/implement.md", "ref": "7388234abb0ea5fc48e4e54d9b731adc485b3aa7", "url": "https://github.com/ryandt33/raptscallions/blob/7388234abb0ea5fc48e4e54d9b731adc485b3aa7/.claude/commands/developer/implement.md", "key": "ryandt33/raptscallions/.claude/commands/developer/implement.md" } } }

implement

About

Implement

Usage

Process

CRITICAL: Test-API Mismatch Detection

CRITICAL: Test Coherence Issues

When to Reject for Coherence Issues

The Rejection Rule

Rejection Process

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