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.

diagnose - Prompt - OpenSmartRoute

Name: diagnose
Author: edwinlov3tt

Prompt file imported from edwinlov3tt/roadmap (.claude/commands/diagnose.md). Copyright stays with the author.

Diagnose — Full-Stack Health Check

Run all diagnostic tools to produce a prioritized report of everything wrong with the running application.

Requires: RuntimeScope SDK connected to a running app. If no session is connected, suggest running /setup first.

Phase 1: Check Connection

Use get_session_info to verify an SDK is connected. If no active session:

No RuntimeScope session detected. Connect your app first:
- Run /setup to install the SDK
- Or check that your app is running with the RuntimeScope snippet

Report the connected app name, SDK version, and session duration.

Phase 2: Run All Diagnostics

Run these tools in sequence and collect results:

detect_issues — Pattern-based issue detection (failed requests, N+1, error spam, slow queries)
get_session_info — Session health and connection status
get_api_health — Endpoint success rates, latency percentiles, error codes
get_query_performance — Database query stats, N+1 detection, slow query analysis
get_performance_metrics — Web Vitals (LCP, FCP, CLS, TTFB, INP) and server metrics
get_console_messages with level: "error" — Runtime errors

Phase 3: Prioritize & Report

Combine all results into a single prioritized report:

# Diagnosis Report

**App**: [app name] | **Session**: [session id] | **Duration**: [time]
**Overall Health**: [Good / Warning / Critical]

## Critical Issues
[Issues that need immediate attention — 500s, crashes, data loss risks]

## Performance
| Metric | Value | Rating |
|--------|-------|--------|
| LCP | Xms | Good/Needs Improvement/Poor |
| FCP | Xms | ... |
| CLS | X | ... |
| TTFB | Xms | ... |

## API Health
| Endpoint | Success Rate | p50 | p95 | Issues |
|----------|-------------|-----|-----|--------|
| POST /api/checkout | 94% | 120ms | 890ms | 6% error rate |

## Database
| Metric | Value |
|--------|-------|
| Slow queries (>500ms) | X |
| N+1 patterns detected | X |
| Missing indexes suggested | X |

## Console Errors
[Top 5 most frequent errors with stack traces]

## Recommendations
1. [Most critical fix]
2. [Second priority]
3. [Third priority]

Phase 4: Suggest Next Steps

Based on findings, suggest specific commands:

API issues → "Run /api /endpoint for details"
Render issues → "Run /renders ComponentName to investigate"
Database issues → "Run /queries slow for slow query details"
Network issues → "Run /network 500 to see failed requests"

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

# Diagnose — Full-Stack Health Check Run all diagnostic tools to produce a prioritized report of everything wrong with the running application. **Requires**: RuntimeScope SDK connected to a running app. If no session is connected, suggest running `/setup` first. --- ## Phase 1: Check Connection Use `get_session_info` to verify an SDK is connected. If no active session: ``` No RuntimeScope session detected. Connect your app first: - Run /setup to install the SDK - Or check that your app is running with the RuntimeScope snippet ``` Report the connected app name, SDK version, and session duration. --- ## Phase 2: Run All Diagnostics Run these tools in sequence and collect results: 1. **`detect_issues`** — Pattern-based issue detection (failed requests, N+1, error spam, slow queries) 2. **`get_session_info`** — Session health and connection status 3. **`get_api_health`** — Endpoint success rates, latency percentiles, error codes 4. **`get_query_performance`** — Database query stats, N+1 detection, slow query analysis 5. **`get_performance_metrics`** — Web Vitals (LCP, FCP, CLS, TTFB, INP) and server metrics 6. **`get_console_messages`** with `level: "error"` — Runtime errors --- ## Phase 3: Prioritize & Report Combine all results into a single prioritized report: ```markdown # Diagnosis Report **App**: [app name] | **Session**: [session id] | **Duration**: [time] **Overall Health**: [Good / Warning / Critical] ## Critical Issues [Issues that need immediate attention — 500s, crashes, data loss risks] ## Performance | Metric | Value | Rating | |--------|-------|--------| | LCP | Xms | Good/Needs Improvement/Poor | | FCP | Xms | ... | | CLS | X | ... | | TTFB | Xms | ... | ## API Health | Endpoint | Success Rate | p50 | p95 | Issues | |----------|-------------|-----|-----|--------| | POST /api/checkout | 94% | 120ms | 890ms | 6% error rate | ## Database | Metric | Value | |--------|-------| | Slow queries (>500ms) | X | | N+1 patterns detected | X | | Missing indexes suggested | X | ## Console Errors [Top 5 most frequent errors with stack traces] ## Recommendations 1. [Most critical fix] 2. [Second priority] 3. [Third priority] ``` --- ## Phase 4: Suggest Next Steps Based on findings, suggest specific commands: - API issues → "Run `/api /endpoint` for details" - Render issues → "Run `/renders ComponentName` to investigate" - Database issues → "Run `/queries slow` for slow query details" - Network issues → "Run `/network 500` to see failed requests"

