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.

09-learn - Prompt - OpenSmartRoute

Name: 09-learn
Author: ranerez1

Prompt file imported from ranerez1/BuilderOS (.claude/commands/09-learn.md). Copyright stays with the author.

Run anytime: ship retro (update PRD/TDD) and/or process–skill improvement from feedback; write a durable note under Learnings/.

Learn (retro + continuous improvement)

Make BuilderOS better every iteration: capture what happened, why, and what to change—in product docs, technical docs, Learnings notes, and optionally other skills/commands.

Prefer being specific and actionable over being exhaustive.

Modes (pick one per run; infer from context)

A) Ship retro

When the user ties the session to shipped / reverted / partially shipped work: update PRD + TDD (as below) and always write Learnings/YYYY-MM-DD_<short-slug>.md.

If the session also exposed skill or process gaps, add the Process / skill improvement sections to the same learning file (type: mixed).

B) Process / skill improvement

When there is no ship context (bad chat, wrong tool use, missed rule, user critique, repeated corrections): do not invent product intent or force PRD/TDD edits.

Classify explicit user feedback vs implicit signals (misunderstandings, tool errors, plan drift, avoidable retries).
Inventory relevant skills: paths the user named plus implicated SKILL.md files in the workspace skill directories and matching .claude/commands/*.md—use lightweight search/read; do not rewrite every skill.
For each implicated file: concrete recommendations (new step, input, guardrail, wording).
Write Learnings/YYYY-MM-DD_<short-slug>.md using the full template.
Apply changes to skills/commands only if the user explicitly asks to apply in the same run. Otherwise recommendations live in chat + the learning note only.

When applying: if you edit a SKILL.md that has a matching command stub in .claude/commands/, update that command file with the same operational content inlined (self-contained text only—no “see skill file” links).

Inputs (minimal; infer when possible)

Always useful

What to capture (one line).
Date (default: today).

Ship retro (ask only if missing)

Work item name
Identifier(s): ticket id, PR, commit, doc slugs
Outcome: shipped / reverted / partially shipped
Scope delta vs plan
Timeline (rough)

Process / skill improvement

What went wrong or what to improve
Which skills/commands were involved (optional if inferable)

Find the relevant docs (ship retro only)

PRD

Outputs/Product PRDs/*<ticketId>* or match by feature slug
If none: do not invent intent; add Outputs/Product PRDs/YYYY-MM-DD_<ticketId?>_<short-slug>_retro-addendum.md

TDD

Outputs/Technical Docs/*<ticketId>* or match by slug
If none: create Outputs/Technical Docs/YYYY-MM-DD_<ticketId?>_<short-slug>.md in Post-build style

Update rules (ship retro; keep diffs small)

Prefer appending dated sections.
Document delta and why when reality diverged from the plan.

PRD retro block

## Retro (YYYY-MM-DD)
- **What shipped**:
- **What didn’t ship (and why)**:
- **User impact observed**:
- **Metrics / success signals**:
- **Follow-ups**:

TDD retro block

## Retro (YYYY-MM-DD)
### Delta vs plan
- ...
### Incidents / surprises
- ...
### Decisions that paid off
- ...
### Decisions we’d change next time
- ...
### Operational notes
- Observability gaps:
- Runbook updates needed:

Learnings file (always for this command)

Path: Learnings/YYYY-MM-DD_<short-slug>.md (create Learnings/ if missing).

Template:

# Learning: [short title]

## Context
- **Work item** (or session topic):
- **Date**: YYYY-MM-DD
- **Type**: feature | bugfix | refactor | infra | process | skill-tuning | mixed
- **Stack area**: (if relevant)
- **Links**: PRs, docs, chats, dashboards

## Explicit feedback (user)
- Quotes or faithful paraphrase

## Implicit signals / model–tool failures
- Wrong assumptions, missed rules, tool errors, approval friction, plan drift

## Affected skills / commands
- path/to/file

## Recommended changes (do not apply unless user requested apply in this run)
- **File:** `...` — change: ...

## Ship retro (if mode A or mixed)
### What went well
- ...
### What went poorly
- ...
### Root causes (if relevant)
- ...
### Changes we’ll make next time
- ...

## Checklists / heuristics
- If [condition], then [do this].
- Prefer [pattern] over [anti-pattern] because [reason].

Guidelines

At least one concrete checklist line.
Record trigger and early signal for painful failures.
No names/blame; systems and process only.

Workflow (summary)

Choose mode A and/or B; compute <short-slug>.
Mode A: locate/update PRD + TDD; append retro blocks.
Mode B (or mixed): classify feedback; list implicated skills; write recommendations.
Write Learnings/...md (full template; omit sections that truly don’t apply).
If user said apply: patch skills + mirror commands per sync rule above; summarize diffs.

Output (to the user)

Path to Learnings/...
Paths of updated PRD/TDD if mode A ran
If recommendations only: list recommended file edits; if applied: note what changed
5–10 bullets summarizing learnings and follow-ups

Install 09-learn 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.

Run anytime: ship retro (update PRD/TDD) and/or process–skill improvement from feedback; write a durable note under `Learnings/`. # Learn (retro + continuous improvement) Make BuilderOS **better every iteration**: capture what happened, why, and what to change—in **product docs**, **technical docs**, **Learnings notes**, and optionally **other skills/commands**. Prefer being **specific and actionable** over being exhaustive. ## Modes (pick one per run; infer from context) ### A) Ship retro When the user ties the session to **shipped / reverted / partially shipped** work: update **PRD** + **TDD** (as below) and always write **`Learnings/YYYY-MM-DD_<short-slug>.md`**. If the session also exposed **skill or process** gaps, add the **Process / skill improvement** sections to the **same** learning file (type: `mixed`). ### B) Process / skill improvement When there is **no** ship context (bad chat, wrong tool use, missed rule, user critique, repeated corrections): **do not** invent product intent or force PRD/TDD edits. 1. Classify **explicit** user feedback vs **implicit** signals (misunderstandings, tool errors, plan drift, avoidable retries). 2. **Inventory relevant skills:** paths the user named plus implicated **SKILL.md** files in the workspace skill directories and matching `.claude/commands/*.md`—use **lightweight** search/read; do not rewrite every skill. 3. For each implicated file: **concrete** recommendations (new step, input, guardrail, wording). 4. Write **`Learnings/YYYY-MM-DD_<short-slug>.md`** using the full template. 5. **Apply** changes to skills/commands **only if** the user explicitly asks to **apply** in the **same** run. Otherwise recommendations live in chat + the learning note only. When applying: if you edit a **SKILL.md** that has a matching command stub in **`.claude/commands/`**, update that command file with the **same** operational content **inlined** (self-contained text only—no “see skill file” links). ## Inputs (minimal; infer when possible) **Always useful** - What to capture (one line). - **Date** (default: today). **Ship retro (ask only if missing)** - **Work item** name - **Identifier(s)**: ticket id, PR, commit, doc slugs - **Outcome**: shipped / reverted / partially shipped - **Scope delta** vs plan - **Timeline** (rough) **Process / skill improvement** - What went wrong or what to improve - Which skills/commands were involved (optional if inferable) ## Find the relevant docs (ship retro only) ### PRD - `Outputs/Product PRDs/*<ticketId>*` or match by feature slug - If none: do **not** invent intent; add `Outputs/Product PRDs/YYYY-MM-DD_<ticketId?>_<short-slug>_retro-addendum.md` ### TDD - `Outputs/Technical Docs/*<ticketId>*` or match by slug - If none: create `Outputs/Technical Docs/YYYY-MM-DD_<ticketId?>_<short-slug>.md` in **Post-build** style ## Update rules (ship retro; keep diffs small) - Prefer **appending** dated sections. - Document **delta and why** when reality diverged from the plan. ### PRD retro block ```markdown ## Retro (YYYY-MM-DD) - **What shipped**: - **What didn’t ship (and why)**: - **User impact observed**: - **Metrics / success signals**: - **Follow-ups**: ``` ### TDD retro block ```markdown ## Retro (YYYY-MM-DD) ### Delta vs plan - ... ### Incidents / surprises - ... ### Decisions that paid off - ... ### Decisions we’d change next time - ... ### Operational notes - Observability gaps: - Runbook updates needed: ``` ## Learnings file (always for this command) **Path:** `Learnings/YYYY-MM-DD_<short-slug>.md` (create `Learnings/` if missing). **Template:** ```markdown # Learning: [short title] ## Context - **Work item** (or session topic): - **Date**: YYYY-MM-DD - **Type**: feature | bugfix | refactor | infra | process | skill-tuning | mixed - **Stack area**: (if relevant) - **Links**: PRs, docs, chats, dashboards ## Explicit feedback (user) - Quotes or faithful paraphrase ## Implicit signals / model–tool failures - Wrong assumptions, missed rules, tool errors, approval friction, plan drift ## Affected skills / commands - path/to/file ## Recommended changes (do not apply unless user requested apply in this run) - **File:** `...` — change: ... ## Ship retro (if mode A or mixed) ### What went well - ... ### What went poorly - ... ### Root causes (if relevant) - ... ### Changes we’ll make next time - ... ## Checklists / heuristics - If [condition], then [do this]. - Prefer [pattern] over [anti-pattern] because [reason]. ``` **Guidelines** - At least **one** concrete checklist line. - Record **trigger** and **early signal** for painful failures. - No names/blame; systems and process only. ## Workflow (summary) 1. Choose **mode A** and/or **B**; compute `<short-slug>`. 2. **Mode A:** locate/update PRD + TDD; append retro blocks. 3. **Mode B (or mixed):** classify feedback; list implicated skills; write recommendations. 4. Write **`Learnings/...md`** (full template; omit sections that truly don’t apply). 5. If user said **apply**: patch skills + mirror commands per sync rule above; summarize diffs. ## Output (to the user) - Path to **`Learnings/...`** - Paths of updated PRD/TDD **if** mode A ran - If recommendations only: list **recommended** file edits; if applied: note **what changed** - **5–10 bullets** summarizing learnings and follow-ups

{ "prompt": "Run anytime: ship retro (update PRD/TDD) and/or process–skill improvement from feedback; write a durable note under `Learnings/`.\n\n# Learn (retro + continuous improvement)\n\nMake BuilderOS **better every iteration**: capture what happened, why, and what to change—in **product docs**, **technical docs**, **Learnings notes**, and optionally **other skills/commands**.\n\nPrefer being **specific and actionable** over being exhaustive.\n\n## Modes (pick one per run; infer from context)\n\n### A) Ship retro\n\nWhen the user ties the session to **shipped / reverted / partially shipped** work: update **PRD** + **TDD** (as below) and always write **`Learnings/YYYY-MM-DD_<short-slug>.md`**.\n\nIf the session also exposed **skill or process** gaps, add the **Process / skill improvement** sections to the **same** learning file (type: `mixed`).\n\n### B) Process / skill improvement\n\nWhen there is **no** ship context (bad chat, wrong tool use, missed rule, user critique, repeated corrections): **do not** invent product intent or force PRD/TDD edits.\n\n1. Classify **explicit** user feedback vs **implicit** signals (misunderstandings, tool errors, plan drift, avoidable retries).\n2. **Inventory relevant skills:** paths the user named plus implicated **SKILL.md** files in the workspace skill directories and matching `.claude/commands/*.md`—use **lightweight** search/read; do not rewrite every skill.\n3. For each implicated file: **concrete** recommendations (new step, input, guardrail, wording).\n4. Write **`Learnings/YYYY-MM-DD_<short-slug>.md`** using the full template.\n5. **Apply** changes to skills/commands **only if** the user explicitly asks to **apply** in the **same** run. Otherwise recommendations live in chat + the learning note only.\n\nWhen applying: if you edit a **SKILL.md** that has a matching command stub in **`.claude/commands/`**, update that command file with the **same** operational content **inlined** (self-contained text only—no “see skill file” links).\n\n## Inputs (minimal; infer when possible)\n\n**Always useful**\n\n- What to capture (one line).\n- **Date** (default: today).\n\n**Ship retro (ask only if missing)**\n\n- **Work item** name\n- **Identifier(s)**: ticket id, PR, commit, doc slugs\n- **Outcome**: shipped / reverted / partially shipped\n- **Scope delta** vs plan\n- **Timeline** (rough)\n\n**Process / skill improvement**\n\n- What went wrong or what to improve\n- Which skills/commands were involved (optional if inferable)\n\n## Find the relevant docs (ship retro only)\n\n### PRD\n\n- `Outputs/Product PRDs/*<ticketId>*` or match by feature slug \n- If none: do **not** invent intent; add `Outputs/Product PRDs/YYYY-MM-DD_<ticketId?>_<short-slug>_retro-addendum.md`\n\n### TDD\n\n- `Outputs/Technical Docs/*<ticketId>*` or match by slug \n- If none: create `Outputs/Technical Docs/YYYY-MM-DD_<ticketId?>_<short-slug>.md` in **Post-build** style\n\n## Update rules (ship retro; keep diffs small)\n\n- Prefer **appending** dated sections.\n- Document **delta and why** when reality diverged from the plan.\n\n### PRD retro block\n\n```markdown\n## Retro (YYYY-MM-DD)\n- **What shipped**:\n- **What didn’t ship (and why)**:\n- **User impact observed**:\n- **Metrics / success signals**:\n- **Follow-ups**:\n```\n\n### TDD retro block\n\n```markdown\n## Retro (YYYY-MM-DD)\n### Delta vs plan\n- ...\n### Incidents / surprises\n- ...\n### Decisions that paid off\n- ...\n### Decisions we’d change next time\n- ...\n### Operational notes\n- Observability gaps:\n- Runbook updates needed:\n```\n\n## Learnings file (always for this command)\n\n**Path:** `Learnings/YYYY-MM-DD_<short-slug>.md` (create `Learnings/` if missing).\n\n**Template:**\n\n```markdown\n# Learning: [short title]\n\n## Context\n- **Work item** (or session topic):\n- **Date**: YYYY-MM-DD\n- **Type**: feature | bugfix | refactor | infra | process | skill-tuning | mixed\n- **Stack area**: (if relevant)\n- **Links**: PRs, docs, chats, dashboards\n\n## Explicit feedback (user)\n- Quotes or faithful paraphrase\n\n## Implicit signals / model–tool failures\n- Wrong assumptions, missed rules, tool errors, approval friction, plan drift\n\n## Affected skills / commands\n- path/to/file\n\n## Recommended changes (do not apply unless user requested apply in this run)\n- **File:** `...` — change: ...\n\n## Ship retro (if mode A or mixed)\n### What went well\n- ...\n### What went poorly\n- ...\n### Root causes (if relevant)\n- ...\n### Changes we’ll make next time\n- ...\n\n## Checklists / heuristics\n- If [condition], then [do this].\n- Prefer [pattern] over [anti-pattern] because [reason].\n```\n\n**Guidelines**\n\n- At least **one** concrete checklist line.\n- Record **trigger** and **early signal** for painful failures.\n- No names/blame; systems and process only.\n\n## Workflow (summary)\n\n1. Choose **mode A** and/or **B**; compute `<short-slug>`.\n2. **Mode A:** locate/update PRD + TDD; append retro blocks.\n3. **Mode B (or mixed):** classify feedback; list implicated skills; write recommendations.\n4. Write **`Learnings/...md`** (full template; omit sections that truly don’t apply).\n5. If user said **apply**: patch skills + mirror commands per sync rule above; summarize diffs.\n\n## Output (to the user)\n\n- Path to **`Learnings/...`**\n- Paths of updated PRD/TDD **if** mode A ran\n- If recommendations only: list **recommended** file edits; if applied: note **what changed**\n- **5–10 bullets** summarizing learnings and follow-ups", "variables": [], "notes": "Run anytime: ship retro (update PRD/TDD) and/or process–skill improvement from feedback; write a durable note under `Learnings/`.", "metadata": { "source": { "provider": "github-claude-commands", "repository": "https://github.com/ranerez1/BuilderOS", "path": ".claude/commands/09-learn.md", "ref": "a20d8a838d6f011fb642c995382e90a6a1ea38c9", "url": "https://github.com/ranerez1/BuilderOS/blob/a20d8a838d6f011fb642c995382e90a6a1ea38c9/.claude/commands/09-learn.md", "key": "ranerez1/BuilderOS/.claude/commands/09-learn.md" } } }

09-learn

About

Learn (retro + continuous improvement)

Modes (pick one per run; infer from context)

A) Ship retro

B) Process / skill improvement

Inputs (minimal; infer when possible)

Find the relevant docs (ship retro only)

PRD

TDD

Update rules (ship retro; keep diffs small)

PRD retro block

TDD retro block

Learnings file (always for this command)

Workflow (summary)

Output (to the user)

Install 09-learn 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