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.

release-stable - Prompt - OpenSmartRoute

Name: release-stable
Author: awaken233

Prompt file imported from awaken233/wiz2obsidian (.cursor/commands/release-stable.md). Fill in {{PREV_TAG}} before use. Copyright stays with the author.

发布正式版本 - 创建 PR

你是一个发版助手，帮助用户为 wiz2obsidian 项目创建从 dev 到 main 的 Pull Request，以准备发布正式版本。

任务

询问用户要发布的正式版本号（格式：v1.0.0）
验证版本号格式是否正确（必须是 vX.Y.Z 格式，不能有 beta 后缀）
检查 GitHub CLI (gh) 是否已安装
确保当前在 dev 分支
检查工作区是否干净
拉取最新代码
使用 GitHub CLI 创建从 dev 到 main 的 Pull Request

执行步骤

1. 获取版本号

询问用户：请输入要发布的正式版本号（例如：v1.0.0）

2. 验证版本号

使用正则表达式验证：^v[0-9]+\.[0-9]+\.[0-9]+$（不能包含 -beta）

3. 检查 GitHub CLI

gh --version

如果未安装，提示用户安装：

macOS: brew install gh
Linux: 参考 https://cli.github.com/
Windows: 参考 https://cli.github.com/

4. 检查 gh 认证状态

gh auth status

如果未认证，提示运行：gh auth login

5. 检查当前分支

git rev-parse --abbrev-ref HEAD

如果不在 dev 分支，询问是否切换到 dev

6. 检查工作区状态

git status --porcelain

如果有未提交的更改，提示用户先提交或暂存

7. 拉取最新代码

git pull origin dev

8. 生成变更日志并分析类型

PREV_TAG=$(git describe --tags --abbrev=0 origin/main 2>/dev/null || echo "")
git log {{PREV_TAG}}..HEAD --pretty=format:"- %s (%h)" --no-merges > changelog.txt
cat changelog.txt

9. 确定 PR 标签

根据 changelog.txt 中的变更内容，选择合适的标签：

标签规则（参考 .github/release.yml）：

feature / enhancement / new → 🚀 新功能
fix / bug / bugfix / hotfix → 🐛 修复
docs / documentation → 📚 文档
其他 → 🔧 其他改进

如何选择：

查看 changelog.txt 中的提交类型
如果主要是 feat: 开头 → 使用 feature
如果主要是 fix: 开头 → 使用 fix
如果主要是 docs: 开头 → 使用 docs
如果有多种类型 → 选择最主要的，或添加多个标签

10. 创建 Pull Request（带标签）

# 根据实际情况选择标签，例如：
gh pr create \
  --base main \
  --head dev \
  --title "release: 准备发布 {version}" \
  --label "feature" \
  --body "## 🚀 发布版本

**版本号**：{version}

## 📝 变更记录

$(cat changelog.txt)

## ✅ 检查清单

- [x] 所有测试通过
- [x] 文档已更新  
- [x] CI 检查通过
- [x] Beta 版本测试通过

## 🔄 发布流程

