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.

write-prd - Prompt - OpenSmartRoute

Name: write-prd
Author: rymcu

Prompt file imported from rymcu/mortise (.github/prompts/write-prd.prompt.md). Copyright stays with the author.

通过结构化的用户访谈、代码探索和模块设计来编写产品需求文档（PRD），最终提交为 GitHub Issue。

先阅读并遵循这些仓库文件：

流程

1. 获取问题描述

让用户详细描述：

要解决的问题
潜在的解决思路
面向的用户角色

2. 探索代码库

验证用户的说法，理解当前状态：

相关模块和现有实现
数据模型和 API 接口
可复用的基础设施（SPI 扩展点、已有 Service 等）

3. 深度访谈

穷尽式追问每个设计分支的细节，直到达成共识：

逐一解决设计决策之间的依赖
边界情况和错误处理策略
与现有功能的交互
权限和安全约束

4. 模块设计

梳理需要构建或修改的主要模块，积极寻找深模块的机会：

深模块 = 用简单、可测试的接口封装大量功能，接口很少变化

在 Mortise 中特别关注：

是否需要新建业务域模块（domain/application/infra/admin/api 分层）
是否可通过 SPI 扩展现有模块，而非直接添加同层依赖
前端改动涉及哪些 apps/packages/layers

与用户确认模块划分和测试范围。

5. 确定 Issue 提交仓库

Mortise 是多 git submodule 项目，需要将 Issue 提交到对应的子仓库。

仓库路由规则

读取根目录 .gitmodules 文件获取完整的子模块映射。常见映射示例：

改动范围	目标仓库	子模块路径
后端 AIOT 业务	`rymcu/mortise-aiot`	`mortise-aiot/`
前端 AIOT 管理	`rymcu/admin-aiot`	`frontend/layers/admin/aiot/`
后端社区业务	`rymcu/mortise-community`	`mortise-community/`
前端社区管理	`rymcu/admin-community`	`frontend/layers/admin/community/`
框架公共模块	`rymcu/mortise`（父仓库）	`mortise-common/`、`mortise-core/` 等
前端共享包	`rymcu/mortise`（父仓库）	`frontend/packages/` 等

提交策略

单仓库改动：直接在目标子仓库创建 Issue。
跨仓库改动（涉及多个子模块）：
1. 在父仓库 rymcu/mortise 创建 Umbrella PRD Issue（完整 PRD 内容）
2. 在每个涉及的子仓库创建 实现 Issue（只包含该仓库范围内的切片和验收标准）
3. 子仓库 Issue 开头标注 Parent PRD: rymcu/mortise#N
4. Umbrella Issue 顶部用表格列出所有子仓库 Issue 链接
仅父仓库改动（框架层、配置、文档）：直接在 rymcu/mortise 创建 Issue。

6. 编写 PRD 并提交 Issue

使用下面的模板编写 PRD，提交为 GitHub Issue。

PRD 模板

## 问题陈述

从用户视角描述面临的问题。

## 解决方案

从用户视角描述解决方案。

## 用户故事

详尽的用户故事列表，覆盖功能的各个方面：

1. 作为<角色>，我希望<功能>，以便<收益>

示例：
1. 作为后台管理员，我希望能批量导入会员数据，以便快速完成系统初始化
2. 作为普通用户，我希望上传头像后能立即看到预览，以便确认效果

## 实现决策

实现过程中做出的技术决策，包括：

- 需要构建或修改的模块
- 模块接口设计
- 架构决策（SPI 扩展 vs 直接依赖、事件驱动 vs 同步调用等）
- 数据库 Schema 变更
- API 契约
- 具体交互逻辑

**不要**包含具体文件路径或代码片段——它们很快会过时。

## 测试决策

- 好测试的标准：只测外部行为，不测实现细节
- 哪些模块需要测试
- 测试参考：代码库中类似的测试模式

## 垂直切片拆分

将 PRD 拆分为 tracer bullet 式的垂直切片，每个切片：
- 贯穿所有集成层（Schema → API → UI → 测试）
- 独立可演示或可验证
- 宁可多切薄片，不要少切厚片

对每个切片列出：
- **标题**：简短描述
- **覆盖的用户故事**：引用上方编号
- **验收标准**：具体可检查的条目
- **依赖关系**：是否阻塞于其他切片

## 范围外

