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-recon - Prompt - OpenSmartRoute

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

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

Arguments

{{arguments}}

You MUST consider the user input before proceeding (if not empty).

What this stage is

A junior starts coding. A senior starts reading. This stage turns a one-line ask into a credible understanding of: what the user probably actually means, what exists in the codebase today, where the real work will be, and what will bite. It writes exactly one artifact: .senior/work/<slug>/recon.md. It MUST NOT write application code, fix anything, or move on to solutions — that discipline belongs to later stages.

Thinking like the senior

Assume the stated problem is a symptom until evidence says otherwise.
Assumptions are not knowledge: anything you cannot show in the codebase is written down as an assumption or a [NEEDS CLARIFICATION: …] marker — never silently believed.
The best result of recon is sometimes "the user's framing is wrong, here is the actual issue." Surfacing that now is the cheapest win available.

Execution steps

State check: run senior state --json (fallback: python -m seniordev state --json). Parse SLUG and WORK_DIR. If no slug is given, derive a short kebab-case one from the ask and use it consistently everywhere. Create WORK_DIR/recon.md fresh; refuse to silently overwrite a non-empty existing recon.md (ask the user first).
Break down the ask: restate the request in one sentence, then list what it implies and what it does NOT cover. Distinguish: asked / implied / not asked / assumed.
Investigate the codebase until you can answer, with file-level pointers:
- Where does the relevant behavior live today? (search symbols, strings, routes, schemas)
- What conventions does this project follow? (naming, layering, error handling, test style — read real examples, not guesses; cite them)
- Are there docs/READMEs/AGENTS/CONTRIBUTING files that constrain how it wants work done? (If they exist, they are governing: note their requirements verbatim.)
- Git history of the affected areas: recent fixes, revert churn, authors' patterns.
- Prior art: was this tried, partially built, discussed in TODOs or issues?
Check the user's framing: is the described symptom consistent with what the code can do? If the framing looks wrong (e.g., "the bug" is actually expected behavior, or the ask duplicates an existing feature), SAY SO in recon.md under "Framing assessment".

Write .senior/work/<slug>/recon.md exactly in this structure:

# Recon: <slug>

- **Created**: <ISO date> | **Status**: complete | partial

## The ask (restated)

<one sentence + what it implies / does not cover>

## How it works today

- `path/to/file.ext` — <what it does, why it matters>
- <entry points, data flow in 3–6 bullets>

## Conventions this work must follow

- <convention> — evidence: `<example file:line>`

## Framing assessment

- <Does the user's framing hold? If not, what is the real issue?>
- Prior art: <existing feature / recent commits / TODOs relevant here>

## Risks & unknowns

| Risk / unknown | Impact | Evidence or [NEEDS CLARIFICATION: …] |
|---|---|---|

## Handoff to scope

- <the 2–4 things the next stage must size and decide>

Nothing in recon may be marked complete if any load-bearing unknown (one that changes what gets built) is still marked [NEEDS CLARIFICATION] and reasonably answerable by looking harder. Look harder first; ask next.

Rules

READ-ONLY on source. Writes only inside .senior/work/<slug>/.
Every factual claim in recon.md cites evidence (file:line) — claims without evidence must be demoted to explicit assumptions instead.
Do not propose solutions here; capture them only as one-line "candidate approaches" for the scope stage to evaluate.

Done When

recon.md written with all six sections filled
Conventions section cites at least 2 real files from this codebase
Every claim has evidence or is marked as assumption / [NEEDS CLARIFICATION]
Framing assessment gives an explicit verdict on the user's framing
User told: stage complete, and /senior.scope <slug> is the next command