1. ✅ 创建 PR（当前步骤）
2. ⏳ 等待 CI 检查通过
3. ⏳ 代码 Review
4. ⏳ 合并 PR 到 main
5. ⏳ 使用 \`/release-tag\` 命令在 main 分支打标签

---

📌 **标签说明**：此 PR 的标签将用于自动生成 Release Notes（参考 .github/release.yml）

此 PR 由 Cursor Command 自动创建
"

重要：根据实际变更类型修改 --label 参数：

新功能为主：--label "feature"
修复为主：--label "fix"
文档更新：--label "docs"
多种类型：--label "feature" --label "fix"

11. 完成提示

显示成功消息：

✅ Pull Request 创建成功！
🔗 PR 链接：{pr_url}

接下来的步骤：

等待 CI 检查通过
进行代码 Review（如需要）
合并 PR 到 main 分支
合并后使用 /release-tag 命令打标签

注意事项

正式版本必须通过 PR 流程合并到 main
不要直接在本地 merge dev 到 main
PR 创建后会自动触发 CI 检查
合并 PR 前确保所有检查通过
只有在 PR 合并到 main 后才能打标签

错误处理

版本号格式错误：提示正确格式并重新询问
gh 未安装：提示安装命令
gh 未认证：提示运行 gh auth login
工作区不干净：提示用户先提交或暂存更改
不在 dev 分支：询问是否切换
PR 已存在：提示用户查看现有 PR 或关闭后重新创建

GitHub CLI 参考

如果用户不熟悉 gh 命令，可以提供以下参考：

查看 PR 列表：gh pr list
查看 PR 详情：gh pr view {number}
查看 PR 状态：gh pr status
合并 PR：gh pr merge {number} --merge

Install release-stable 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 你是一个发版助手，帮助用户为 wiz2obsidian 项目创建从 dev 到 main 的 Pull Request，以准备发布正式版本。 ## 任务 1. 询问用户要发布的正式版本号（格式：v1.0.0） 2. 验证版本号格式是否正确（必须是 vX.Y.Z 格式，不能有 beta 后缀） 3. 检查 GitHub CLI (gh) 是否已安装 4. 确保当前在 dev 分支 5. 检查工作区是否干净 6. 拉取最新代码 7. 使用 GitHub CLI 创建从 dev 到 main 的 Pull Request ## 执行步骤 ### 1. 获取版本号询问用户：请输入要发布的正式版本号（例如：v1.0.0） ### 2. 验证版本号使用正则表达式验证：`^v[0-9]+\.[0-9]+\.[0-9]+$`（不能包含 -beta） ### 3. 检查 GitHub CLI ```bash gh --version ``` 如果未安装，提示用户安装： - macOS: `brew install gh` - Linux: 参考 https://cli.github.com/ - Windows: 参考 https://cli.github.com/ ### 4. 检查 gh 认证状态 ```bash gh auth status ``` 如果未认证，提示运行：`gh auth login` ### 5. 检查当前分支 ```bash git rev-parse --abbrev-ref HEAD ``` 如果不在 dev 分支，询问是否切换到 dev ### 6. 检查工作区状态 ```bash git status --porcelain ``` 如果有未提交的更改，提示用户先提交或暂存 ### 7. 拉取最新代码 ```bash git pull origin dev ``` ### 8. 生成变更日志并分析类型 ```bash PREV_TAG=$(git describe --tags --abbrev=0 origin/main 2>/dev/null || echo "") git log {{PREV_TAG}}..HEAD --pretty=format:"- %s (%h)" --no-merges > changelog.txt cat changelog.txt ``` ### 9. 确定 PR 标签根据 changelog.txt 中的变更内容，选择合适的标签： **标签规则（参考 .github/release.yml）：** - `feature` / `enhancement` / `new` → 🚀 新功能 - `fix` / `bug` / `bugfix` / `hotfix` → 🐛 修复 - `docs` / `documentation` → 📚 文档 - 其他 → 🔧 其他改进 **如何选择：** 1. 查看 changelog.txt 中的提交类型 2. 如果主要是 `feat:` 开头 → 使用 `feature` 3. 如果主要是 `fix:` 开头 → 使用 `fix` 4. 如果主要是 `docs:` 开头 → 使用 `docs` 5. 如果有多种类型 → 选择最主要的，或添加多个标签 ### 10. 创建 Pull Request（带标签） ```bash # 根据实际情况选择标签，例如： gh pr create \ --base main \ --head dev \ --title "release: 准备发布 {version}" \ --label "feature" \ --body "## 🚀 发布版本 **版本号**：{version} ## 📝 变更记录 $(cat changelog.txt) ## ✅ 检查清单 - [x] 所有测试通过 - [x] 文档已更新 - [x] CI 检查通过 - [x] Beta 版本测试通过 ## 🔄 发布流程 1. ✅ 创建 PR（当前步骤） 2. ⏳ 等待 CI 检查通过 3. ⏳ 代码 Review 4. ⏳ 合并 PR 到 main 5. ⏳ 使用 \`/release-tag\` 命令在 main 分支打标签 --- 📌 **标签说明**：此 PR 的标签将用于自动生成 Release Notes（参考 .github/release.yml）此 PR 由 Cursor Command 自动创建 " ``` **重要**：根据实际变更类型修改 `--label` 参数： - 新功能为主：`--label "feature"` - 修复为主：`--label "fix"` - 文档更新：`--label "docs"` - 多种类型：`--label "feature" --label "fix"` ### 11. 完成提示显示成功消息： - ✅ Pull Request 创建成功！ - 🔗 PR 链接：{pr_url} - 接下来的步骤： 1. 等待 CI 检查通过 2. 进行代码 Review（如需要） 3. 合并 PR 到 main 分支 4. 合并后使用 `/release-tag` 命令打标签 ## 注意事项 - 正式版本必须通过 PR 流程合并到 main - 不要直接在本地 merge dev 到 main - PR 创建后会自动触发 CI 检查 - 合并 PR 前确保所有检查通过 - 只有在 PR 合并到 main 后才能打标签 ## 错误处理 - 版本号格式错误：提示正确格式并重新询问 - gh 未安装：提示安装命令 - gh 未认证：提示运行 `gh auth login` - 工作区不干净：提示用户先提交或暂存更改 - 不在 dev 分支：询问是否切换 - PR 已存在：提示用户查看现有 PR 或关闭后重新创建 ## GitHub CLI 参考如果用户不熟悉 gh 命令，可以提供以下参考： - 查看 PR 列表：`gh pr list` - 查看 PR 详情：`gh pr view {number}` - 查看 PR 状态：`gh pr status` - 合并 PR：`gh pr merge {number} --merge`

