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.

ship - Prompt - OpenSmartRoute

Name: ship
Author: 8408323

Prompt file imported from 8408323/ha-lymow (.github/prompts/ship.prompt.md). Fill in {{args}} before use. Copyright stays with the author.

Ship the current changes through commit, push, and PR creation. Confirm with the user before each step using the an interactive confirmation.

Step 1: Scan

Run git status to see all changed, staged, and untracked files
Run git diff to see what changed (staged + unstaged)
Run git log --oneline -5 to see recent commit style
Present a clear summary to the user:
- Files modified
- Files added
- Files deleted
- Untracked files
If there are no changes, tell the user and stop

Step 2: Stage & Commit

Propose which files to stage. Never stage these:
- Secrets: .env*, *.pem, *.key, credentials.json
- Lock files: package-lock.json, yarn.lock, pnpm-lock.yaml (unless intentionally updated)
- Generated: *.gen.ts, *.generated.*, *.min.js, *.min.css
- Build output: dist/, build/, .next/, __pycache__/
- Dependencies: node_modules/, vendor/, .venv/
- OS/editor: .DS_Store, Thumbs.db, *.swp, .idea/, .vscode/settings.json
Draft a commit message based on the changes, matching the repo's existing commit style
ASK the user to confirm or edit: show the exact files to stage and the proposed commit message
Only after confirmation: stage the files and create the commit
If the commit fails (e.g., pre-commit hook), fix the issue and try again with a NEW commit

Step 3: Push

Check if the current branch has an upstream remote
If not, propose creating one with git push -u origin <branch>
ASK the user to confirm before pushing
Only after confirmation: push to remote

Step 4: Pull Request

Check if a PR already exists for this branch (gh pr view. If it exists, show the URL and stop)
Analyze ALL commits on this branch vs the base branch (not just the latest commit)
Draft a PR title (under 72 chars) and body with:
- Summary: 2-4 bullet points
- Test plan: how to verify
ASK the user to confirm or edit the title and body
Only after confirmation: create the PR with gh pr create
Show the PR URL when done

Step 5: Review & merge discipline

Follow the PR Review Discipline rule. The critical point: a green, "clean"/mergeable PR is not ready to merge if a reviewer is still running — Copilot/Codex can be mid-review with no comments posted yet. Wait for the round to finish, not just for checks to pass.

Batching: if you know you'll make several pushes, make them all first, then run this loop once on the final commit. Don't re-request review on intermediate pushes — it churns reviewers on states you're about to change.

Once the PR is open (or after the final push you want reviewed):

Wait for the review round to finish. gh has no watch for reviews, so poll: sleep ~2 min between checks, up to ~10 min.
```
gh pr view <n> --json reviewRequests,latestReviews,reviewDecision
gh api repos/{owner}/{repo}/issues/<n>/timeline   # shows "review_requested" / Copilot "is reviewing"
```
A reviewer still in reviewRequests (or shown reviewing in the timeline) is not done — keep waiting. The round is finished when every expected reviewer (Copilot, Codex, …) has posted its review/comments on the current head commit and none remain pending. Don't evaluate comments or merge until then.
- Timeout path (deterministic): if ~10 min elapses and an expected reviewer still hasn't posted for the current commit, re-request that reviewer once. If it still doesn't engage after another short wait, stop polling and tell the user which reviewer is missing — ask whether to wait longer or proceed without it. Never wait indefinitely, and never merge counting a missing reviewer as approval.
Address each comment: implement it, or decline with a short reply. Resolve the thread for each handled comment (gh api graphql → resolveReviewThread). Don't resolve a thread that asks a question / for more info — reply and leave it open.

Pushing fixes is a new push to review. Resolve the fixed threads, then re-request in one comment, and go back to step 1:

gh pr comment <n> --body "Addressed the feedback — @claude review, @codex review, @codex[agent] review, @copilot review"

Merge only when every reviewer has finished the latest round with no remaining comments, all threads are resolved, and CI is green (gh pr checks <n> --watch --fail-fast) — and the user explicitly confirms. Never merge while a review is in progress or on silence.

Rules

NEVER skip a confirmation step. Each step requires explicit user approval
NEVER force-push
NEVER commit .env, secrets, or credential files
If the user says "skip" at any step, skip that step and move to the next
If {{args}} is provided, use it as the commit message / PR title

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

