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.

新功能开发流程 - Prompt

Name: 新功能开发流程
Author: armink

Prompt file imported from armink/word-master (.github/prompts/feature.prompt.md). Copyright stays with the author.

新功能开发与改进标准流程

与 Bug 修复流程（先写失败测试再修代码）不同，新功能的需求往往在实现过程中才逐渐清晰。本流程采用混合策略：先澄清需求、再渐进实现，契约测试随实现同步、行为测试最后补全。

按以下步骤执行，遇到需求不清晰时必须停下来澄清，不要猜测继续推进。

Step 1：需求澄清（Clarification）

复述理解：用自己的话描述功能目标，确认与用户对齐
识别模糊点：主动提问，重点关注：
- 业务规则边界（如：新字段的合法值范围、默认值是什么？）
- 与现有功能的潜在冲突（如：新逻辑是否与已有调度机制矛盾？）
- 优先级（核心功能 vs 增强功能，哪些本次必做？）
写下最终确认的规格，一两句话描述每个要实现的行为

⚠️ 暂停点：将理解到的需求规格呈现给用户，等待用户明确确认后方可进入 Step 2。 如果用户补充或修正了需求，必须重新梳理后再次确认。

Step 2：影响范围分析（Impact Analysis）

在写任何代码前，先梳理：

数据库层：是否需要新增字段或表？迁移是否幂等(NOT EXISTS/ON CONFLICT)?
类型层：后端 types/index.ts、前端 types/index.ts 需要同步更新哪些类型？
后端路由层：哪些接口的入参/出参/逻辑需要改动？是否影响现有接口的调用方？
前端层：API 调用层、页面组件、状态管理哪些需要联动？
测试层：哪些已有测试用例可能因此被影响？是否需要修改 helpers.ts？

列出要修改的文件清单，按依赖顺序排列（下层先改，不要从 UI 开始）。

⚠️ 暂停点：将改动范围及文件清单展示给用户，等待用户确认后方可开始实现。 如果用户对影响范围有异议（如不希望改某个接口），必须重新评估影响范围。

Step 3：渐进式实现（Incremental Implementation）

按以下层次顺序实现，每完成一层做一次编译验证：

3.1 数据库 Schema

新增字段使用幂等 ALTER TABLE ... ADD COLUMN IF NOT EXISTS 或通过 planNewCols 列表
设置合理的 DEFAULT 值确保存量数据兼容

3.2 后端类型与路由

先更新 types/index.ts，再改路由和业务逻辑
路由中同步增加入参校验（非法值返回 400）和存在性校验（不存在返回 404）
路由改完后，立即运行：
```
npx tsc --noEmit
```
类型错误必须清零再继续

3.3 前端类型与 API 层

更新前端 types/index.ts 与后端保持同步
更新 api/index.ts 函数签名，新增可选参数时注意向后兼容

3.4 前端 UI

完成 UI 后再次运行 TypeScript 检查

3.5 阶段性验证

每完成一个后端路由的改动，用以下方式快速验证：

curl 或 Postman 手动调接口
或直接运行对应的测试文件：npx vitest run src/routes/xxx.test.ts

Step 4：测试补充（Testing）

测试范围：仅后端接口测试（backend/src/**/*.test.ts），不涉及前端。

新功能测试采用混合策略，分两类写：

4.1 契约测试（随实现同步写）

每写完一条路由，立即补充以下测试：

缺少必要参数 → 400
非法参数值 → 400（含边界值）
资源不存在 → 404
正常创建/更新 → 201/200，返回结构正确

这类测试成本低、不依赖业务决策，应随手写。

4.2 行为测试（业务逻辑稳定后补写）

等核心业务逻辑（联锁逻辑、调度算法、状态流转）实现并稳定后，补充：

核心业务路径的正确行为（如：解锁链在不同 target_level 下的差异）
边界条件（如：stage=5 上限、remaining_days=1 时全量出词）
状态一致性（如：答对 vs 答错对 mastery 的不同影响）

