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.

generate-pr-description - Prompt

Name: generate-pr-description
Author: vg-public

Prompt file imported from vg-public/agents-demo (.github/prompts/generate-pr-description.prompt.md). Copyright stays with the author.

Generate PR Description

Generate a structured pull request description from the current code changes.

Instructions

Identify the changed/added files
Understand the purpose of the changes
Generate the PR description in the format below

PR Template

## Summary
<!-- One-paragraph description of what this PR does and why -->

## Type of Change
- [ ] New feature (non-breaking change that adds functionality)
- [ ] Bug fix (non-breaking change that fixes an issue)
- [ ] Breaking change (fix or feature that causes existing functionality to change)
- [ ] Refactoring (no functional changes)
- [ ] Documentation update
- [ ] Database migration

## Changes

### Added
- `ClassName.java` — description of what was added

### Modified
- `ClassName.java` — description of what changed

### Database
- `V<N>__description.sql` — schema change description

## API Changes
<!-- Include if REST endpoints were added or modified -->

| Method | Endpoint | Description |
|--------|----------|-------------|
| POST   | `/api/v1/products` | Create a new product |

## Testing

### Unit Tests
- `ServiceTest` — X tests covering Y scenarios

### Integration Tests
- `ControllerTest` — X tests covering Y scenarios

### Manual Testing
<!-- Steps to manually verify if needed -->
1. Start the application
2. Send POST to `/api/v1/products` with: `{ ... }`
3. Verify 201 response with generated ID

## Checklist
- [ ] Code compiles without errors
- [ ] All new and existing tests pass
- [ ] No new SonarQube/Fortify findings
- [ ] Javadoc added for public methods
- [ ] API contract updated (if endpoints changed)
- [ ] No hardcoded secrets or credentials

Rules

Keep the summary concise — one paragraph
List every changed file with a brief description
If database migrations are included, call them out explicitly
Include specific API endpoint table if REST changes are involved
Don't include generated files (target/, .class) in the changes list

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

# Generate PR Description Generate a **structured pull request description** from the current code changes. ## Instructions 1. Identify the changed/added files 2. Understand the purpose of the changes 3. Generate the PR description in the format below ## PR Template ```markdown ## Summary  ## Type of Change - [ ] New feature (non-breaking change that adds functionality) - [ ] Bug fix (non-breaking change that fixes an issue) - [ ] Breaking change (fix or feature that causes existing functionality to change) - [ ] Refactoring (no functional changes) - [ ] Documentation update - [ ] Database migration ## Changes ### Added - `ClassName.java` — description of what was added ### Modified - `ClassName.java` — description of what changed ### Database - `V<N>__description.sql` — schema change description ## API Changes  | Method | Endpoint | Description | |--------|----------|-------------| | POST | `/api/v1/products` | Create a new product | ## Testing ### Unit Tests - `ServiceTest` — X tests covering Y scenarios ### Integration Tests - `ControllerTest` — X tests covering Y scenarios ### Manual Testing  1. Start the application 2. Send POST to `/api/v1/products` with: `{ ... }` 3. Verify 201 response with generated ID ## Checklist - [ ] Code compiles without errors - [ ] All new and existing tests pass - [ ] No new SonarQube/Fortify findings - [ ] Javadoc added for public methods - [ ] API contract updated (if endpoints changed) - [ ] No hardcoded secrets or credentials ``` ## Rules - Keep the summary concise — one paragraph - List every changed file with a brief description - If database migrations are included, call them out explicitly - Include specific API endpoint table if REST changes are involved - Don't include generated files (target/, .class) in the changes list

{ "prompt": "# Generate PR Description\n\nGenerate a **structured pull request description** from the current code changes.\n\n## Instructions\n\n1. Identify the changed/added files\n2. Understand the purpose of the changes\n3. Generate the PR description in the format below\n\n## PR Template\n\n```markdown\n## Summary\n\n\n## Type of Change\n- [ ] New feature (non-breaking change that adds functionality)\n- [ ] Bug fix (non-breaking change that fixes an issue)\n- [ ] Breaking change (fix or feature that causes existing functionality to change)\n- [ ] Refactoring (no functional changes)\n- [ ] Documentation update\n- [ ] Database migration\n\n## Changes\n\n### Added\n- `ClassName.java` — description of what was added\n\n### Modified\n- `ClassName.java` — description of what changed\n\n### Database\n- `V<N>__description.sql` — schema change description\n\n## API Changes\n\n\n| Method | Endpoint | Description |\n|--------|----------|-------------|\n| POST | `/api/v1/products` | Create a new product |\n\n## Testing\n\n### Unit Tests\n- `ServiceTest` — X tests covering Y scenarios\n\n### Integration Tests\n- `ControllerTest` — X tests covering Y scenarios\n\n### Manual Testing\n\n1. Start the application\n2. Send POST to `/api/v1/products` with: `{ ... }`\n3. Verify 201 response with generated ID\n\n## Checklist\n- [ ] Code compiles without errors\n- [ ] All new and existing tests pass\n- [ ] No new SonarQube/Fortify findings\n- [ ] Javadoc added for public methods\n- [ ] API contract updated (if endpoints changed)\n- [ ] No hardcoded secrets or credentials\n```\n\n## Rules\n\n- Keep the summary concise — one paragraph\n- List every changed file with a brief description\n- If database migrations are included, call them out explicitly\n- Include specific API endpoint table if REST changes are involved\n- Don't include generated files (target/, .class) in the changes list", "variables": [], "notes": "Use when: generating a pull request description from code changes — creates a structured PR description with summary, changes, testing, and checklist. Tools: read, search. Arguments: Describe the PR or point to the changed files — e.g., 'Generate PR description for the product CRUD feature'.", "metadata": { "source": { "provider": "github-prompts", "repository": "https://github.com/vg-public/agents-demo", "path": ".github/prompts/generate-pr-description.prompt.md", "ref": "43188a8a7efc95edb69d1b40c259de5ca160e7da", "url": "https://github.com/vg-public/agents-demo/blob/43188a8a7efc95edb69d1b40c259de5ca160e7da/.github/prompts/generate-pr-description.prompt.md", "key": "vg-public/agents-demo/.github/prompts/generate-pr-description.prompt.md" } } }

generate-pr-description

About

Generate PR Description

Instructions

PR Template

Rules

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