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.

commit - Prompt - OpenSmartRoute

Name: commit
Author: mvdbos

Prompt file imported from mvdbos/php-spider (.github/prompts/commit.prompt.md). Copyright stays with the author.

CRITICAL: Only analyze actual repository changes. Ignore conversation history about what might be changed.

Shell Command Rules

Prefix commands with \ to bypass aliases (e.g., \git, \printf). Use --no-pager and pipe to \cat for git output.

Commit Message Format

<Title: max 72 chars, capitalized verb, imperative mood>
                                                         <- BLANK LINE
<Body: key changes and rationale, wrapped at 72 chars>

CRITICAL: The blank line between title and body is MANDATORY - git uses it to parse subject/body!

Title Rules

Start with capitalized verb: Add, Fix, Update, Remove, Refactor
Max 72 characters, imperative mood, no period
ASCII only - no emojis or Unicode
Be specific ("Fix null pointer in user validation" not "Fix bug")
Reference issues when applicable: "Fix #123: ..."

Body Rules

Keep it brief: Focus only on the main change, not minor or unrelated fixes
Summarize why this change was needed (problem solved, improvement gained, refactoring goal)
For commits with multiple unrelated changes, focus on the primary change only
Wrap at 72 characters, ASCII only
Use prose, not bullet lists or detailed file-by-file changes
Avoid listing each file or function changed; emphasize the overall impact

Workflow

1. Check Branch (REQUIRED FIRST STEP)

CRITICAL: Always check the current branch FIRST and create a feature branch if on master/main.

\git branch --show-current

If on master or main, you MUST create a feature branch before staging changes:

\git checkout -b feature/short-description  # or fix/short-description

Do NOT proceed to staging changes until you are on a feature branch.

2. Review and Stage Changes

\git status
\git --no-pager diff | cat                    # Review changes
\git add <files>                              # Stage relevant files
\git --no-pager diff --cached --stat | cat    # Verify staged

3. Draft Commit Message (MUST GET APPROVAL)

Present the message as a code block. Focus on the main change and its rationale, omitting secondary fixes or unrelated changes:

Refactor path finding to use executable location

Simplify path resolution by using os.Executable() instead of checking
multiple CWD paths. Reduces complexity and improves startup performance.

Note: This focuses on the primary refactoring goal, not every changed function or incidental fixes.

STOP and ask: "Would you like me to proceed with this commit message, or would you like to modify it?"

4. Create and Execute Commit (ONLY after approval)

Use exactly two -m flags by default: first for the title, second for the full body (single paragraph). If another paragraph is truly needed, add one extra -m for that paragraph—never one per line:

\git commit -m 'Title here' -m 'Body paragraph here.'
# If a distinct paragraph is clearer, add one extra -m (not one per line):
# \git commit -m 'Title here' -m 'Body paragraph here.' -m 'Second paragraph when required.'
\git --no-pager log -1 | cat                  # Verify commit

5. Push

BRANCH=$(\git branch --show-current)
\git push --dry-run 2>&1 | cat

Clean push: Execute \git push -u origin "$BRANCH" automatically
Force push required: STOP and ask user - never force push without explicit confirmation

Prohibited Actions

NEVER commit without showing draft and getting approval first
NEVER include conversation references ("as discussed", "per your request")
NEVER use generic messages ("Update files", "Changes", "WIP")
NEVER force push or rewrite history without explicit user confirmation

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

**CRITICAL: Only analyze actual repository changes. Ignore conversation history about what might be changed.** ## Shell Command Rules Prefix commands with `\` to bypass aliases (e.g., `\git`, `\printf`). Use `--no-pager` and pipe to `\cat` for git output. ## Commit Message Format ``` <Title: max 72 chars, capitalized verb, imperative mood> <- BLANK LINE <Body: key changes and rationale, wrapped at 72 chars> ``` **CRITICAL: The blank line between title and body is MANDATORY - git uses it to parse subject/body!** ### Title Rules - Start with capitalized verb: Add, Fix, Update, Remove, Refactor - Max 72 characters, imperative mood, no period - ASCII only - no emojis or Unicode - Be specific ("Fix null pointer in user validation" not "Fix bug") - Reference issues when applicable: "Fix #123: ..." ### Body Rules - **Keep it brief:** Focus only on the main change, not minor or unrelated fixes - Summarize why this change was needed (problem solved, improvement gained, refactoring goal) - For commits with multiple unrelated changes, focus on the primary change only - Wrap at 72 characters, ASCII only - Use prose, not bullet lists or detailed file-by-file changes - Avoid listing each file or function changed; emphasize the overall impact ## Workflow ### 1. Check Branch (REQUIRED FIRST STEP) **CRITICAL: Always check the current branch FIRST and create a feature branch if on master/main.** ```bash \git branch --show-current ``` **If on `master` or `main`, you MUST create a feature branch before staging changes:** ```bash \git checkout -b feature/short-description # or fix/short-description ``` Do NOT proceed to staging changes until you are on a feature branch. ### 2. Review and Stage Changes ```bash \git status \git --no-pager diff | cat # Review changes \git add <files> # Stage relevant files \git --no-pager diff --cached --stat | cat # Verify staged ``` ### 3. Draft Commit Message (MUST GET APPROVAL) Present the message as a code block. Focus on **the main change and its rationale**, omitting secondary fixes or unrelated changes: ``` Refactor path finding to use executable location Simplify path resolution by using os.Executable() instead of checking multiple CWD paths. Reduces complexity and improves startup performance. ``` Note: This focuses on the primary refactoring goal, not every changed function or incidental fixes. **STOP and ask: "Would you like me to proceed with this commit message, or would you like to modify it?"** ### 4. Create and Execute Commit (ONLY after approval) Use exactly two `-m` flags by default: first for the title, second for the full body (single paragraph). If another paragraph is truly needed, add one extra `-m` for that paragraph—never one per line: ```bash \git commit -m 'Title here' -m 'Body paragraph here.' # If a distinct paragraph is clearer, add one extra -m (not one per line): # \git commit -m 'Title here' -m 'Body paragraph here.' -m 'Second paragraph when required.' \git --no-pager log -1 | cat # Verify commit ``` ### 5. Push ```bash BRANCH=$(\git branch --show-current) \git push --dry-run 2>&1 | cat ``` - **Clean push**: Execute `\git push -u origin "$BRANCH"` automatically - **Force push required**: **STOP and ask user** - never force push without explicit confirmation ## Prohibited Actions - **NEVER** commit without showing draft and getting approval first - **NEVER** include conversation references ("as discussed", "per your request") - **NEVER** use generic messages ("Update files", "Changes", "WIP") - **NEVER** force push or rewrite history without explicit user confirmation