明确不在本次 PRD 范围内的内容。

## 补充说明

任何额外备注。

注意事项

在 Mortise 中，新模块需遵循 domain/application/infra/admin/api 分层，在 PRD 中明确这一点
涉及权限时，参考 .github/instructions/permission-conventions.instructions.md 的命名规范
垂直切片拆分是可选步骤——如果 PRD 较小，可以不拆分
PRD 提交后不要关闭——后续的实现 Issue 应引用它作为 Parent PRD
跨子模块的 PRD 必须拆分 Issue 到对应子仓库，父仓库只保留 Umbrella 跟踪 Issue
提交前先通过 .gitmodules 确认目标仓库，不要将子模块范围的 Issue 提交到父仓库

Install write-prd 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.

通过结构化的用户访谈、代码探索和模块设计来编写**产品需求文档**（PRD），最终提交为 GitHub Issue。先阅读并遵循这些仓库文件： - [工作区说明](../copilot-instructions.md) - [后端模块边界](../instructions/backend-module-boundaries.instructions.md) - [前端 Nuxt 模式](../instructions/frontend-nuxt-patterns.instructions.md) ## 流程 ### 1. 获取问题描述让用户详细描述： - 要解决的问题 - 潜在的解决思路 - 面向的用户角色 ### 2. 探索代码库验证用户的说法，理解当前状态： - 相关模块和现有实现 - 数据模型和 API 接口 - 可复用的基础设施（SPI 扩展点、已有 Service 等） ### 3. 深度访谈 **穷尽式**追问每个设计分支的细节，直到达成共识： - 逐一解决设计决策之间的依赖 - 边界情况和错误处理策略 - 与现有功能的交互 - 权限和安全约束 ### 4. 模块设计梳理需要构建或修改的主要模块，积极寻找**深模块**的机会： > 深模块 = 用简单、可测试的接口封装大量功能，接口很少变化在 Mortise 中特别关注： - 是否需要新建业务域模块（`domain/application/infra/admin/api` 分层） - 是否可通过 SPI 扩展现有模块，而非直接添加同层依赖 - 前端改动涉及哪些 apps/packages/layers 与用户确认模块划分和测试范围。 ### 5. 确定 Issue 提交仓库 Mortise 是多 git submodule 项目，需要将 Issue 提交到**对应的子仓库**。 #### 仓库路由规则读取根目录 `.gitmodules` 文件获取完整的子模块映射。常见映射示例： | 改动范围 | 目标仓库 | 子模块路径 | |---------|---------|-----------| | 后端 AIOT 业务 | `rymcu/mortise-aiot` | `mortise-aiot/` | | 前端 AIOT 管理 | `rymcu/admin-aiot` | `frontend/layers/admin/aiot/` | | 后端社区业务 | `rymcu/mortise-community` | `mortise-community/` | | 前端社区管理 | `rymcu/admin-community` | `frontend/layers/admin/community/` | | 框架公共模块 | `rymcu/mortise`（父仓库） | `mortise-common/`、`mortise-core/` 等 | | 前端共享包 | `rymcu/mortise`（父仓库） | `frontend/packages/` 等 | #### 提交策略 - **单仓库改动**：直接在目标子仓库创建 Issue。 - **跨仓库改动**（涉及多个子模块）： 1. 在父仓库 `rymcu/mortise` 创建 **Umbrella PRD Issue**（完整 PRD 内容） 2. 在每个涉及的子仓库创建 **实现 Issue**（只包含该仓库范围内的切片和验收标准） 3. 子仓库 Issue 开头标注 `Parent PRD: rymcu/mortise#N` 4. Umbrella Issue 顶部用表格列出所有子仓库 Issue 链接 - **仅父仓库改动**（框架层、配置、文档）：直接在 `rymcu/mortise` 创建 Issue。 ### 6. 编写 PRD 并提交 Issue 使用下面的模板编写 PRD，提交为 GitHub Issue。 ## PRD 模板 ```markdown ## 问题陈述从用户视角描述面临的问题。 ## 解决方案从用户视角描述解决方案。 ## 用户故事详尽的用户故事列表，覆盖功能的各个方面： 1. 作为<角色>，我希望<功能>，以便<收益> 示例： 1. 作为后台管理员，我希望能批量导入会员数据，以便快速完成系统初始化 2. 作为普通用户，我希望上传头像后能立即看到预览，以便确认效果 ## 实现决策实现过程中做出的技术决策，包括： - 需要构建或修改的模块 - 模块接口设计 - 架构决策（SPI 扩展 vs 直接依赖、事件驱动 vs 同步调用等） - 数据库 Schema 变更 - API 契约 - 具体交互逻辑 **不要**包含具体文件路径或代码片段——它们很快会过时。 ## 测试决策 - 好测试的标准：只测外部行为，不测实现细节 - 哪些模块需要测试 - 测试参考：代码库中类似的测试模式 ## 垂直切片拆分将 PRD 拆分为 tracer bullet 式的垂直切片，每个切片： - 贯穿所有集成层（Schema → API → UI → 测试） - 独立可演示或可验证 - 宁可多切薄片，不要少切厚片对每个切片列出： - **标题**：简短描述 - **覆盖的用户故事**：引用上方编号 - **验收标准**：具体可检查的条目 - **依赖关系**：是否阻塞于其他切片 ## 范围外明确不在本次 PRD 范围内的内容。 ## 补充说明任何额外备注。 ``` ## 注意事项 - 在 Mortise 中，新模块需遵循 `domain/application/infra/admin/api` 分层，在 PRD 中明确这一点 - 涉及权限时，参考 `.github/instructions/permission-conventions.instructions.md` 的命名规范 - 垂直切片拆分是可选步骤——如果 PRD 较小，可以不拆分 - PRD 提交后不要关闭——后续的实现 Issue 应引用它作为 Parent PRD - **跨子模块的 PRD 必须拆分 Issue 到对应子仓库**，父仓库只保留 Umbrella 跟踪 Issue - 提交前先通过 `.gitmodules` 确认目标仓库，不要将子模块范围的 Issue 提交到父仓库

