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.

README - Prompt - OpenSmartRoute

Name: README
Author: BabakBar

Prompt file imported from BabakBar/vps-dashboard-py (.claude/commands/README.md). Fill in {{arguments}} before use. Copyright stays with the author.

Claude Code Custom Commands

Custom slash commands let you create shortcuts for repetitive tasks. Commands are simple markdown files with prompts that get expanded when you type /command-name.

What Are Custom Commands?

Commands are:

Simple text files with .md extension
Prompt expansions that run when you type /command-name
Task-specific shortcuts for repetitive workflows
Easy to create - just markdown with optional argument support

When to Create Your First Command

Phase 2 (after completing Project 3)

By Project 3, you'll have noticed repetitive tasks:

Running lint + format before every commit
Setting up new Python projects with the same structure
Running tests with coverage reports
Creating git commits with proper formatting

These patterns are perfect candidates for commands!

Available Commands

⏸️ DORMANT: commit.md

Phase: 2+ (Enable after Project 3) Purpose: Structured git commit workflow with good message formatting

WHEN TO ENABLE: After completing Project 3, when you're comfortable with git workflows and ready for structured commits.

TO ACTIVATE: Just start using it! The file is already in place:

/commit

The command will:

Run git status and git diff to show changes
Ask you to describe what changed and why
Format the commit message properly
Execute the commit with co-authored-by attribution

⏸️ DORMANT: code-review.md

Phase: 2+ (Enable after Project 3) Purpose: Manual trigger for code review before committing

TO USE:

/code-review

Invokes the appropriate reviewer agent (learning-reviewer in Phase 1-2, code-reviewer in Phase 3+).

Creating Your First Command

Step 1: Identify a Repetitive Task

After Project 3, notice what you type repeatedly. Common examples:

uv run ruff check . && uv run ruff format . && uv run pytest --cov
uv init new-project && cd new-project && uv add psutil requests
Commit message templates for different change types

Step 2: Create the Command File

Example: /quick-check command

Create .claude/commands/quick-check.md:

Run linting, formatting, and tests with coverage.

Execute these commands sequentially:
1. uv run ruff check .
2. uv run ruff format .
3. uv run pytest --cov=src tests/ -v

Report results for each step clearly.

Step 3: Use It!

/quick-check

That's it! Claude will expand your prompt and execute the workflow.

Command Templates

Quality Check Command

Run code quality checks:
1. Lint: uv run ruff check .
2. Format: uv run ruff format .
3. Type check: uv run pyright
4. Tests: uv run pytest --cov

Stop if any check fails and report the issue.

Project Setup Command

Set up a new Python project with modern tooling:

1. Create project: uv init {{arguments}}
2. Add dependencies: uv add psutil tabulate click rich
3. Add dev dependencies: uv add --dev pytest pytest-cov ruff pyright
4. Create src/ directory structure
5. Initialize git repository
6. Create .gitignore for Python
7. Show next steps

Project name: {{arguments}}

Docker Build & Run Command

Build and run the Docker container for this project:

1. Build: docker build -t vps-dashboard:latest .
2. Run: docker run --rm -p 8000:8000 vps-dashboard:latest
3. Show container logs

If build fails, explain the error clearly.

Command Arguments

Use {{arguments}} in your command to accept input:

Command file:

Create a new feature branch and switch to it.

Branch name: {{arguments}}

Execute: git checkout -b feature/{{arguments}}

Usage:

/new-branch api-metrics-endpoint
# Expands to: git checkout -b feature/api-metrics-endpoint

Best Practices

Start simple: Your first command should be straightforward (lint + format + test)
One task per command: Don't create mega-commands that do everything
Use descriptive names: /quick-check is better than /qc
Document expected behavior: Explain what the command does in the first line
Test thoroughly: Run the command a few times to ensure it works as expected
Iterate based on usage: Refine commands as you discover edge cases

📦 ARCHIVED: Phase 4 Orchestration Commands

Complex workflow commands are stored in archive/phase4/commands/:

task_easy.md

Sequential thinking-based problem solving
Best practices enforcement
No band-aid fixes or fallbacks

task_hard.md

Full investigation → flow mapping → planning workflow
Automatic instance directory creation
Multi-agent orchestration with sequential execution

When to Restore: After completing Project 8, if working on large, complex features. See archive/phase4/README.md.

Examples from Phase 2+

/test-with-docker

Run tests inside Docker container to verify production environment:

1. Build test image: docker build -f Dockerfile.test -t app-test .
2. Run tests: docker run --rm app-test pytest --cov
3. Clean up: docker rmi app-test

Report coverage percentage and any failures.

/deploy-dev