Ship the current changes through commit, push, and PR creation. Confirm with the user before each step using the an interactive confirmation. ## Step 1: Scan - Run `git status` to see all changed, staged, and untracked files - Run `git diff` to see what changed (staged + unstaged) - Run `git log --oneline -5` to see recent commit style - Present a clear summary to the user: - Files modified - Files added - Files deleted - Untracked files - If there are no changes, tell the user and stop ## Step 2: Stage & Commit - Propose which files to stage. **Never stage** these: - Secrets: `.env*`, `*.pem`, `*.key`, `credentials.json` - Lock files: `package-lock.json`, `yarn.lock`, `pnpm-lock.yaml` (unless intentionally updated) - Generated: `*.gen.ts`, `*.generated.*`, `*.min.js`, `*.min.css` - Build output: `dist/`, `build/`, `.next/`, `__pycache__/` - Dependencies: `node_modules/`, `vendor/`, `.venv/` - OS/editor: `.DS_Store`, `Thumbs.db`, `*.swp`, `.idea/`, `.vscode/settings.json` - Draft a commit message based on the changes, matching the repo's existing commit style - **ASK the user to confirm or edit**: show the exact files to stage and the proposed commit message - Only after confirmation: stage the files and create the commit - If the commit fails (e.g., pre-commit hook), fix the issue and try again with a NEW commit ## Step 3: Push - Check if the current branch has an upstream remote - If not, propose creating one with `git push -u origin <branch>` - **ASK the user to confirm** before pushing - Only after confirmation: push to remote ## Step 4: Pull Request - Check if a PR already exists for this branch (`gh pr view`. If it exists, show the URL and stop) - Analyze ALL commits on this branch vs the base branch (not just the latest commit) - Draft a PR title (under 72 chars) and body with: - Summary: 2-4 bullet points - Test plan: how to verify - **ASK the user to confirm or edit** the title and body - Only after confirmation: create the PR with `gh pr create` - Show the PR URL when done ## Step 5: Review & merge discipline Follow the **PR Review Discipline** rule. The critical point: a green, "clean"/mergeable PR is **not** ready to merge if a reviewer is still running — Copilot/Codex can be mid-review with no comments posted yet. Wait for the round to *finish*, not just for checks to pass. **Batching:** if you know you'll make several pushes, make them all first, *then* run this loop once on the final commit. Don't re-request review on intermediate pushes — it churns reviewers on states you're about to change. Once the PR is open (or after the final push you want reviewed): 1. **Wait for the review round to finish.** `gh` has no watch for reviews, so poll: sleep ~2 min between checks, up to ~10 min. ``` gh pr view <n> --json reviewRequests,latestReviews,reviewDecision gh api repos/{owner}/{repo}/issues/<n>/timeline # shows "review_requested" / Copilot "is reviewing" ``` A reviewer still in `reviewRequests` (or shown reviewing in the timeline) is **not done** — keep waiting. The round is finished when every expected reviewer (Copilot, Codex, …) has posted its review/comments on the **current head commit** and none remain pending. Don't evaluate comments or merge until then. - **Timeout path (deterministic):** if ~10 min elapses and an expected reviewer still hasn't posted for the current commit, re-request that reviewer once. If it still doesn't engage after another short wait, stop polling and tell the user which reviewer is missing — ask whether to wait longer or proceed without it. Never wait indefinitely, and never merge counting a missing reviewer as approval. 2. **Address each comment:** implement it, or decline with a short reply. **Resolve the thread** for each handled comment (`gh api graphql` → `resolveReviewThread`). **Don't resolve** a thread that asks a question / for more info — reply and leave it open. 3. **Pushing fixes is a new push to review.** Resolve the fixed threads, then re-request in one comment, and go back to step 1: ``` gh pr comment <n> --body "Addressed the feedback — @claude review, @codex review, @codex[agent] review, @copilot review" ``` 4. **Merge only when** every reviewer has *finished* the latest round with no remaining comments, all threads are resolved, and CI is green (`gh pr checks <n> --watch --fail-fast`) — **and** the user explicitly confirms. Never merge while a review is in progress or on silence. ## Rules - NEVER skip a confirmation step. Each step requires explicit user approval - NEVER force-push - NEVER commit .env, secrets, or credential files - If the user says "skip" at any step, skip that step and move to the next - If {{args}} is provided, use it as the commit message / PR title

