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.

senior-status - Prompt - OpenSmartRoute

Name: senior-status
Author: Nom-nom-hub

Prompt file imported from Nom-nom-hub/senior-agent (.codex/prompts/senior-status.md). Fill in {{arguments}} before use. Copyright stays with the author.

Arguments

{{arguments}}

What this stage is

The router a senior team lead would run every morning. It reads deterministic state and answers: where is each piece of work, what's blocked, and what is the next correct command. No judgment calls of its own — the state script owns counting; this stage owns the plain- language interpretation.

Execution steps

Run senior state --json for the full picture (all work slugs + all bug slugs; if arguments provide a slug, also request that slug's detail).
If .senior/ does not exist, say precisely: this project has no seniordev workspace, and tell the user to run senior init --agent <their-agent> (or to pick an agent from senior sync --list-agents if unspecified).

Otherwise render a dashboard:

seniordev status
─ Workspace: .senior (initialized <date>, agent: <key>)

Work:
  <slug> — phase <recon|scope|decide|design|execute|review|verify|ship>
          artifacts: <what exists> / <gaps>
          checks: <passing/failing from the state script>
          → next: /senior.<command> <slug>   <or "nothing left; shipped on <date>">

Bugs:
  <slug> — assess ✓ | fix ✓/✗ | test ✓/✗   verdict: …
          → next: /senior.bug-… slug=<slug>

Principles: <versioned/ratified or draft>
Decisions: <date span of D-NNN records>
Backlog: <N items — top 3 by note>

On top: exactly one recommendation (start here if unsure) — the highest-priority unfinished thing: an unshipped verified work item before new work, a failed bug before new work, then newest unfinished work, then the incomplete stage least advanced.
If the user passes a slug, include that work's per-artifact readiness detail (missing inputs for the next command, and what to do about each).

Rules

The status stage never fixes or progresses anything itself; it reads and routes.
Its numbers come from the state script, not from its own recounting.

Done When

Dashboard rendered with per-item phases and gaps
One clear single recommendation named
All → next entries are real commands with correct prerequisites

Install senior-status 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.

## Arguments ```text {{arguments}} ``` ## What this stage is The router a senior team lead would run every morning. It reads deterministic state and answers: where is each piece of work, what's blocked, and what is the next correct command. No judgment calls of its own — the state script owns counting; this stage owns the plain- language interpretation. ## Execution steps 1. Run `senior state --json` for the full picture (all work slugs + all bug slugs; if arguments provide a slug, also request that slug's detail). 2. If `.senior/` does not exist, say precisely: this project has no seniordev workspace, and tell the user to run `senior init --agent <their-agent>` (or to pick an agent from `senior sync --list-agents` if unspecified). 3. Otherwise render a dashboard: ```text seniordev status ─ Workspace: .senior (initialized <date>, agent: <key>) Work: <slug> — phase <recon|scope|decide|design|execute|review|verify|ship> artifacts: <what exists> / <gaps> checks: <passing/failing from the state script> → next: /senior.<command> <slug> <or "nothing left; shipped on <date>"> Bugs: <slug> — assess ✓ | fix ✓/✗ | test ✓/✗ verdict: … → next: /senior.bug-… slug=<slug> Principles: <versioned/ratified or draft> Decisions: <date span of D-NNN records> Backlog: <N items — top 3 by note> ``` 4. On top: exactly one **recommendation** (start here if unsure) — the highest-priority unfinished thing: an unshipped `verified` work item before new work, a `failed` bug before new work, then newest unfinished work, then the incomplete stage least advanced. 5. If the user passes a slug, include that work's per-artifact readiness detail (missing inputs for the next command, and what to do about each). ## Rules - The status stage never fixes or progresses anything itself; it reads and routes. - Its numbers come from the state script, not from its own recounting. ## Done When - [ ] Dashboard rendered with per-item phases and gaps - [ ] One clear single recommendation named - [ ] All `→ next` entries are real commands with correct prerequisites

{ "prompt": "## Arguments\n\n```text\n{{arguments}}\n```\n\n## What this stage is\n\nThe router a senior team lead would run every morning. It reads deterministic state and\nanswers: where is each piece of work, what's blocked, and what is the next correct command.\nNo judgment calls of its own — the state script owns counting; this stage owns the plain-\nlanguage interpretation.\n\n## Execution steps\n\n1. Run `senior state --json` for the full picture (all work slugs + all bug slugs; if\n arguments provide a slug, also request that slug's detail).\n2. If `.senior/` does not exist, say precisely: this project has no seniordev workspace,\n and tell the user to run `senior init --agent <their-agent>` (or to pick an agent from\n `senior sync --list-agents` if unspecified).\n3. Otherwise render a dashboard:\n\n ```text\n seniordev status\n ─ Workspace: .senior (initialized <date>, agent: <key>)\n\n Work:\n <slug> — phase <recon|scope|decide|design|execute|review|verify|ship>\n artifacts: <what exists> / <gaps>\n checks: <passing/failing from the state script>\n → next: /senior.<command> <slug> <or \"nothing left; shipped on <date>\">\n\n Bugs:\n <slug> — assess ✓ | fix ✓/✗ | test ✓/✗ verdict: …\n → next: /senior.bug-… slug=<slug>\n\n Principles: <versioned/ratified or draft>\n Decisions: <date span of D-NNN records>\n Backlog: <N items — top 3 by note>\n ```\n\n4. On top: exactly one **recommendation** (start here if unsure) — the highest-priority\n unfinished thing: an unshipped `verified` work item before new work, a `failed` bug\n before new work, then newest unfinished work, then the incomplete stage least advanced.\n5. If the user passes a slug, include that work's per-artifact readiness detail (missing\n inputs for the next command, and what to do about each).\n\n## Rules\n\n- The status stage never fixes or progresses anything itself; it reads and routes.\n- Its numbers come from the state script, not from its own recounting.\n\n## Done When\n\n- [ ] Dashboard rendered with per-item phases and gaps\n- [ ] One clear single recommendation named\n- [ ] All `→ next` entries are real commands with correct prerequisites", "variables": [ "arguments" ], "notes": "Dashboard — read current workflow state and tell the user exactly what exists, what's missing, and the next command to run", "metadata": { "source": { "provider": "github-codex-prompts", "repository": "https://github.com/Nom-nom-hub/senior-agent", "path": ".codex/prompts/senior-status.md", "ref": "44a34366d4323fd3610bfabc4039a6c79e90ffe7", "url": "https://github.com/Nom-nom-hub/senior-agent/blob/44a34366d4323fd3610bfabc4039a6c79e90ffe7/.codex/prompts/senior-status.md", "key": "Nom-nom-hub/senior-agent/.codex/prompts/senior-status.md" } } }

senior-status

About

Arguments

What this stage is

Execution steps

Rules

Done When

Install senior-status 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