Install senior-recon 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}} ``` You MUST consider the user input before proceeding (if not empty). ## What this stage is A junior starts coding. A senior starts reading. This stage turns a one-line ask into a *credible understanding* of: what the user probably actually means, what exists in the codebase today, where the real work will be, and what will bite. It writes exactly one artifact: `.senior/work/<slug>/recon.md`. It MUST NOT write application code, fix anything, or move on to solutions — that discipline belongs to later stages. ## Thinking like the senior - Assume the stated problem is a symptom until evidence says otherwise. - Assumptions are not knowledge: anything you cannot show in the codebase is written down as an assumption or a `[NEEDS CLARIFICATION: …]` marker — never silently believed. - The best result of recon is sometimes "the user's framing is wrong, here is the actual issue." Surfacing that now is the cheapest win available. ## Execution steps 1. **State check**: run `senior state --json` (fallback: `python -m seniordev state --json`). Parse `SLUG` and `WORK_DIR`. If no slug is given, derive a short kebab-case one from the ask and use it consistently everywhere. Create `WORK_DIR/recon.md` fresh; refuse to silently overwrite a non-empty existing `recon.md` (ask the user first). 2. **Break down the ask**: restate the request in one sentence, then list what it implies and what it does NOT cover. Distinguish: asked / implied / not asked / assumed. 3. **Investigate the codebase** until you can answer, with file-level pointers: - Where does the relevant behavior live today? (search symbols, strings, routes, schemas) - What conventions does this project follow? (naming, layering, error handling, test style — read real examples, not guesses; cite them) - Are there docs/READMEs/AGENTS/CONTRIBUTING files that constrain how it wants work done? (If they exist, they are governing: note their requirements verbatim.) - Git history of the affected areas: recent fixes, revert churn, authors' patterns. - Prior art: was this tried, partially built, discussed in TODOs or issues? 4. **Check the user's framing**: is the described symptom consistent with what the code can do? If the framing looks wrong (e.g., "the bug" is actually expected behavior, or the ask duplicates an existing feature), SAY SO in `recon.md` under "Framing assessment". 5. **Write `.senior/work/<slug>/recon.md`** exactly in this structure: ```markdown # Recon: <slug> - **Created**: <ISO date> | **Status**: complete | partial ## The ask (restated) <one sentence + what it implies / does not cover> ## How it works today - `path/to/file.ext` — <what it does, why it matters> - <entry points, data flow in 3–6 bullets> ## Conventions this work must follow - <convention> — evidence: `<example file:line>` ## Framing assessment - <Does the user's framing hold? If not, what is the real issue?> - Prior art: <existing feature / recent commits / TODOs relevant here> ## Risks & unknowns | Risk / unknown | Impact | Evidence or [NEEDS CLARIFICATION: …] | |---|---|---| ## Handoff to scope - <the 2–4 things the next stage must size and decide> ``` 6. Nothing in recon may be marked `complete` if any **load-bearing** unknown (one that changes what gets built) is still marked `[NEEDS CLARIFICATION]` and reasonably answerable by looking harder. Look harder first; ask next. ## Rules - READ-ONLY on source. Writes only inside `.senior/work/<slug>/`. - Every factual claim in recon.md cites evidence (`file:line`) — claims without evidence must be demoted to explicit assumptions instead. - Do not propose solutions here; capture them only as one-line "candidate approaches" for the scope stage to evaluate. ## Done When - [ ] recon.md written with all six sections filled - [ ] Conventions section cites at least 2 real files from this codebase - [ ] Every claim has evidence or is marked as assumption / `[NEEDS CLARIFICATION]` - [ ] Framing assessment gives an explicit verdict on the user's framing - [ ] User told: stage complete, and `/senior.scope <slug>` is the next command

