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.

pr - Prompt - OpenSmartRoute

Name: pr
Author: moduloMoments

Prompt file imported from moduloMoments/VINE (.claude/commands/pr.md). Copyright stays with the author.

pr — Template-Aware Pull Request Creation

Step 1: Understand Current State

Run these commands to gather context:

git status — check for uncommitted changes (warn if any exist)
git log develop..HEAD --oneline — see all commits on this branch
git diff develop...HEAD --stat — see which files changed

VINE uses a main-release / develop-integration branch model: feature branches cut from develop and PRs target develop (main holds only released states). If the current branch is main or develop, stop and tell the user to create a feature branch first.

If there are uncommitted changes, ask whether to proceed or commit first.

Step 2: Load the PR Template

Read .github/PULL_REQUEST_TEMPLATE.md if it exists. This is the structure the PR body must follow.

If no template exists, use a minimal format:

## What

## Why

## How to test

Step 3: Load Contributing Guidelines

Read CONTRIBUTING.md if it exists. Extract the PR submission rules — these inform what to check and how to frame the PR.

Key rules from VINE's contributing guide:

Branch from develop (the integration branch; main is release-only)
Keep changes focused — one concern per PR
Run /trellis to validate structural conventions across the skill files
Test commands in an actual VINE cycle if changing behavior
Describe what you changed and why

Step 4: Analyze Changes and Draft

Read git diff develop...HEAD to understand the full diff. Then:

Categorize the change — is this a command behavior change, docs update, new contributor tool, bug fix, or structural change?
Check focus — if changes span multiple unrelated concerns, warn the user and suggest splitting.
Check for skill changes — if any files under plugins/vine/skills/ were modified, note that /trellis validation and VINE cycle testing are expected.

Check for related issues — scan the open issues (gh issue list --state open) for any that this PR resolves. Match by topic, keywords, or explicit references in commit messages. If a match is found, include Closes #N in the Why section. Use AskUserQuestion to confirm the match before adding it — don't silently close issues.

Draft the PR body by filling in the template sections:

What — concise summary of what changed
Why — motivation, link to issue if one exists. Include Closes #N for issues this PR resolves.
How to test — specific steps a reviewer can follow
Checklist — pre-check items based on what actually changed (only check the box for VINE cycle testing if command behavior was modified)

Step 5: Confirm with User

Use AskUserQuestion to present the draft PR title and body. Ask:

Does the title capture the change? (suggest a concise title under 70 chars)
Does the body look right? Any context to add?
Ready to create, or want to edit?

Options: Create PR (Recommended), Edit title/body, Cancel

Step 6: Create the PR

Push the branch and create the PR:

git push -u origin HEAD
gh pr create --base develop --title "<title>" --body "<body>"

(Target develop explicitly — feature PRs integrate there, never into main. A release is a separate develop→main merge a maintainer cuts, not a /pr flow.)

After creation, display the PR URL.

If the change touches areas listed under "What's not ready for contribution yet" in CONTRIBUTING.md (new phases/commands, core phase flow, CI/automation), add a note in the PR body acknowledging this and reference any related issue discussion.

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

# pr — Template-Aware Pull Request Creation ## Step 1: Understand Current State Run these commands to gather context: 1. `git status` — check for uncommitted changes (warn if any exist) 2. `git log develop..HEAD --oneline` — see all commits on this branch 3. `git diff develop...HEAD --stat` — see which files changed VINE uses a `main`-release / `develop`-integration branch model: feature branches cut from `develop` and PRs target `develop` (`main` holds only released states). If the current branch is `main` or `develop`, stop and tell the user to create a feature branch first. If there are uncommitted changes, ask whether to proceed or commit first. ## Step 2: Load the PR Template Read `.github/PULL_REQUEST_TEMPLATE.md` if it exists. This is the structure the PR body must follow. If no template exists, use a minimal format: ``` ## What ## Why ## How to test ``` ## Step 3: Load Contributing Guidelines Read `CONTRIBUTING.md` if it exists. Extract the PR submission rules — these inform what to check and how to frame the PR. Key rules from VINE's contributing guide: - Branch from `develop` (the integration branch; `main` is release-only) - Keep changes focused — one concern per PR - Run `/trellis` to validate structural conventions across the skill files - Test commands in an actual VINE cycle if changing behavior - Describe what you changed and why ## Step 4: Analyze Changes and Draft Read `git diff develop...HEAD` to understand the full diff. Then: 1. **Categorize the change** — is this a command behavior change, docs update, new contributor tool, bug fix, or structural change? 2. **Check focus** — if changes span multiple unrelated concerns, warn the user and suggest splitting. 3. **Check for skill changes** — if any files under `plugins/vine/skills/` were modified, note that `/trellis` validation and VINE cycle testing are expected. **Check for related issues** — scan the open issues (`gh issue list --state open`) for any that this PR resolves. Match by topic, keywords, or explicit references in commit messages. If a match is found, include `Closes #N` in the Why section. Use `AskUserQuestion` to confirm the match before adding it — don't silently close issues. Draft the PR body by filling in the template sections: - **What** — concise summary of what changed - **Why** — motivation, link to issue if one exists. Include `Closes #N` for issues this PR resolves. - **How to test** — specific steps a reviewer can follow - **Checklist** — pre-check items based on what actually changed (only check the box for VINE cycle testing if command behavior was modified) ## Step 5: Confirm with User Use `AskUserQuestion` to present the draft PR title and body. Ask: - Does the title capture the change? (suggest a concise title under 70 chars) - Does the body look right? Any context to add? - Ready to create, or want to edit? Options: **Create PR (Recommended)**, **Edit title/body**, **Cancel** ## Step 6: Create the PR Push the branch and create the PR: ``` git push -u origin HEAD gh pr create --base develop --title "<title>" --body "<body>" ``` (Target `develop` explicitly — feature PRs integrate there, never into `main`. A release is a separate `develop`→`main` merge a maintainer cuts, not a `/pr` flow.) After creation, display the PR URL. If the change touches areas listed under "What's not ready for contribution yet" in CONTRIBUTING.md (new phases/commands, core phase flow, CI/automation), add a note in the PR body acknowledging this and reference any related issue discussion.