{ "prompt": "**CRITICAL: Only analyze actual repository changes. Ignore conversation history about what might be changed.**\n\n## Shell Command Rules\n\nPrefix commands with `\\` to bypass aliases (e.g., `\\git`, `\\printf`). Use `--no-pager` and pipe to `\\cat` for git output.\n\n## Commit Message Format\n\n```\n<Title: max 72 chars, capitalized verb, imperative mood>\n <- BLANK LINE\n<Body: key changes and rationale, wrapped at 72 chars>\n```\n\n**CRITICAL: The blank line between title and body is MANDATORY - git uses it to parse subject/body!**\n\n### Title Rules\n- Start with capitalized verb: Add, Fix, Update, Remove, Refactor\n- Max 72 characters, imperative mood, no period\n- ASCII only - no emojis or Unicode\n- Be specific (\"Fix null pointer in user validation\" not \"Fix bug\")\n- Reference issues when applicable: \"Fix #123: ...\"\n\n### Body Rules\n- **Keep it brief:** Focus only on the main change, not minor or unrelated fixes\n- Summarize why this change was needed (problem solved, improvement gained, refactoring goal)\n- For commits with multiple unrelated changes, focus on the primary change only\n- Wrap at 72 characters, ASCII only\n- Use prose, not bullet lists or detailed file-by-file changes\n- Avoid listing each file or function changed; emphasize the overall impact\n\n## Workflow\n\n### 1. Check Branch (REQUIRED FIRST STEP)\n\n**CRITICAL: Always check the current branch FIRST and create a feature branch if on master/main.**\n\n```bash\n\\git branch --show-current\n```\n\n**If on `master` or `main`, you MUST create a feature branch before staging changes:**\n```bash\n\\git checkout -b feature/short-description # or fix/short-description\n```\n\nDo NOT proceed to staging changes until you are on a feature branch.\n\n### 2. Review and Stage Changes\n```bash\n\\git status\n\\git --no-pager diff | cat # Review changes\n\\git add <files> # Stage relevant files\n\\git --no-pager diff --cached --stat | cat # Verify staged\n```\n\n### 3. Draft Commit Message (MUST GET APPROVAL)\n\nPresent the message as a code block. Focus on **the main change and its rationale**, omitting secondary fixes or unrelated changes:\n\n```\nRefactor path finding to use executable location\n\nSimplify path resolution by using os.Executable() instead of checking\nmultiple CWD paths. Reduces complexity and improves startup performance.\n```\n\nNote: This focuses on the primary refactoring goal, not every changed function or incidental fixes.\n\n**STOP and ask: \"Would you like me to proceed with this commit message, or would you like to modify it?\"**\n\n### 4. Create and Execute Commit (ONLY after approval)\n\nUse exactly two `-m` flags by default: first for the title, second for the full body (single paragraph). If another paragraph is truly needed, add one extra `-m` for that paragraph—never one per line:\n```bash\n\\git commit -m 'Title here' -m 'Body paragraph here.'\n# If a distinct paragraph is clearer, add one extra -m (not one per line):\n# \\git commit -m 'Title here' -m 'Body paragraph here.' -m 'Second paragraph when required.'\n\\git --no-pager log -1 | cat # Verify commit\n```\n\n### 5. Push\n\n```bash\nBRANCH=$(\\git branch --show-current)\n\\git push --dry-run 2>&1 | cat\n```\n\n- **Clean push**: Execute `\\git push -u origin \"$BRANCH\"` automatically\n- **Force push required**: **STOP and ask user** - never force push without explicit confirmation\n\n## Prohibited Actions\n\n- **NEVER** commit without showing draft and getting approval first\n- **NEVER** include conversation references (\"as discussed\", \"per your request\")\n- **NEVER** use generic messages (\"Update files\", \"Changes\", \"WIP\")\n- **NEVER** force push or rewrite history without explicit user confirmation", "variables": [], "notes": "Commit current changes with proper formatting and user approval", "metadata": { "source": { "provider": "github-prompts", "repository": "https://github.com/mvdbos/php-spider", "path": ".github/prompts/commit.prompt.md", "ref": "522411fbda6af83c896f1d35cdc983ea99b2587c", "url": "https://github.com/mvdbos/php-spider/blob/522411fbda6af83c896f1d35cdc983ea99b2587c/.github/prompts/commit.prompt.md", "key": "mvdbos/php-spider/.github/prompts/commit.prompt.md" } } }

commit

About

Shell Command Rules

Commit Message Format

Title Rules

Body Rules

Workflow

1. Check Branch (REQUIRED FIRST STEP)

2. Review and Stage Changes

3. Draft Commit Message (MUST GET APPROVAL)

4. Create and Execute Commit (ONLY after approval)

5. Push

Prohibited Actions

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