4.3 修改 helpers.ts

如果新增了必要的测试辅助函数或扩展了 createXxx 辅助函数，确保：

新参数设置合理默认值（向后兼容已有调用）
在函数注释中说明新参数含义

4.4 回归测试（含覆盖率）

在 backend/ 目录运行：

npm run test:coverage

必须满足：

所有测试通过，已有测试不因新功能被破坏
各项覆盖率指标（statements / branches / functions / lines）不低于开发前（见 vitest.config.ts 中的 thresholds）
如有覆盖率下降，必须补充对应测试，不允许降低 thresholds 阈值来通过检查

Step 5：汇报并提示提交

完成后向用户说明：

实现了哪些功能（对应 Step 1 确认的规格逐条说明）
改动了哪些文件（分层列出：DB / 后端 / 前端）
新增或修改了哪些测试，覆盖了哪些关键行为
提示用户可以提交，建议格式（遵循 COMMIT_CONVENTION.md）：

feat(<scope>): <用一句话描述新功能>

- 实现：...
- 关联变更：DB 新增 xxx 字段 / 前端新增 xxx 组件 / ...
- 测试：新增 X 条用例覆盖 ...

注意事项

需求变更：实现过程中如发现需求与现有设计冲突，立即暂停并回到 Step 1 重新澄清，不要自行决策
范围克制：不要在做新功能时顺手"改善"相关代码，除非是功能所必需
向后兼容：新字段默认值、新 API 参数可选性，确保存量数据和调用方不受影响
TypeScript 优先：类型收窄优于 any，每次改动后保持零类型错误

Install 新功能开发流程 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.

