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.

cycle - Prompt - OpenSmartRoute

Name: cycle
Author: FHIR-IQ

Prompt file imported from FHIR-IQ/openquality (.claude/commands/cycle.md). Copyright stays with the author.

Run exactly one cycle of the development loop. docs/operating-model.md is the policy; read it first and follow it over anything here. Never do what it reserves for the maintainer. Never edit docs/operating-model.md, .claude/agents/, .claude/commands/ or .github/workflows/.

1. Check the line

gh issue list --label stop-the-line --state open. If any: report and stop.
gh run list --branch main --workflow CI --limit 1. If the latest run failed, the work item is making main green. Go to step 3.

2. Pull one work item

gh pr list --label loop --state open. If one exists, it is the work item: fix its failing checks or council findings, or close it if it is no longer wanted. Go to step 3.
Otherwise take the oldest issue labelled ready (gh issue list --label ready --state open).
Otherwise check pnpm oq validate-all measures/cms-fhir-2026 measures/community for a finding whose knowledge entry records a decided fix.
If there is nothing, report "idle: no demand" and stop. Do not invent work.

If the item is too big for one PR under the batch rule, split it into issues, comment the split on the original issue, and take the first slice.

3. Build it

git checkout -b loop/<short-name> origin/main.
Go and see: read the code, corpus and upstream that the item concerns.
Write the failing test first, then the change.
Run pnpm test, pnpm typecheck and pnpm oq validate-all measures/cms-fhir-2026 measures/community. If the importer changed, also pnpm oq-import 2026-08-01 && git diff --exit-code -- measures/. If a catalogue input changed, run pnpm build-library.
Anything else you notice that is wrong becomes an issue or a knowledge entry, not part of this diff.

4. Convene the council

Commit, then run the four reviewers in parallel with the Agent tool: council-provenance, council-standards, council-verification, council-lean. Give each the work item (issue number and text) and tell it to review git diff origin/main...HEAD.

Any BLOCK: fix the findings, commit, and convene all four again. At most two rounds.
Still blocked after two rounds: push, open the PR with label loop and needs-maintainer, put the open findings in the body, and stop.

5. Ship

