メニュー
后端测试验证，基于 .plan/features.json 已完成任务驱动：运行单元测试 + 启动服务验证 API 契约 + 逐任务检查验收标准。支持读取 .plan/test-cases.json 执行用户提供的独立测试用例。当用户说 "/backend-test"、"后端测试"、"跑后端测试"、"验证后端"、"API 测试"、"跑测试用例" 时触发。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
将现有 Skill 项目改造成同时支持 Claude Code 和 Codex 的插件式安装项目，生成 .claude-plugin、.codex-plugin、marketplace、package.json 与 README 配置；安装命令默认不指定远程分支。
精简版后端开发编排，顺序执行四个核心 skill（plan-write → plan-next → code-simplifier → code-fixer）。当用户说 "/backend-single"、"精简开发" 时触发。需先运行 /plan-init 完成任务分解。适用于现有后端项目的功能开发。
智能开发团队编排，使用 Agent Team 协调六个 skill 的全流程自动化执行。当用户说 "/backend-team" 时触发。从方案预研到代码交付一站式完成。
新项目脚手架团队编排，从零开始搭建项目：需求收集 → 架构设计 → 脚手架搭建 → TDD 开发 → 验证 → CR。当用户说 "/framework-team" 时触发。适用于没有现有代码库的全新项目。
精简版前端开发编排，顺序执行四个核心 skill（plan-write → plan-next → code-simplifier → code-fixer）。当用户说 "/frontend-single"、"前端精简" 时触发。需先运行 /plan-init 完成任务分解。支持 React、Vue3、Vue2 框架自动检测。
前端开发团队编排，串联设计 → 编码 → 打磨 → 审查的完整流水线。当用户说 "/frontend-team" 时触发。支持 React、Vue3、Vue2 三种前端框架，集成 ui-ux-pro-max 设计系统和 frontend-design 美学指南。
| name | backend-test |
| description | 后端测试验证，基于 .plan/features.json 已完成任务驱动：运行单元测试 + 启动服务验证 API 契约 + 逐任务检查验收标准。支持读取 .plan/test-cases.json 执行用户提供的独立测试用例。当用户说 "/backend-test"、"后端测试"、"跑后端测试"、"验证后端"、"API 测试"、"跑测试用例" 时触发。 |
基于 .plan/features.json 已完成的后端任务，执行三层验证：单元测试 → API 契约验证 → 验收标准检查。
读取 features.json + test-cases.json → 框架检测 → 运行单元测试 → 启动服务 → API 契约验证 → 测试用例执行 → 验收标准检查 → 生成报告 → 清理
读取 .plan/features.json，过滤目标任务：
domain 字段：只取 domain=backend 且 passes: true 的任务/backend-test order-service）：进一步只取 app 匹配的任务domain 字段：取所有 passes: true 的任务appPath 路由：如果任务含 appPath 字段，在对应目录下执行测试。
如果无已完成任务，提示用户先完成开发，停止流程。
读取 .plan/test-cases.json（如存在）。
appPath 路由：如果 test-cases.json 含 serviceConfig.appPath，在对应目录下执行。
独立运行模式：如果 features.json 不存在或无已完成任务，但 test-cases.json 存在，则跳过 Step 1-2（单元测试和 API 契约验证），直接执行 Step 2.5（测试用例），仍然生成报告。
| 框架 | 检测条件 | 测试命令 | 启动命令 | 默认端口 | 健康检查路径 |
|---|---|---|---|---|---|
| Spring Boot | pom.xml / build.gradle 含 spring-boot | mvn test / ./gradlew test | mvn spring-boot:run / ./gradlew bootRun | 8080 | /actuator/health |
| Go (Gin/Echo/Fiber) | go.mod + main.go | go test ./... | go run . | 8080 | /health 或 / |
| FastAPI | requirements.txt 含 fastapi | pytest | uvicorn app.main:app --port 8000 | 8000 | /docs 或 /health |
| Flask | requirements.txt 含 flask | pytest | flask run --port 5000 | 5000 | / |
| Express | package.json 含 express | npm test | npm run dev 或 node app.js | 3000 | / |
| NestJS | package.json 含 @nestjs/core | npm test | npm run start:dev | 3000 | / |
无法自动检测时，AskUserQuestion 询问启动命令、端口、健康检查路径。
执行框架对应的测试命令，收集结果：
<测试命令> 2>&1
记录：通过数 / 失败数 / 跳过数 / 总耗时。
如果测试全部通过 → 继续 Step 2。 如果有失败 → 记录失败详情，继续 Step 2（不中断流程）。
扫描已完成任务中的 apiContracts 字段，同时收集测试用例：
测试用例来源（按优先级）：
dataSamples 字段：使用预定义的测试数据对于业务逻辑复杂的接口（涉及具体业务规则、权限校验、状态机等），优先询问用户是否要提供测试用例：
以下接口涉及业务逻辑，建议提供测试用例以确保验证准确：
1. POST /api/orders - 创建订单（涉及库存校验、价格计算）
2. PUT /api/users/:id/role - 修改用户角色（涉及权限校验）
请提供测试数据（JSON 格式），或回复"自动生成"让我根据代码逻辑构造。
如果任务中没有 apiContracts，跳过此步。
nohup <启动命令> > /tmp/backend-test-server.log 2>&1 &
记录 PID，轮询健康检查（每 3s 一次，超时 90s）。
对每个 apiContract 中的接口，用收集到的测试用例发请求：
curl -s -w "\n%{http_code}\n%{time_total}" \
-X <METHOD> \
-H "Content-Type: application/json" \
-d '<request body>' \
http://localhost:<端口><path>
验证规则：
| 维度 | 验证内容 | PASS 条件 |
|---|---|---|
| 状态码 | 与 apiContracts.response.code 对比 | 匹配 |
| 响应结构 | 检查响应 JSON 是否包含契约定义的字段 | 所有必需字段存在 |
| 响应类型 | Content-Type 检查 | application/json |
| 响应时间 | 记录耗时 | < 10s |
通用 FAIL 条件：状态码 5xx、连接拒绝、响应超时(>10s)。
kill <PID>
# 如 PID 无效
lsof -ti:<端口> | xargs kill -9
清理临时日志。
跳过条件：.plan/test-cases.json 不存在。
如果 Step 2 已启动服务且端口相同 → 复用（不重复启动）。
否则：
serviceConfig.setupCommands（如有）serviceConfig.framework 为 "auto" 时使用 Step 0 的检测结果填充 startCommand/port/healthCheck；用户在 serviceConfig 中指定的值优先serviceConfig.envVarsnohup <startCommand> > /tmp/backend-test-tc-server.log 2>&1 &构建变量上下文：
variables 全局变量作为初始值saveAs 在执行后追加到变量上下文替换所有 {{variableName}} 占位符（出现在 path、headers、body 中）。
对 testSuites 中的每个套件：
sequential: true → 按数组顺序执行测试sequential: false → 测试可按任意顺序执行对套件中的每个测试：
dependsOn — 如果前置测试失败或被跳过，标记 SKIP 并记录原因{{变量}} 占位符curl -s -w "\n%{http_code}\n%{time_total}" \
-X <method> \
-H "<header>: <value>" \
-d '<body>' \
http://localhost:<port><path>
expected.status → 状态码匹配expected.bodyContains → 响应体包含指定字符串列表中的每一项expected.bodyMatch → 响应体字段值匹配（深度比较）expected.maxResponseTime → 响应时间不超过阈值（默认 10s）saveAs：从响应 JSON 中提取值，加入变量上下文
echo $response | jq -r '<jsonpath>'如果 2.5.1 中新启动了服务（非复用 Step 2 的）：
kill <PID>
# 如 PID 无效
lsof -ti:<端口> | xargs kill -9
清理临时日志。
逐任务检查 acceptance 字段中的每条验收标准：
后端测试报告
===========
框架: {框架名}
已完成任务: {N} 个
1. 单元测试: [PASS/FAIL] ({通过数}/{总数} 通过, 耗时 {X}s)
2. API 契约验证: [X/Y 通过]
任务 2 "用户 API 实现":
- GET /api/users [PASS] (200, 45ms)
- POST /api/users [PASS] (201, 62ms)
任务 3 "订单 API 实现":
- POST /api/orders [FAIL] (500, 120ms, "NullPointerException")
3. 测试用例: [X/Y 通过, Z 个套件] ← 仅有 test-cases.json 时显示
套件 "订单 API 集成测试" (顺序执行):
- tc-1 创建订单-正常数据 [PASS] (200, 62ms)
- tc-2 查询已创建订单 [PASS] (200, 35ms)
- tc-3 创建订单-无效数据 [PASS] (400, 28ms)
套件 "数据校验":
- tc-4 重复订单检测 [FAIL] (200 ≠ 409, 41ms)
4. 验收标准: [X/Y 通过]
任务 2: 3/3 通过
任务 3: 2/3 通过
- [FAIL] "订单创建成功后返回 order_id"
响应时间: 平均 {X}ms, 最慢 {X}ms ({接口名})
结论: [通过/不通过]
判定规则：
| 错误 | 处理 |
|---|---|
| features.json 不存在 | 提示先运行 /plan-init + /backend-single |
| 无已完成任务 | 提示先完成开发 |
| 框架无法检测 | AskUserQuestion 询问 |
| 服务启动失败/超时 | 输出日志，跳过 API 验证，继续验收检查 |
| 接口返回 5xx | 标记 FAIL，继续下一个 |
| 进程清理失败 | 通过端口号强制 kill |
| test-cases.json 格式错误 | 输出解析错误，跳过 Step 2.5，继续后续步骤 |
| 测试用例依赖的前置测试失败 | 标记 SKIP，记录原因，继续下一个测试 |
变量 {{xxx}} 未定义 | 输出警告，保留占位符原文发送请求 |