{ "prompt": "\n\nShip the current changes through commit, push, and PR creation. Confirm with the user before each step using the an interactive confirmation.\n\n## Step 1: Scan\n\n- Run `git status` to see all changed, staged, and untracked files\n- Run `git diff` to see what changed (staged + unstaged)\n- Run `git log --oneline -5` to see recent commit style\n- Present a clear summary to the user:\n - Files modified\n - Files added\n - Files deleted\n - Untracked files\n- If there are no changes, tell the user and stop\n\n## Step 2: Stage & Commit\n\n- Propose which files to stage. **Never stage** these:\n - Secrets: `.env*`, `*.pem`, `*.key`, `credentials.json`\n - Lock files: `package-lock.json`, `yarn.lock`, `pnpm-lock.yaml` (unless intentionally updated)\n - Generated: `*.gen.ts`, `*.generated.*`, `*.min.js`, `*.min.css`\n - Build output: `dist/`, `build/`, `.next/`, `__pycache__/`\n - Dependencies: `node_modules/`, `vendor/`, `.venv/`\n - OS/editor: `.DS_Store`, `Thumbs.db`, `*.swp`, `.idea/`, `.vscode/settings.json`\n- Draft a commit message based on the changes, matching the repo's existing commit style\n- **ASK the user to confirm or edit**: show the exact files to stage and the proposed commit message\n- Only after confirmation: stage the files and create the commit\n- If the commit fails (e.g., pre-commit hook), fix the issue and try again with a NEW commit\n\n## Step 3: Push\n\n- Check if the current branch has an upstream remote\n- If not, propose creating one with `git push -u origin <branch>`\n- **ASK the user to confirm** before pushing\n- Only after confirmation: push to remote\n\n## Step 4: Pull Request\n\n- Check if a PR already exists for this branch (`gh pr view`. If it exists, show the URL and stop)\n- Analyze ALL commits on this branch vs the base branch (not just the latest commit)\n- Draft a PR title (under 72 chars) and body with:\n - Summary: 2-4 bullet points\n - Test plan: how to verify\n- **ASK the user to confirm or edit** the title and body\n- Only after confirmation: create the PR with `gh pr create`\n- Show the PR URL when done\n\n## Step 5: Review & merge discipline\n\nFollow the **PR Review Discipline** rule. The critical point: a green, \"clean\"/mergeable PR is **not** ready to merge if a reviewer is still running — Copilot/Codex can be mid-review with no comments posted yet. Wait for the round to *finish*, not just for checks to pass.\n\n**Batching:** if you know you'll make several pushes, make them all first, *then* run this loop once on the final commit. Don't re-request review on intermediate pushes — it churns reviewers on states you're about to change.\n\nOnce the PR is open (or after the final push you want reviewed):\n\n1. **Wait for the review round to finish.** `gh` has no watch for reviews, so poll: sleep ~2 min between checks, up to ~10 min.\n ```\n gh pr view <n> --json reviewRequests,latestReviews,reviewDecision\n gh api repos/{owner}/{repo}/issues/<n>/timeline # shows \"review_requested\" / Copilot \"is reviewing\"\n ```\n A reviewer still in `reviewRequests` (or shown reviewing in the timeline) is **not done** — keep waiting. The round is finished when every expected reviewer (Copilot, Codex, …) has posted its review/comments on the **current head commit** and none remain pending. Don't evaluate comments or merge until then.\n - **Timeout path (deterministic):** if ~10 min elapses and an expected reviewer still hasn't posted for the current commit, re-request that reviewer once. If it still doesn't engage after another short wait, stop polling and tell the user which reviewer is missing — ask whether to wait longer or proceed without it. Never wait indefinitely, and never merge counting a missing reviewer as approval.\n2. **Address each comment:** implement it, or decline with a short reply. **Resolve the thread** for each handled comment (`gh api graphql` → `resolveReviewThread`). **Don't resolve** a thread that asks a question / for more info — reply and leave it open.\n3. **Pushing fixes is a new push to review.** Resolve the fixed threads, then re-request in one comment, and go back to step 1:\n ```\n gh pr comment <n> --body \"Addressed the feedback — @claude review, @codex review, @codex[agent] review, @copilot review\"\n ```\n4. **Merge only when** every reviewer has *finished* the latest round with no remaining comments, all threads are resolved, and CI is green (`gh pr checks <n> --watch --fail-fast`) — **and** the user explicitly confirms. Never merge while a review is in progress or on silence.\n\n## Rules\n\n- NEVER skip a confirmation step. Each step requires explicit user approval\n- NEVER force-push\n- NEVER commit .env, secrets, or credential files\n- If the user says \"skip\" at any step, skip that step and move to the next\n- If {{args}} is provided, use it as the commit message / PR title", "variables": [ "args" ], "notes": "Scan changes, commit, push, and create a PR. With confirmation at each step", "metadata": { "source": { "provider": "github-prompts", "repository": "https://github.com/8408323/ha-lymow", "path": ".github/prompts/ship.prompt.md", "ref": "29c2caa257a909bd8fac5f1c8eab8120853607f0", "url": "https://github.com/8408323/ha-lymow/blob/29c2caa257a909bd8fac5f1c8eab8120853607f0/.github/prompts/ship.prompt.md", "key": "8408323/ha-lymow/.github/prompts/ship.prompt.md" } } }

ship

About

Step 1: Scan

Step 2: Stage & Commit

Step 3: Push

Step 4: Pull Request

Step 5: Review & merge discipline

Rules

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