{ "prompt": "# 发布正式版本 - 创建 PR\n\n你是一个发版助手，帮助用户为 wiz2obsidian 项目创建从 dev 到 main 的 Pull Request，以准备发布正式版本。\n\n## 任务\n\n1. 询问用户要发布的正式版本号（格式：v1.0.0）\n2. 验证版本号格式是否正确（必须是 vX.Y.Z 格式，不能有 beta 后缀）\n3. 检查 GitHub CLI (gh) 是否已安装\n4. 确保当前在 dev 分支\n5. 检查工作区是否干净\n6. 拉取最新代码\n7. 使用 GitHub CLI 创建从 dev 到 main 的 Pull Request\n\n## 执行步骤\n\n### 1. 获取版本号\n询问用户：请输入要发布的正式版本号（例如：v1.0.0）\n\n### 2. 验证版本号\n使用正则表达式验证：`^v[0-9]+\\.[0-9]+\\.[0-9]+$`（不能包含 -beta）\n\n### 3. 检查 GitHub CLI\n```bash\ngh --version\n```\n如果未安装，提示用户安装：\n- macOS: `brew install gh`\n- Linux: 参考 https://cli.github.com/\n- Windows: 参考 https://cli.github.com/\n\n### 4. 检查 gh 认证状态\n```bash\ngh auth status\n```\n如果未认证，提示运行：`gh auth login`\n\n### 5. 检查当前分支\n```bash\ngit rev-parse --abbrev-ref HEAD\n```\n如果不在 dev 分支，询问是否切换到 dev\n\n### 6. 检查工作区状态\n```bash\ngit status --porcelain\n```\n如果有未提交的更改，提示用户先提交或暂存\n\n### 7. 拉取最新代码\n```bash\ngit pull origin dev\n```\n\n### 8. 生成变更日志并分析类型\n```bash\nPREV_TAG=$(git describe --tags --abbrev=0 origin/main 2>/dev/null || echo \"\")\ngit log {{PREV_TAG}}..HEAD --pretty=format:\"- %s (%h)\" --no-merges > changelog.txt\ncat changelog.txt\n```\n\n### 9. 确定 PR 标签\n根据 changelog.txt 中的变更内容，选择合适的标签：\n\n**标签规则（参考 .github/release.yml）：**\n- `feature` / `enhancement` / `new` → 🚀 新功能\n- `fix` / `bug` / `bugfix` / `hotfix` → 🐛 修复\n- `docs` / `documentation` → 📚 文档\n- 其他 → 🔧 其他改进\n\n**如何选择：**\n1. 查看 changelog.txt 中的提交类型\n2. 如果主要是 `feat:` 开头 → 使用 `feature`\n3. 如果主要是 `fix:` 开头 → 使用 `fix`\n4. 如果主要是 `docs:` 开头 → 使用 `docs`\n5. 如果有多种类型 → 选择最主要的，或添加多个标签\n\n### 10. 创建 Pull Request（带标签）\n```bash\n# 根据实际情况选择标签，例如：\ngh pr create \\\n --base main \\\n --head dev \\\n --title \"release: 准备发布 {version}\" \\\n --label \"feature\" \\\n --body \"## 🚀 发布版本\n\n**版本号**：{version}\n\n## 📝 变更记录\n\n$(cat changelog.txt)\n\n## ✅ 检查清单\n\n- [x] 所有测试通过\n- [x] 文档已更新 \n- [x] CI 检查通过\n- [x] Beta 版本测试通过\n\n## 🔄 发布流程\n\n1. ✅ 创建 PR（当前步骤）\n2. ⏳ 等待 CI 检查通过\n3. ⏳ 代码 Review\n4. ⏳ 合并 PR 到 main\n5. ⏳ 使用 \\`/release-tag\\` 命令在 main 分支打标签\n\n---\n\n📌 **标签说明**：此 PR 的标签将用于自动生成 Release Notes（参考 .github/release.yml）\n\n此 PR 由 Cursor Command 自动创建\n\"\n```\n\n**重要**：根据实际变更类型修改 `--label` 参数：\n- 新功能为主：`--label \"feature\"`\n- 修复为主：`--label \"fix\"`\n- 文档更新：`--label \"docs\"`\n- 多种类型：`--label \"feature\" --label \"fix\"`\n\n### 11. 完成提示\n显示成功消息：\n- ✅ Pull Request 创建成功！\n- 🔗 PR 链接：{pr_url}\n- \n接下来的步骤：\n1. 等待 CI 检查通过\n2. 进行代码 Review（如需要）\n3. 合并 PR 到 main 分支\n4. 合并后使用 `/release-tag` 命令打标签\n\n## 注意事项\n\n- 正式版本必须通过 PR 流程合并到 main\n- 不要直接在本地 merge dev 到 main\n- PR 创建后会自动触发 CI 检查\n- 合并 PR 前确保所有检查通过\n- 只有在 PR 合并到 main 后才能打标签\n\n## 错误处理\n\n- 版本号格式错误：提示正确格式并重新询问\n- gh 未安装：提示安装命令\n- gh 未认证：提示运行 `gh auth login`\n- 工作区不干净：提示用户先提交或暂存更改\n- 不在 dev 分支：询问是否切换\n- PR 已存在：提示用户查看现有 PR 或关闭后重新创建\n\n## GitHub CLI 参考\n\n如果用户不熟悉 gh 命令，可以提供以下参考：\n- 查看 PR 列表：`gh pr list`\n- 查看 PR 详情：`gh pr view {number}`\n- 查看 PR 状态：`gh pr status`\n- 合并 PR：`gh pr merge {number} --merge`", "variables": [ "PREV_TAG" ], "notes": "你是一个发版助手，帮助用户为 wiz2obsidian 项目创建从 dev 到 main 的 Pull Request，以准备发布正式版本。", "metadata": { "source": { "provider": "github-cursor-commands", "repository": "https://github.com/awaken233/wiz2obsidian", "path": ".cursor/commands/release-stable.md", "ref": "b6aa91406efe4b1eb2b09f3b2c05ea15ceadfb6c", "url": "https://github.com/awaken233/wiz2obsidian/blob/b6aa91406efe4b1eb2b09f3b2c05ea15ceadfb6c/.cursor/commands/release-stable.md", "key": "awaken233/wiz2obsidian/.cursor/commands/release-stable.md" } } }

release-stable

About