{ "prompt": "## Arguments\n\n```text\n{{arguments}}\n```\n\nYou MUST consider the user input before proceeding (if not empty).\n\n## What this stage is\n\nA junior starts coding. A senior starts reading. This stage turns a one-line ask into a\n*credible understanding* of: what the user probably actually means, what exists in the\ncodebase today, where the real work will be, and what will bite. It writes exactly one\nartifact: `.senior/work/<slug>/recon.md`. It MUST NOT write application code, fix anything,\nor move on to solutions — that discipline belongs to later stages.\n\n## Thinking like the senior\n\n- Assume the stated problem is a symptom until evidence says otherwise.\n- Assumptions are not knowledge: anything you cannot show in the codebase is written down\n as an assumption or a `[NEEDS CLARIFICATION: …]` marker — never silently believed.\n- The best result of recon is sometimes \"the user's framing is wrong, here is the actual\n issue.\" Surfacing that now is the cheapest win available.\n\n## Execution steps\n\n1. **State check**: run `senior state --json` (fallback: `python -m seniordev state --json`).\n Parse `SLUG` and `WORK_DIR`. If no slug is given, derive a short kebab-case one from the\n ask and use it consistently everywhere. Create `WORK_DIR/recon.md` fresh; refuse to\n silently overwrite a non-empty existing `recon.md` (ask the user first).\n2. **Break down the ask**: restate the request in one sentence, then list what it implies\n and what it does NOT cover. Distinguish: asked / implied / not asked / assumed.\n3. **Investigate the codebase** until you can answer, with file-level pointers:\n - Where does the relevant behavior live today? (search symbols, strings, routes, schemas)\n - What conventions does this project follow? (naming, layering, error handling, test\n style — read real examples, not guesses; cite them)\n - Are there docs/READMEs/AGENTS/CONTRIBUTING files that constrain how it wants work done?\n (If they exist, they are governing: note their requirements verbatim.)\n - Git history of the affected areas: recent fixes, revert churn, authors' patterns.\n - Prior art: was this tried, partially built, discussed in TODOs or issues?\n4. **Check the user's framing**: is the described symptom consistent with what the code can\n do? If the framing looks wrong (e.g., \"the bug\" is actually expected behavior, or the ask\n duplicates an existing feature), SAY SO in `recon.md` under \"Framing assessment\".\n5. **Write `.senior/work/<slug>/recon.md`** exactly in this structure:\n\n ```markdown\n # Recon: <slug>\n\n - **Created**: <ISO date> | **Status**: complete | partial\n\n ## The ask (restated)\n\n <one sentence + what it implies / does not cover>\n\n ## How it works today\n\n - `path/to/file.ext` — <what it does, why it matters>\n - <entry points, data flow in 3–6 bullets>\n\n ## Conventions this work must follow\n\n - <convention> — evidence: `<example file:line>`\n\n ## Framing assessment\n\n - <Does the user's framing hold? If not, what is the real issue?>\n - Prior art: <existing feature / recent commits / TODOs relevant here>\n\n ## Risks & unknowns\n\n | Risk / unknown | Impact | Evidence or [NEEDS CLARIFICATION: …] |\n |---|---|---|\n\n ## Handoff to scope\n\n - <the 2–4 things the next stage must size and decide>\n ```\n\n6. Nothing in recon may be marked `complete` if any **load-bearing** unknown (one that\n changes what gets built) is still marked `[NEEDS CLARIFICATION]` and reasonably\n answerable by looking harder. Look harder first; ask next.\n\n## Rules\n\n- READ-ONLY on source. Writes only inside `.senior/work/<slug>/`.\n- Every factual claim in recon.md cites evidence (`file:line`) — claims without evidence\n must be demoted to explicit assumptions instead.\n- Do not propose solutions here; capture them only as one-line \"candidate approaches\" for\n the scope stage to evaluate.\n\n## Done When\n\n- [ ] recon.md written with all six sections filled\n- [ ] Conventions section cites at least 2 real files from this codebase\n- [ ] Every claim has evidence or is marked as assumption / `[NEEDS CLARIFICATION]`\n- [ ] Framing assessment gives an explicit verdict on the user's framing\n- [ ] User told: stage complete, and `/senior.scope <slug>` is the next command", "variables": [ "arguments" ], "notes": "Investigate before acting — build a credibility-checked understanding of the work, the codebase, and the risks", "metadata": { "source": { "provider": "github-codex-prompts", "repository": "https://github.com/Nom-nom-hub/senior-agent", "path": ".codex/prompts/senior-recon.md", "ref": "44a34366d4323fd3610bfabc4039a6c79e90ffe7", "url": "https://github.com/Nom-nom-hub/senior-agent/blob/44a34366d4323fd3610bfabc4039a6c79e90ffe7/.codex/prompts/senior-recon.md", "key": "Nom-nom-hub/senior-agent/.codex/prompts/senior-recon.md" } } }

senior-recon

About

Arguments

What this stage is

Thinking like the senior

Execution steps

Rules

Done When

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