{ "prompt": "# pr — Template-Aware Pull Request Creation\n\n## Step 1: Understand Current State\n\nRun these commands to gather context:\n\n1. `git status` — check for uncommitted changes (warn if any exist)\n2. `git log develop..HEAD --oneline` — see all commits on this branch\n3. `git diff develop...HEAD --stat` — see which files changed\n\nVINE uses a `main`-release / `develop`-integration branch model: feature branches cut from\n`develop` and PRs target `develop` (`main` holds only released states). If the current branch is\n`main` or `develop`, stop and tell the user to create a feature branch first.\n\nIf there are uncommitted changes, ask whether to proceed or commit first.\n\n## Step 2: Load the PR Template\n\nRead `.github/PULL_REQUEST_TEMPLATE.md` if it exists. This is the structure the PR body must follow.\n\nIf no template exists, use a minimal format:\n\n```\n## What\n\n## Why\n\n## How to test\n```\n\n## Step 3: Load Contributing Guidelines\n\nRead `CONTRIBUTING.md` if it exists. Extract the PR submission rules — these inform what to check and how to frame the PR.\n\nKey rules from VINE's contributing guide:\n- Branch from `develop` (the integration branch; `main` is release-only)\n- Keep changes focused — one concern per PR\n- Run `/trellis` to validate structural conventions across the skill files\n- Test commands in an actual VINE cycle if changing behavior\n- Describe what you changed and why\n\n## Step 4: Analyze Changes and Draft\n\nRead `git diff develop...HEAD` to understand the full diff. Then:\n\n1. **Categorize the change** — is this a command behavior change, docs update, new contributor tool, bug fix, or structural change?\n2. **Check focus** — if changes span multiple unrelated concerns, warn the user and suggest splitting.\n3. **Check for skill changes** — if any files under `plugins/vine/skills/` were modified, note that `/trellis` validation and VINE cycle testing are expected.\n\n**Check for related issues** — scan the open issues (`gh issue list --state open`) for any that\nthis PR resolves. Match by topic, keywords, or explicit references in commit messages. If a\nmatch is found, include `Closes #N` in the Why section. Use `AskUserQuestion` to confirm the\nmatch before adding it — don't silently close issues.\n\nDraft the PR body by filling in the template sections:\n- **What** — concise summary of what changed\n- **Why** — motivation, link to issue if one exists. Include `Closes #N` for issues this PR resolves.\n- **How to test** — specific steps a reviewer can follow\n- **Checklist** — pre-check items based on what actually changed (only check the box for VINE cycle testing if command behavior was modified)\n\n## Step 5: Confirm with User\n\nUse `AskUserQuestion` to present the draft PR title and body. Ask:\n\n- Does the title capture the change? (suggest a concise title under 70 chars)\n- Does the body look right? Any context to add?\n- Ready to create, or want to edit?\n\nOptions: **Create PR (Recommended)**, **Edit title/body**, **Cancel**\n\n## Step 6: Create the PR\n\nPush the branch and create the PR:\n\n```\ngit push -u origin HEAD\ngh pr create --base develop --title \"<title>\" --body \"<body>\"\n```\n\n(Target `develop` explicitly — feature PRs integrate there, never into `main`. A release is a\nseparate `develop`→`main` merge a maintainer cuts, not a `/pr` flow.)\n\nAfter creation, display the PR URL.\n\nIf the change touches areas listed under \"What's not ready for contribution yet\" in CONTRIBUTING.md (new phases/commands, core phase flow, CI/automation), add a note in the PR body acknowledging this and reference any related issue discussion.", "variables": [], "notes": "Create a PR using the repo's template and contributing guidelines Tools: Bash, Read, Glob, Grep, AskUserQuestion.", "metadata": { "source": { "provider": "github-claude-commands", "repository": "https://github.com/moduloMoments/VINE", "path": ".claude/commands/pr.md", "ref": "710f1666e4bb208255f010ff5dbea9b2bd36937e", "url": "https://github.com/moduloMoments/VINE/blob/710f1666e4bb208255f010ff5dbea9b2bd36937e/.claude/commands/pr.md", "key": "moduloMoments/VINE/.claude/commands/pr.md" } } }

pr

About

pr — Template-Aware Pull Request Creation

Step 1: Understand Current State

Step 2: Load the PR Template

Step 3: Load Contributing Guidelines

Step 4: Analyze Changes and Draft

Step 5: Confirm with User

Step 6: Create the PR

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