# 新功能开发与改进标准流程 > 与 Bug 修复流程（先写失败测试再修代码）不同，新功能的需求往往在实现过程中才逐渐清晰。 > 本流程采用**混合策略**：先澄清需求、再渐进实现，契约测试随实现同步、行为测试最后补全。按以下步骤执行，**遇到需求不清晰时必须停下来澄清，不要猜测继续推进**。 --- ## Step 1：需求澄清（Clarification） 1. **复述理解**：用自己的话描述功能目标，确认与用户对齐 2. **识别模糊点**：主动提问，重点关注： - 业务规则边界（如：新字段的合法值范围、默认值是什么？） - 与现有功能的潜在冲突（如：新逻辑是否与已有调度机制矛盾？） - 优先级（核心功能 vs 增强功能，哪些本次必做？） 3. **写下最终确认的规格**，一两句话描述每个要实现的行为 > ⚠️ **暂停点：将理解到的需求规格呈现给用户，等待用户明确确认后方可进入 Step 2。** > 如果用户补充或修正了需求，必须重新梳理后再次确认。 --- ## Step 2：影响范围分析（Impact Analysis）在写任何代码前，先梳理： 1. **数据库层**：是否需要新增字段或表？迁移是否幂等(`NOT EXISTS`/`ON CONFLICT`)? 2. **类型层**：后端 `types/index.ts`、前端 `types/index.ts` 需要同步更新哪些类型？ 3. **后端路由层**：哪些接口的入参/出参/逻辑需要改动？是否影响现有接口的调用方？ 4. **前端层**：API 调用层、页面组件、状态管理哪些需要联动？ 5. **测试层**：哪些已有测试用例可能因此被影响？是否需要修改 `helpers.ts`？列出要修改的文件清单，按依赖顺序排列（下层先改，不要从 UI 开始）。 > ⚠️ **暂停点：将改动范围及文件清单展示给用户，等待用户确认后方可开始实现。** > 如果用户对影响范围有异议（如不希望改某个接口），必须重新评估影响范围。 --- ## Step 3：渐进式实现（Incremental Implementation）按以下层次顺序实现，**每完成一层做一次编译验证**： ### 3.1 数据库 Schema - 新增字段使用幂等 `ALTER TABLE ... ADD COLUMN IF NOT EXISTS` 或通过 `planNewCols` 列表 - 设置合理的 `DEFAULT` 值确保存量数据兼容 ### 3.2 后端类型与路由 - 先更新 `types/index.ts`，再改路由和业务逻辑 - 路由中同步增加**入参校验**（非法值返回 400）和**存在性校验**（不存在返回 404） - 路由改完后，立即运行： ```bash npx tsc --noEmit ``` 类型错误**必须清零**再继续 ### 3.3 前端类型与 API 层 - 更新前端 `types/index.ts` 与后端保持同步 - 更新 `api/index.ts` 函数签名，新增可选参数时注意向后兼容 ### 3.4 前端 UI - 完成 UI 后再次运行 TypeScript 检查 ### 3.5 阶段性验证每完成一个后端路由的改动，用以下方式快速验证： - `curl` 或 Postman 手动调接口 - 或直接运行对应的测试文件：`npx vitest run src/routes/xxx.test.ts` --- ## Step 4：测试补充（Testing） > 测试范围：**仅后端接口测试**（`backend/src/**/*.test.ts`），不涉及前端。新功能测试采用**混合策略**，分两类写： ### 4.1 契约测试（随实现同步写）每写完一条路由，立即补充以下测试： - 缺少必要参数 → 400 - 非法参数值 → 400（含边界值） - 资源不存在 → 404 - 正常创建/更新 → 201/200，返回结构正确这类测试成本低、不依赖业务决策，应**随手写**。 ### 4.2 行为测试（业务逻辑稳定后补写）等核心业务逻辑（联锁逻辑、调度算法、状态流转）实现并稳定后，补充： - 核心业务路径的正确行为（如：解锁链在不同 `target_level` 下的差异） - 边界条件（如：`stage=5` 上限、`remaining_days=1` 时全量出词） - 状态一致性（如：答对 vs 答错对 mastery 的不同影响） ### 4.3 修改 helpers.ts 如果新增了必要的测试辅助函数或扩展了 `createXxx` 辅助函数，确保： - 新参数设置合理**默认值**（向后兼容已有调用） - 在函数注释中说明新参数含义 ### 4.4 回归测试（含覆盖率）在 `backend/` 目录运行： ```bash npm run test:coverage ``` **必须满足**： 1. 所有测试通过，已有测试不因新功能被破坏 2. 各项覆盖率指标（statements / branches / functions / lines）**不低于开发前**（见 `vitest.config.ts` 中的 `thresholds`） 3. 如有覆盖率下降，必须补充对应测试，**不允许降低 thresholds 阈值来通过检查** --- ## Step 5：汇报并提示提交完成后向用户说明： - 实现了哪些功能（对应 Step 1 确认的规格逐条说明） - 改动了哪些文件（分层列出：DB / 后端 / 前端） - 新增或修改了哪些测试，覆盖了哪些关键行为 - 提示用户可以提交，建议格式（遵循 [COMMIT_CONVENTION.md](../../COMMIT_CONVENTION.md)）： ``` feat(<scope>): <用一句话描述新功能> - 实现：... - 关联变更：DB 新增 xxx 字段 / 前端新增 xxx 组件 / ... - 测试：新增 X 条用例覆盖 ... ``` --- ## 注意事项 - **需求变更**：实现过程中如发现需求与现有设计冲突，立即暂停并回到 Step 1 重新澄清，不要自行决策 - **范围克制**：不要在做新功能时顺手"改善"相关代码，除非是功能所必需 - **向后兼容**：新字段默认值、新 API 参数可选性，确保存量数据和调用方不受影响 - **TypeScript 优先**：类型收窄优于 `any`，每次改动后保持零类型错误