Deploy to development environment:

1. Run tests: uv run pytest
2. Build Docker image: docker build -t app:dev .
3. Push to registry: docker push registry.example.com/app:dev
4. Update deployment: kubectl set image deployment/app app=registry.example.com/app:dev

Stop if any step fails.

Questions?

"How do I edit a command?" Just edit the .md file. Changes take effect immediately.
"Can commands call other commands?" Not directly, but you can include similar prompts or reference other workflows.
"What if my command needs complex logic?" For complex logic, consider creating a Python script and having the command invoke it.
"Should I create commands in Phase 1?" Not yet - wait until Phase 2 when you have established patterns and repetitive tasks.

Remember: Commands are shortcuts for tasks you do repeatedly. If you're typing the same sequence of commands 3+ times, it's a candidate for a custom command!

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

# Claude Code Custom Commands Custom slash commands let you create shortcuts for repetitive tasks. Commands are simple markdown files with prompts that get expanded when you type `/command-name`. --- ## What Are Custom Commands? Commands are: - **Simple text files** with `.md` extension - **Prompt expansions** that run when you type `/command-name` - **Task-specific shortcuts** for repetitive workflows - **Easy to create** - just markdown with optional argument support --- ## When to Create Your First Command **Phase 2 (after completing Project 3)** By Project 3, you'll have noticed repetitive tasks: - Running lint + format before every commit - Setting up new Python projects with the same structure - Running tests with coverage reports - Creating git commits with proper formatting **These patterns are perfect candidates for commands!** --- ## Available Commands ### ⏸️ DORMANT: commit.md **Phase:** 2+ (Enable after Project 3) **Purpose:** Structured git commit workflow with good message formatting **WHEN TO ENABLE:** After completing Project 3, when you're comfortable with git workflows and ready for structured commits. **TO ACTIVATE:** Just start using it! The file is already in place: ```bash /commit ``` The command will: 1. Run `git status` and `git diff` to show changes 2. Ask you to describe what changed and why 3. Format the commit message properly 4. Execute the commit with co-authored-by attribution --- ### ⏸️ DORMANT: code-review.md **Phase:** 2+ (Enable after Project 3) **Purpose:** Manual trigger for code review before committing **TO USE:** ```bash /code-review ``` Invokes the appropriate reviewer agent (learning-reviewer in Phase 1-2, code-reviewer in Phase 3+). --- ## Creating Your First Command ### Step 1: Identify a Repetitive Task After Project 3, notice what you type repeatedly. Common examples: - `uv run ruff check . && uv run ruff format . && uv run pytest --cov` - `uv init new-project && cd new-project && uv add psutil requests` - Commit message templates for different change types ### Step 2: Create the Command File **Example: /quick-check command** Create `.claude/commands/quick-check.md`: ```markdown Run linting, formatting, and tests with coverage. Execute these commands sequentially: 1. uv run ruff check . 2. uv run ruff format . 3. uv run pytest --cov=src tests/ -v Report results for each step clearly. ``` ### Step 3: Use It! ```bash /quick-check ``` That's it! Claude will expand your prompt and execute the workflow. --- ## Command Templates ### Quality Check Command ```markdown Run code quality checks: 1. Lint: uv run ruff check . 2. Format: uv run ruff format . 3. Type check: uv run pyright 4. Tests: uv run pytest --cov Stop if any check fails and report the issue. ``` ### Project Setup Command ```markdown Set up a new Python project with modern tooling: 1. Create project: uv init {{arguments}} 2. Add dependencies: uv add psutil tabulate click rich 3. Add dev dependencies: uv add --dev pytest pytest-cov ruff pyright 4. Create src/ directory structure 5. Initialize git repository 6. Create .gitignore for Python 7. Show next steps Project name: {{arguments}} ``` ### Docker Build & Run Command ```markdown Build and run the Docker container for this project: 1. Build: docker build -t vps-dashboard:latest . 2. Run: docker run --rm -p 8000:8000 vps-dashboard:latest 3. Show container logs If build fails, explain the error clearly. ``` --- ## Command Arguments Use `{{arguments}}` in your command to accept input: **Command file:** ```markdown Create a new feature branch and switch to it. Branch name: {{arguments}} Execute: git checkout -b feature/{{arguments}} ``` **Usage:** ```bash /new-branch api-metrics-endpoint # Expands to: git checkout -b feature/api-metrics-endpoint ``` --- ## Best Practices 1. **Start simple:** Your first command should be straightforward (lint + format + test) 2. **One task per command:** Don't create mega-commands that do everything 3. **Use descriptive names:** `/quick-check` is better than `/qc` 4. **Document expected behavior:** Explain what the command does in the first line 5. **Test thoroughly:** Run the command a few times to ensure it works as expected 6. **Iterate based on usage:** Refine commands as you discover edge cases --- ## 📦 ARCHIVED: Phase 4 Orchestration Commands Complex workflow commands are stored in `archive/phase4/commands/`: ### task_easy.md - Sequential thinking-based problem solving - Best practices enforcement - No band-aid fixes or fallbacks ### task_hard.md - Full investigation → flow mapping → planning workflow - Automatic instance directory creation - Multi-agent orchestration with sequential execution **When to Restore:** After completing Project 8, if working on large, complex features. See `archive/phase4/README.md`. --- ## Examples from Phase 2+ ### /test-with-docker ```markdown Run tests inside Docker container to verify production environment: 1. Build test image: docker build -f Dockerfile.test -t app-test . 2. Run tests: docker run --rm app-test pytest --cov 3. Clean up: docker rmi app-test Report coverage percentage and any failures. ``` ### /deploy-dev ```markdown Deploy to development environment: 1. Run tests: uv run pytest 2. Build Docker image: docker build -t app:dev . 3. Push to registry: docker push registry.example.com/app:dev 4. Update deployment: kubectl set image deployment/app app=registry.example.com/app:dev Stop if any step fails. ``` --- ## Questions? - **"How do I edit a command?"** Just edit the `.md` file. Changes take effect immediately. - **"Can commands call other commands?"** Not directly, but you can include similar prompts or reference other workflows. - **"What if my command needs complex logic?"** For complex logic, consider creating a Python script and having the command invoke it. - **"Should I create commands in Phase 1?"** Not yet - wait until Phase 2 when you have established patterns and repetitive tasks. --- **Remember:** Commands are shortcuts for tasks you do repeatedly. If you're typing the same sequence of commands 3+ times, it's a candidate for a custom command!