Push and open the PR with label loop. The body holds: the work item it closes (Closes #n), what changed, how it was verified, and each reviewer's verdict and findings with how they were resolved. End with the attribution line from the session.
Only with four PASS verdicts: gh pr merge --auto --squash. GitHub merges once the required checks pass.

6. Report

End with three lines: the work item, the outcome (merged-pending-checks, needs-maintainer, idle, stopped), and the link.

Install cycle 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 exactly one cycle of the development loop. `docs/operating-model.md` is the policy; read it first and follow it over anything here. Never do what it reserves for the maintainer. Never edit `docs/operating-model.md`, `.claude/agents/`, `.claude/commands/` or `.github/workflows/`. ## 1. Check the line - `gh issue list --label stop-the-line --state open`. If any: report and stop. - `gh run list --branch main --workflow CI --limit 1`. If the latest run failed, the work item is making `main` green. Go to step 3. ## 2. Pull one work item - `gh pr list --label loop --state open`. If one exists, it is the work item: fix its failing checks or council findings, or close it if it is no longer wanted. Go to step 3. - Otherwise take the oldest issue labelled `ready` (`gh issue list --label ready --state open`). - Otherwise check `pnpm oq validate-all measures/cms-fhir-2026 measures/community` for a finding whose knowledge entry records a decided fix. - If there is nothing, report "idle: no demand" and stop. Do not invent work. If the item is too big for one PR under the batch rule, split it into issues, comment the split on the original issue, and take the first slice. ## 3. Build it 1. `git checkout -b loop/<short-name> origin/main`. 2. Go and see: read the code, corpus and upstream that the item concerns. 3. Write the failing test first, then the change. 4. Run `pnpm test`, `pnpm typecheck` and `pnpm oq validate-all measures/cms-fhir-2026 measures/community`. If the importer changed, also `pnpm oq-import 2026-08-01 && git diff --exit-code -- measures/`. If a catalogue input changed, run `pnpm build-library`. 5. Anything else you notice that is wrong becomes an issue or a knowledge entry, not part of this diff. ## 4. Convene the council Commit, then run the four reviewers in parallel with the Agent tool: `council-provenance`, `council-standards`, `council-verification`, `council-lean`. Give each the work item (issue number and text) and tell it to review `git diff origin/main...HEAD`. - Any BLOCK: fix the findings, commit, and convene all four again. At most two rounds. - Still blocked after two rounds: push, open the PR with label `loop` and `needs-maintainer`, put the open findings in the body, and stop. ## 5. Ship - Push and open the PR with label `loop`. The body holds: the work item it closes (`Closes #n`), what changed, how it was verified, and each reviewer's verdict and findings with how they were resolved. End with the attribution line from the session. - Only with four PASS verdicts: `gh pr merge --auto --squash`. GitHub merges once the required checks pass. ## 6. Report End with three lines: the work item, the outcome (merged-pending-checks, needs-maintainer, idle, stopped), and the link.

{ "prompt": "Run exactly one cycle of the development loop. `docs/operating-model.md` is the policy;\nread it first and follow it over anything here. Never do what it reserves for the\nmaintainer. Never edit `docs/operating-model.md`, `.claude/agents/`, `.claude/commands/`\nor `.github/workflows/`.\n\n## 1. Check the line\n\n- `gh issue list --label stop-the-line --state open`. If any: report and stop.\n- `gh run list --branch main --workflow CI --limit 1`. If the latest run failed, the work\n item is making `main` green. Go to step 3.\n\n## 2. Pull one work item\n\n- `gh pr list --label loop --state open`. If one exists, it is the work item: fix its\n failing checks or council findings, or close it if it is no longer wanted. Go to step 3.\n- Otherwise take the oldest issue labelled `ready` (`gh issue list --label ready --state open`).\n- Otherwise check `pnpm oq validate-all measures/cms-fhir-2026 measures/community` for a\n finding whose knowledge entry records a decided fix.\n- If there is nothing, report \"idle: no demand\" and stop. Do not invent work.\n\nIf the item is too big for one PR under the batch rule, split it into issues, comment\nthe split on the original issue, and take the first slice.\n\n## 3. Build it\n\n1. `git checkout -b loop/<short-name> origin/main`.\n2. Go and see: read the code, corpus and upstream that the item concerns.\n3. Write the failing test first, then the change.\n4. Run `pnpm test`, `pnpm typecheck` and\n `pnpm oq validate-all measures/cms-fhir-2026 measures/community`. If the importer\n changed, also `pnpm oq-import 2026-08-01 && git diff --exit-code -- measures/`.\n If a catalogue input changed, run `pnpm build-library`.\n5. Anything else you notice that is wrong becomes an issue or a knowledge entry, not\n part of this diff.\n\n## 4. Convene the council\n\nCommit, then run the four reviewers in parallel with the Agent tool:\n`council-provenance`, `council-standards`, `council-verification`, `council-lean`.\nGive each the work item (issue number and text) and tell it to review\n`git diff origin/main...HEAD`.\n\n- Any BLOCK: fix the findings, commit, and convene all four again. At most two rounds.\n- Still blocked after two rounds: push, open the PR with label `loop` and\n `needs-maintainer`, put the open findings in the body, and stop.\n\n## 5. Ship\n\n- Push and open the PR with label `loop`. The body holds: the work item it closes\n (`Closes #n`), what changed, how it was verified, and each reviewer's verdict and\n findings with how they were resolved. End with the attribution line from the session.\n- Only with four PASS verdicts: `gh pr merge --auto --squash`. GitHub merges once the\n required checks pass.\n\n## 6. Report\n\nEnd with three lines: the work item, the outcome (merged-pending-checks,\nneeds-maintainer, idle, stopped), and the link.", "variables": [], "notes": "Run one cycle of the Open Quality development loop under docs/operating-model.md", "metadata": { "source": { "provider": "github-claude-commands", "repository": "https://github.com/FHIR-IQ/openquality", "path": ".claude/commands/cycle.md", "ref": "48e113cc4d74c35a7241784bed52590c06e95999", "url": "https://github.com/FHIR-IQ/openquality/blob/48e113cc4d74c35a7241784bed52590c06e95999/.claude/commands/cycle.md", "key": "FHIR-IQ/openquality/.claude/commands/cycle.md" } } }

cycle

About

1. Check the line

2. Pull one work item

3. Build it

4. Convene the council

5. Ship

6. Report

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