{ "prompt": "# 新功能开发与改进标准流程\r\n\r\n> 与 Bug 修复流程（先写失败测试再修代码）不同，新功能的需求往往在实现过程中才逐渐清晰。\r\n> 本流程采用**混合策略**：先澄清需求、再渐进实现，契约测试随实现同步、行为测试最后补全。\r\n\r\n按以下步骤执行，**遇到需求不清晰时必须停下来澄清，不要猜测继续推进**。\r\n\r\n---\r\n\r\n## Step 1：需求澄清（Clarification）\r\n\r\n1. **复述理解**：用自己的话描述功能目标，确认与用户对齐\r\n2. **识别模糊点**：主动提问，重点关注：\r\n - 业务规则边界（如：新字段的合法值范围、默认值是什么？）\r\n - 与现有功能的潜在冲突（如：新逻辑是否与已有调度机制矛盾？）\r\n - 优先级（核心功能 vs 增强功能，哪些本次必做？）\r\n3. **写下最终确认的规格**，一两句话描述每个要实现的行为\r\n\r\n> ⚠️ **暂停点：将理解到的需求规格呈现给用户，等待用户明确确认后方可进入 Step 2。**\r\n> 如果用户补充或修正了需求，必须重新梳理后再次确认。\r\n\r\n---\r\n\r\n## Step 2：影响范围分析（Impact Analysis）\r\n\r\n在写任何代码前，先梳理：\r\n\r\n1. **数据库层**：是否需要新增字段或表？迁移是否幂等(`NOT EXISTS`/`ON CONFLICT`)?\r\n2. **类型层**：后端 `types/index.ts`、前端 `types/index.ts` 需要同步更新哪些类型？\r\n3. **后端路由层**：哪些接口的入参/出参/逻辑需要改动？是否影响现有接口的调用方？\r\n4. **前端层**：API 调用层、页面组件、状态管理哪些需要联动？\r\n5. **测试层**：哪些已有测试用例可能因此被影响？是否需要修改 `helpers.ts`？\r\n\r\n列出要修改的文件清单，按依赖顺序排列（下层先改，不要从 UI 开始）。\r\n\r\n> ⚠️ **暂停点：将改动范围及文件清单展示给用户，等待用户确认后方可开始实现。**\r\n> 如果用户对影响范围有异议（如不希望改某个接口），必须重新评估影响范围。\r\n\r\n---\r\n\r\n## Step 3：渐进式实现（Incremental Implementation）\r\n\r\n按以下层次顺序实现，**每完成一层做一次编译验证**：\r\n\r\n### 3.1 数据库 Schema\r\n\r\n- 新增字段使用幂等 `ALTER TABLE ... ADD COLUMN IF NOT EXISTS` 或通过 `planNewCols` 列表\r\n- 设置合理的 `DEFAULT` 值确保存量数据兼容\r\n\r\n### 3.2 后端类型与路由\r\n\r\n- 先更新 `types/index.ts`，再改路由和业务逻辑\r\n- 路由中同步增加**入参校验**（非法值返回 400）和**存在性校验**（不存在返回 404）\r\n- 路由改完后，立即运行：\r\n ```bash\r\n npx tsc --noEmit\r\n ```\r\n 类型错误**必须清零**再继续\r\n\r\n### 3.3 前端类型与 API 层\r\n\r\n- 更新前端 `types/index.ts` 与后端保持同步\r\n- 更新 `api/index.ts` 函数签名，新增可选参数时注意向后兼容\r\n\r\n### 3.4 前端 UI\r\n\r\n- 完成 UI 后再次运行 TypeScript 检查\r\n\r\n### 3.5 阶段性验证\r\n\r\n每完成一个后端路由的改动，用以下方式快速验证：\r\n- `curl` 或 Postman 手动调接口\r\n- 或直接运行对应的测试文件：`npx vitest run src/routes/xxx.test.ts`\r\n\r\n---\r\n\r\n## Step 4：测试补充（Testing）\r\n\r\n> 测试范围：**仅后端接口测试**（`backend/src/**/*.test.ts`），不涉及前端。\r\n\r\n新功能测试采用**混合策略**，分两类写：\r\n\r\n### 4.1 契约测试（随实现同步写）\r\n\r\n每写完一条路由，立即补充以下测试：\r\n- 缺少必要参数 → 400\r\n- 非法参数值 → 400（含边界值）\r\n- 资源不存在 → 404\r\n- 正常创建/更新 → 201/200，返回结构正确\r\n\r\n这类测试成本低、不依赖业务决策，应**随手写**。\r\n\r\n### 4.2 行为测试（业务逻辑稳定后补写）\r\n\r\n等核心业务逻辑（联锁逻辑、调度算法、状态流转）实现并稳定后，补充：\r\n- 核心业务路径的正确行为（如：解锁链在不同 `target_level` 下的差异）\r\n- 边界条件（如：`stage=5` 上限、`remaining_days=1` 时全量出词）\r\n- 状态一致性（如：答对 vs 答错对 mastery 的不同影响）\r\n\r\n### 4.3 修改 helpers.ts\r\n\r\n如果新增了必要的测试辅助函数或扩展了 `createXxx` 辅助函数，确保：\r\n- 新参数设置合理**默认值**（向后兼容已有调用）\r\n- 在函数注释中说明新参数含义\r\n\r\n### 4.4 回归测试（含覆盖率）\r\n\r\n在 `backend/` 目录运行：\r\n\r\n```bash\r\nnpm run test:coverage\r\n```\r\n\r\n**必须满足**：\r\n1. 所有测试通过，已有测试不因新功能被破坏\r\n2. 各项覆盖率指标（statements / branches / functions / lines）**不低于开发前**（见 `vitest.config.ts` 中的 `thresholds`）\r\n3. 如有覆盖率下降，必须补充对应测试，**不允许降低 thresholds 阈值来通过检查**\r\n\r\n---\r\n\r\n## Step 5：汇报并提示提交\r\n\r\n完成后向用户说明：\r\n\r\n- 实现了哪些功能（对应 Step 1 确认的规格逐条说明）\r\n- 改动了哪些文件（分层列出：DB / 后端 / 前端）\r\n- 新增或修改了哪些测试，覆盖了哪些关键行为\r\n- 提示用户可以提交，建议格式（遵循 [COMMIT_CONVENTION.md](../../COMMIT_CONVENTION.md)）：\r\n\r\n```\r\nfeat(<scope>): <用一句话描述新功能>\r\n\r\n- 实现：...\r\n- 关联变更：DB 新增 xxx 字段 / 前端新增 xxx 组件 / ...\r\n- 测试：新增 X 条用例覆盖 ...\r\n```\r\n\r\n---\r\n\r\n## 注意事项\r\n\r\n- **需求变更**：实现过程中如发现需求与现有设计冲突，立即暂停并回到 Step 1 重新澄清，不要自行决策\r\n- **范围克制**：不要在做新功能时顺手\"改善\"相关代码，除非是功能所必需\r\n- **向后兼容**：新字段默认值、新 API 参数可选性，确保存量数据和调用方不受影响\r\n- **TypeScript 优先**：类型收窄优于 `any`，每次改动后保持零类型错误", "variables": [], "notes": "新功能开发和改进的标准流程：需求澄清 → 影响分析 → 渐进式实现 → 测试补充 Arguments: 描述要新增的功能或改进点.", "metadata": { "source": { "provider": "github-prompts", "repository": "https://github.com/armink/word-master", "path": ".github/prompts/feature.prompt.md", "ref": "eae08b7b8e9efa81a6a9bb774c9b0e63bd945bb9", "url": "https://github.com/armink/word-master/blob/eae08b7b8e9efa81a6a9bb774c9b0e63bd945bb9/.github/prompts/feature.prompt.md", "key": "armink/word-master/.github/prompts/feature.prompt.md" } } }

新功能开发流程

About