{ "prompt": "# Claude Code Custom Commands\n\nCustom slash commands let you create shortcuts for repetitive tasks. Commands are simple markdown files with prompts that get expanded when you type `/command-name`.\n\n---\n\n## What Are Custom Commands?\n\nCommands are:\n- **Simple text files** with `.md` extension\n- **Prompt expansions** that run when you type `/command-name`\n- **Task-specific shortcuts** for repetitive workflows\n- **Easy to create** - just markdown with optional argument support\n\n---\n\n## When to Create Your First Command\n\n**Phase 2 (after completing Project 3)**\n\nBy Project 3, you'll have noticed repetitive tasks:\n- Running lint + format before every commit\n- Setting up new Python projects with the same structure\n- Running tests with coverage reports\n- Creating git commits with proper formatting\n\n**These patterns are perfect candidates for commands!**\n\n---\n\n## Available Commands\n\n### ⏸️ DORMANT: commit.md\n**Phase:** 2+ (Enable after Project 3)\n**Purpose:** Structured git commit workflow with good message formatting\n\n**WHEN TO ENABLE:**\nAfter completing Project 3, when you're comfortable with git workflows and ready for structured commits.\n\n**TO ACTIVATE:**\nJust start using it! The file is already in place:\n```bash\n/commit\n```\n\nThe command will:\n1. Run `git status` and `git diff` to show changes\n2. Ask you to describe what changed and why\n3. Format the commit message properly\n4. Execute the commit with co-authored-by attribution\n\n---\n\n### ⏸️ DORMANT: code-review.md\n**Phase:** 2+ (Enable after Project 3)\n**Purpose:** Manual trigger for code review before committing\n\n**TO USE:**\n```bash\n/code-review\n```\n\nInvokes the appropriate reviewer agent (learning-reviewer in Phase 1-2, code-reviewer in Phase 3+).\n\n---\n\n## Creating Your First Command\n\n### Step 1: Identify a Repetitive Task\n\nAfter Project 3, notice what you type repeatedly. Common examples:\n- `uv run ruff check . && uv run ruff format . && uv run pytest --cov`\n- `uv init new-project && cd new-project && uv add psutil requests`\n- Commit message templates for different change types\n\n### Step 2: Create the Command File\n\n**Example: /quick-check command**\n\nCreate `.claude/commands/quick-check.md`:\n```markdown\nRun linting, formatting, and tests with coverage.\n\nExecute these commands sequentially:\n1. uv run ruff check .\n2. uv run ruff format .\n3. uv run pytest --cov=src tests/ -v\n\nReport results for each step clearly.\n```\n\n### Step 3: Use It!\n\n```bash\n/quick-check\n```\n\nThat's it! Claude will expand your prompt and execute the workflow.\n\n---\n\n## Command Templates\n\n### Quality Check Command\n```markdown\nRun code quality checks:\n1. Lint: uv run ruff check .\n2. Format: uv run ruff format .\n3. Type check: uv run pyright\n4. Tests: uv run pytest --cov\n\nStop if any check fails and report the issue.\n```\n\n### Project Setup Command\n```markdown\nSet up a new Python project with modern tooling:\n\n1. Create project: uv init {{arguments}}\n2. Add dependencies: uv add psutil tabulate click rich\n3. Add dev dependencies: uv add --dev pytest pytest-cov ruff pyright\n4. Create src/ directory structure\n5. Initialize git repository\n6. Create .gitignore for Python\n7. Show next steps\n\nProject name: {{arguments}}\n```\n\n### Docker Build & Run Command\n```markdown\nBuild and run the Docker container for this project:\n\n1. Build: docker build -t vps-dashboard:latest .\n2. Run: docker run --rm -p 8000:8000 vps-dashboard:latest\n3. Show container logs\n\nIf build fails, explain the error clearly.\n```\n\n---\n\n## Command Arguments\n\nUse `{{arguments}}` in your command to accept input:\n\n**Command file:**\n```markdown\nCreate a new feature branch and switch to it.\n\nBranch name: {{arguments}}\n\nExecute: git checkout -b feature/{{arguments}}\n```\n\n**Usage:**\n```bash\n/new-branch api-metrics-endpoint\n# Expands to: git checkout -b feature/api-metrics-endpoint\n```\n\n---\n\n## Best Practices\n\n1. **Start simple:** Your first command should be straightforward (lint + format + test)\n2. **One task per command:** Don't create mega-commands that do everything\n3. **Use descriptive names:** `/quick-check` is better than `/qc`\n4. **Document expected behavior:** Explain what the command does in the first line\n5. **Test thoroughly:** Run the command a few times to ensure it works as expected\n6. **Iterate based on usage:** Refine commands as you discover edge cases\n\n---\n\n## 📦 ARCHIVED: Phase 4 Orchestration Commands\n\nComplex workflow commands are stored in `archive/phase4/commands/`:\n\n### task_easy.md\n- Sequential thinking-based problem solving\n- Best practices enforcement\n- No band-aid fixes or fallbacks\n\n### task_hard.md\n- Full investigation → flow mapping → planning workflow\n- Automatic instance directory creation\n- Multi-agent orchestration with sequential execution\n\n**When to Restore:** After completing Project 8, if working on large, complex features. See `archive/phase4/README.md`.\n\n---\n\n## Examples from Phase 2+\n\n### /test-with-docker\n```markdown\nRun tests inside Docker container to verify production environment:\n\n1. Build test image: docker build -f Dockerfile.test -t app-test .\n2. Run tests: docker run --rm app-test pytest --cov\n3. Clean up: docker rmi app-test\n\nReport coverage percentage and any failures.\n```\n\n### /deploy-dev\n```markdown\nDeploy to development environment:\n\n1. Run tests: uv run pytest\n2. Build Docker image: docker build -t app:dev .\n3. Push to registry: docker push registry.example.com/app:dev\n4. Update deployment: kubectl set image deployment/app app=registry.example.com/app:dev\n\nStop if any step fails.\n```\n\n---\n\n## Questions?\n\n- **\"How do I edit a command?\"**\n Just edit the `.md` file. Changes take effect immediately.\n\n- **\"Can commands call other commands?\"**\n Not directly, but you can include similar prompts or reference other workflows.\n\n- **\"What if my command needs complex logic?\"**\n For complex logic, consider creating a Python script and having the command invoke it.\n\n- **\"Should I create commands in Phase 1?\"**\n Not yet - wait until Phase 2 when you have established patterns and repetitive tasks.\n\n---\n\n**Remember:** Commands are shortcuts for tasks you do repeatedly. If you're typing the same sequence of commands 3+ times, it's a candidate for a custom command!", "variables": [ "arguments" ], "notes": "Custom slash commands let you create shortcuts for repetitive tasks. Commands are simple markdown files with prompts that get expanded when you type `/command-name`.", "metadata": { "source": { "provider": "github-claude-commands", "repository": "https://github.com/BabakBar/vps-dashboard-py", "path": ".claude/commands/README.md", "ref": "f32c4cd530daa49b6ac829c74d3c19e6c9542fad", "url": "https://github.com/BabakBar/vps-dashboard-py/blob/f32c4cd530daa49b6ac829c74d3c19e6c9542fad/.claude/commands/README.md", "key": "BabakBar/vps-dashboard-py/.claude/commands/README.md" } } }

README

About