{ "prompt": "通过结构化的用户访谈、代码探索和模块设计来编写**产品需求文档**（PRD），最终提交为 GitHub Issue。\n\n先阅读并遵循这些仓库文件：\n- [工作区说明](../copilot-instructions.md)\n- [后端模块边界](../instructions/backend-module-boundaries.instructions.md)\n- [前端 Nuxt 模式](../instructions/frontend-nuxt-patterns.instructions.md)\n\n## 流程\n\n### 1. 获取问题描述\n\n让用户详细描述：\n- 要解决的问题\n- 潜在的解决思路\n- 面向的用户角色\n\n### 2. 探索代码库\n\n验证用户的说法，理解当前状态：\n- 相关模块和现有实现\n- 数据模型和 API 接口\n- 可复用的基础设施（SPI 扩展点、已有 Service 等）\n\n### 3. 深度访谈\n\n**穷尽式**追问每个设计分支的细节，直到达成共识：\n- 逐一解决设计决策之间的依赖\n- 边界情况和错误处理策略\n- 与现有功能的交互\n- 权限和安全约束\n\n### 4. 模块设计\n\n梳理需要构建或修改的主要模块，积极寻找**深模块**的机会：\n\n> 深模块 = 用简单、可测试的接口封装大量功能，接口很少变化\n\n在 Mortise 中特别关注：\n- 是否需要新建业务域模块（`domain/application/infra/admin/api` 分层）\n- 是否可通过 SPI 扩展现有模块，而非直接添加同层依赖\n- 前端改动涉及哪些 apps/packages/layers\n\n与用户确认模块划分和测试范围。\n\n### 5. 确定 Issue 提交仓库\n\nMortise 是多 git submodule 项目，需要将 Issue 提交到**对应的子仓库**。\n\n#### 仓库路由规则\n\n读取根目录 `.gitmodules` 文件获取完整的子模块映射。常见映射示例：\n\n| 改动范围 | 目标仓库 | 子模块路径 |\n|---------|---------|-----------|\n| 后端 AIOT 业务 | `rymcu/mortise-aiot` | `mortise-aiot/` |\n| 前端 AIOT 管理 | `rymcu/admin-aiot` | `frontend/layers/admin/aiot/` |\n| 后端社区业务 | `rymcu/mortise-community` | `mortise-community/` |\n| 前端社区管理 | `rymcu/admin-community` | `frontend/layers/admin/community/` |\n| 框架公共模块 | `rymcu/mortise`（父仓库） | `mortise-common/`、`mortise-core/` 等 |\n| 前端共享包 | `rymcu/mortise`（父仓库） | `frontend/packages/` 等 |\n\n#### 提交策略\n\n- **单仓库改动**：直接在目标子仓库创建 Issue。\n- **跨仓库改动**（涉及多个子模块）：\n 1. 在父仓库 `rymcu/mortise` 创建 **Umbrella PRD Issue**（完整 PRD 内容）\n 2. 在每个涉及的子仓库创建 **实现 Issue**（只包含该仓库范围内的切片和验收标准）\n 3. 子仓库 Issue 开头标注 `Parent PRD: rymcu/mortise#N`\n 4. Umbrella Issue 顶部用表格列出所有子仓库 Issue 链接\n- **仅父仓库改动**（框架层、配置、文档）：直接在 `rymcu/mortise` 创建 Issue。\n\n### 6. 编写 PRD 并提交 Issue\n\n使用下面的模板编写 PRD，提交为 GitHub Issue。\n\n## PRD 模板\n\n```markdown\n## 问题陈述\n\n从用户视角描述面临的问题。\n\n## 解决方案\n\n从用户视角描述解决方案。\n\n## 用户故事\n\n详尽的用户故事列表，覆盖功能的各个方面：\n\n1. 作为<角色>，我希望<功能>，以便<收益>\n\n示例：\n1. 作为后台管理员，我希望能批量导入会员数据，以便快速完成系统初始化\n2. 作为普通用户，我希望上传头像后能立即看到预览，以便确认效果\n\n## 实现决策\n\n实现过程中做出的技术决策，包括：\n\n- 需要构建或修改的模块\n- 模块接口设计\n- 架构决策（SPI 扩展 vs 直接依赖、事件驱动 vs 同步调用等）\n- 数据库 Schema 变更\n- API 契约\n- 具体交互逻辑\n\n**不要**包含具体文件路径或代码片段——它们很快会过时。\n\n## 测试决策\n\n- 好测试的标准：只测外部行为，不测实现细节\n- 哪些模块需要测试\n- 测试参考：代码库中类似的测试模式\n\n## 垂直切片拆分\n\n将 PRD 拆分为 tracer bullet 式的垂直切片，每个切片：\n- 贯穿所有集成层（Schema → API → UI → 测试）\n- 独立可演示或可验证\n- 宁可多切薄片，不要少切厚片\n\n对每个切片列出：\n- **标题**：简短描述\n- **覆盖的用户故事**：引用上方编号\n- **验收标准**：具体可检查的条目\n- **依赖关系**：是否阻塞于其他切片\n\n## 范围外\n\n明确不在本次 PRD 范围内的内容。\n\n## 补充说明\n\n任何额外备注。\n```\n\n## 注意事项\n\n- 在 Mortise 中，新模块需遵循 `domain/application/infra/admin/api` 分层，在 PRD 中明确这一点\n- 涉及权限时，参考 `.github/instructions/permission-conventions.instructions.md` 的命名规范\n- 垂直切片拆分是可选步骤——如果 PRD 较小，可以不拆分\n- PRD 提交后不要关闭——后续的实现 Issue 应引用它作为 Parent PRD\n- **跨子模块的 PRD 必须拆分 Issue 到对应子仓库**，父仓库只保留 Umbrella 跟踪 Issue\n- 提交前先通过 `.gitmodules` 确认目标仓库，不要将子模块范围的 Issue 提交到父仓库", "variables": [], "notes": "通过用户访谈、代码探索和模块设计编写 PRD，并提交为 GitHub Issue Arguments: 简述要解决的问题或要实现的功能.", "metadata": { "source": { "provider": "github-prompts", "repository": "https://github.com/rymcu/mortise", "path": ".github/prompts/write-prd.prompt.md", "ref": "70ac0ca130e2d89a3b255d2286374750479b1072", "url": "https://github.com/rymcu/mortise/blob/70ac0ca130e2d89a3b255d2286374750479b1072/.github/prompts/write-prd.prompt.md", "key": "rymcu/mortise/.github/prompts/write-prd.prompt.md" } } }

write-prd

About

流程

1. 获取问题描述

2. 探索代码库

3. 深度访谈

4. 模块设计

5. 确定 Issue 提交仓库

仓库路由规则

提交策略

6. 编写 PRD 并提交 Issue

PRD 模板

注意事项

Install write-prd 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