{ "prompt": "# Diagnose — Full-Stack Health Check\n\nRun all diagnostic tools to produce a prioritized report of everything wrong with the running application.\n\n**Requires**: RuntimeScope SDK connected to a running app. If no session is connected, suggest running `/setup` first.\n\n---\n\n## Phase 1: Check Connection\n\nUse `get_session_info` to verify an SDK is connected. If no active session:\n\n```\nNo RuntimeScope session detected. Connect your app first:\n- Run /setup to install the SDK\n- Or check that your app is running with the RuntimeScope snippet\n```\n\nReport the connected app name, SDK version, and session duration.\n\n---\n\n## Phase 2: Run All Diagnostics\n\nRun these tools in sequence and collect results:\n\n1. **`detect_issues`** — Pattern-based issue detection (failed requests, N+1, error spam, slow queries)\n2. **`get_session_info`** — Session health and connection status\n3. **`get_api_health`** — Endpoint success rates, latency percentiles, error codes\n4. **`get_query_performance`** — Database query stats, N+1 detection, slow query analysis\n5. **`get_performance_metrics`** — Web Vitals (LCP, FCP, CLS, TTFB, INP) and server metrics\n6. **`get_console_messages`** with `level: \"error\"` — Runtime errors\n\n---\n\n## Phase 3: Prioritize & Report\n\nCombine all results into a single prioritized report:\n\n```markdown\n# Diagnosis Report\n\n**App**: [app name] | **Session**: [session id] | **Duration**: [time]\n**Overall Health**: [Good / Warning / Critical]\n\n## Critical Issues\n[Issues that need immediate attention — 500s, crashes, data loss risks]\n\n## Performance\n| Metric | Value | Rating |\n|--------|-------|--------|\n| LCP | Xms | Good/Needs Improvement/Poor |\n| FCP | Xms | ... |\n| CLS | X | ... |\n| TTFB | Xms | ... |\n\n## API Health\n| Endpoint | Success Rate | p50 | p95 | Issues |\n|----------|-------------|-----|-----|--------|\n| POST /api/checkout | 94% | 120ms | 890ms | 6% error rate |\n\n## Database\n| Metric | Value |\n|--------|-------|\n| Slow queries (>500ms) | X |\n| N+1 patterns detected | X |\n| Missing indexes suggested | X |\n\n## Console Errors\n[Top 5 most frequent errors with stack traces]\n\n## Recommendations\n1. [Most critical fix]\n2. [Second priority]\n3. [Third priority]\n```\n\n---\n\n## Phase 4: Suggest Next Steps\n\nBased on findings, suggest specific commands:\n\n- API issues → \"Run `/api /endpoint` for details\"\n- Render issues → \"Run `/renders ComponentName` to investigate\"\n- Database issues → \"Run `/queries slow` for slow query details\"\n- Network issues → \"Run `/network 500` to see failed requests\"", "variables": [], "notes": "Full-stack health check — issues, API health, query performance, Web Vitals Tools: Bash, Read, Grep, Glob.", "metadata": { "source": { "provider": "github-claude-commands", "repository": "https://github.com/edwinlov3tt/roadmap", "path": ".claude/commands/diagnose.md", "ref": "e43db429a68faca4ae9cb47ab64d22cee0b151f3", "url": "https://github.com/edwinlov3tt/roadmap/blob/e43db429a68faca4ae9cb47ab64d22cee0b151f3/.claude/commands/diagnose.md", "key": "edwinlov3tt/roadmap/.claude/commands/diagnose.md" } } }

diagnose

About

Diagnose — Full-Stack Health Check

Phase 1: Check Connection

Phase 2: Run All Diagnostics

Phase 3: Prioritize & Report

Phase 4: Suggest Next Steps

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