feat: monorepo 重构 + 新增 5 个平台适配器
项目从单体结构重构为 pnpm monorepo (shared/backend/frontend)， 新增 YouTube、Instagram、Twitter/X、哔哩哔哩、微博 5 个平台适配器， 包含完整的单元测试和 E2E 测试覆盖。 - 完成 T-031~T-044: 5 个适配器实现、注册、配置和测试 - 重构前后端分离: Hono 后端 + Next.js 前端 - 151 个单元测试 + 21 个 Mock E2E + 25 个真实 E2E - 适配器基于真实 TikHub API 响应结构实现 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
wxs
@@ -0,0 +1,122 @@
|
||||
# CLAUDE.md
|
||||
|
||||
This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
|
||||
|
||||
|
||||
## 最重要的事情
|
||||
|
||||
1. **TDD 先行** - fix/feat 必须先写失败测试，红黄绿循环
|
||||
2. **原子提交** - 每个 commit 只做一件事，可独立回滚
|
||||
3. **文档驱动** - feat 改动关联 doc/ 下文档，多输出表格、流程图、ASCII 原型图
|
||||
4. **知识沉淀** - 有价值的迭代沉淀到 CLAUDE.md（拿捏不准主动问我）
|
||||
5. **利用现有工具** - 不重复造轮子，会开车 > 会修车
|
||||
6. **有头有尾** - 头：确认清楚再动手，不清楚就一直问；尾：自己跑验证，不把验证甩给用户
|
||||
7. **任务结束后追加** - 主人，用不用我沉淀 or git 提交？
|
||||
|
||||
## 项目概述
|
||||
|
||||
**{{项目名称}}** — {{一句话描述}}
|
||||
|
||||
**产品目标**：
|
||||
- {{目标1}}
|
||||
- {{目标2}}
|
||||
- {{目标3}}
|
||||
|
||||
## 技术栈
|
||||
|
||||
| 层级 | 技术 | 说明 |
|
||||
|------|------|------|
|
||||
| 前端 | {{前端技术}} | {{说明}} |
|
||||
| 后端 | {{后端技术}} | {{说明}} |
|
||||
| 数据库 | {{数据库}} | {{说明}} |
|
||||
| 缓存 | {{缓存方案，如无可删除此行}} | {{说明}} |
|
||||
| AI 服务 | {{AI 服务，如无可删除此行}} | {{说明}} |
|
||||
| 部署 | {{部署方案}} | {{说明}} |
|
||||
|
||||
## 项目结构
|
||||
|
||||
```
|
||||
{{项目名称}}/
|
||||
├── {{目录1}}/ # {{说明}}
|
||||
│ ├── {{子目录}}/ # {{说明}}
|
||||
│ └── {{子目录}}/ # {{说明}}
|
||||
├── doc/ # 项目文档
|
||||
│ ├── PRD.md
|
||||
│ ├── DevelopmentPlan.md
|
||||
│ └── tasks.md
|
||||
└── {{其他文件}} # {{说明}}
|
||||
```
|
||||
|
||||
## 常用命令
|
||||
|
||||
### 开发
|
||||
|
||||
```bash
|
||||
{{开发启动命令}}
|
||||
```
|
||||
|
||||
### 构建
|
||||
|
||||
```bash
|
||||
{{构建命令}}
|
||||
```
|
||||
|
||||
### 测试
|
||||
|
||||
```bash
|
||||
{{测试命令}}
|
||||
```
|
||||
|
||||
### 部署
|
||||
|
||||
```bash
|
||||
{{部署命令}}
|
||||
```
|
||||
|
||||
## 开发约定
|
||||
|
||||
- **包管理器**: 使用 {{包管理器}}（不是 {{其他包管理器}}）
|
||||
- **TDD 流程**: 先写测试再实现，核心业务逻辑覆盖率 100%
|
||||
- **日志规范**: 使用日志管理器，避免 console.log
|
||||
- **知识沉淀**: 将有价值的对话迭代沉淀到文档中，包括：
|
||||
- 重要技术决策和架构演进 → 更新 CLAUDE.md 相关章节
|
||||
- 新功能实现方案 → 更新组件职责、数据流等章节
|
||||
- 踩坑经验和解决方案 → 添加到踩坑经验章节
|
||||
- API 使用技巧和注意事项 → 更新相关技术栈说明
|
||||
|
||||
{{在此添加项目特定的开发约定}}
|
||||
|
||||
## 交互准则
|
||||
|
||||
### 任务有头有尾
|
||||
|
||||
**头 — 确认清楚再动手**：
|
||||
- 收到任务后，先复述理解、列出不确定的点
|
||||
- 不确定就问，一直问到双方对齐为止，**绝不带着假设开工**
|
||||
- 确认范围边界：做什么、不做什么、验收标准
|
||||
|
||||
**尾 — 自己验证，说到做到**：
|
||||
- 任务完成后，自己执行验证（跑测试、构建、截图、检查输出等）
|
||||
- 把验证结果直接展示给用户，而不是列一堆步骤让用户自己验
|
||||
- 验证不通过就自己修，循环直到通过
|
||||
- 最终交付物 = 已通过的验证结果根据既定的方案（所以倒逼开始的时候更明确才执行，否则自己打自己的脸。）
|
||||
|
||||
### 其他
|
||||
|
||||
- 任务彻底结束后，追加一句：**主人，用不用我沉淀 or git 提交？**
|
||||
|
||||
## 踩坑经验
|
||||
|
||||
<!-- 格式示例：
|
||||
|
||||
### {{问题简述}}
|
||||
|
||||
**问题现象**：{{描述现象}}
|
||||
|
||||
**根因**：{{分析根因}}
|
||||
|
||||
**解决方案**：{{解决方案}}
|
||||
|
||||
**注意事项**：{{补充说明}}
|
||||
|
||||
-->
|
||||
@@ -0,0 +1 @@
|
||||
just empety...
|
||||
@@ -0,0 +1,109 @@
|
||||
---
|
||||
name: changelog
|
||||
description: 一键发版：生成更新日志 → commit → 打 tag，全流程自动化。
|
||||
---
|
||||
|
||||
# Changelog - 一键发版
|
||||
|
||||
> **定位**：发版全流程。`/changelog 1.0.0227.1` 一个命令搞定日志生成 + commit + tag。
|
||||
|
||||
## 用法
|
||||
|
||||
```
|
||||
/changelog <version> # 例: /changelog 1.0.0227.1
|
||||
/changelog # 不传版本号则自动推断
|
||||
```
|
||||
|
||||
## 执行流程
|
||||
|
||||
### 1. 确定版本号
|
||||
|
||||
**有参数**：直接使用用户传入的版本号。
|
||||
|
||||
**无参数**：自动推断。读取最新 tag，bump build 号 +1。例如当前最新 `v1.1.0211.1` → 推断为 `1.1.0211.2`。若无 tag 则提示用户输入。
|
||||
|
||||
版本格式：`{major}.{minor}.{MMDD}.{build}`
|
||||
|
||||
### 2. 获取 Commits
|
||||
|
||||
```bash
|
||||
# 找到上一个 tag
|
||||
git tag --sort=-creatordate
|
||||
|
||||
# 读取 commits（从上一个 tag 到 HEAD）
|
||||
git log {prev_tag}..HEAD --oneline --no-merges
|
||||
```
|
||||
|
||||
如果没有上一个 tag，则从初始 commit 开始。
|
||||
|
||||
### 3. AI 总结
|
||||
|
||||
将 commit 列表总结为用户友好的中文更新说明：
|
||||
|
||||
| type | emoji | 说明 |
|
||||
|------|-------|------|
|
||||
| feat | ✨ | 新功能 / 新 Skill |
|
||||
| fix | 🐛 | Bug 修复 |
|
||||
| refactor | ♻️ | 代码重构 |
|
||||
| docs | 📝 | 文档更新 |
|
||||
| chore | 🔧 | 杂项维护 |
|
||||
|
||||
规则：
|
||||
- 每条说明 1 句话，简洁明了
|
||||
- 合并相关的小 commit 为一条
|
||||
- 面向用户描述（不要出现技术细节如文件名、函数名）
|
||||
- summary：一句话概括本次更新的核心主题
|
||||
|
||||
### 4. 展示草稿，等待确认
|
||||
|
||||
```
|
||||
📦 v{version} · {date}
|
||||
{summary}
|
||||
|
||||
✨ 新增 /go 执行按钮 Skill...
|
||||
📝 更新 README 文档格式...
|
||||
🐛 修复仓库 URL 配置...
|
||||
```
|
||||
|
||||
**必须等用户确认或修改后才继续**。
|
||||
|
||||
### 5. 写入文件
|
||||
|
||||
用户确认后，更新 `CHANGELOG.md`：
|
||||
|
||||
- 文件不存在时创建，头部加 `# Changelog` 标题
|
||||
- 将新条目插入已有内容**头部**（标题行之后，最新版本在前），保持现有条目不变
|
||||
- 条目格式：
|
||||
|
||||
```markdown
|
||||
## v{version} ({YYYY-MM-DD})
|
||||
|
||||
{summary}
|
||||
|
||||
- ✨ xxx
|
||||
- 🐛 xxx
|
||||
- ♻️ xxx
|
||||
```
|
||||
|
||||
### 6. Commit + Tag
|
||||
|
||||
```bash
|
||||
# Stage 变更文件
|
||||
git add CHANGELOG.md
|
||||
|
||||
# Commit
|
||||
git commit -m "release: v{version}"
|
||||
|
||||
# 打 tag
|
||||
git tag v{version}
|
||||
```
|
||||
|
||||
### 7. 完成提示
|
||||
|
||||
```
|
||||
✅ 发版完成！
|
||||
- 📝 CHANGELOG.md: 新增 v{version} 条目
|
||||
- 🏷️ git tag: v{version}
|
||||
|
||||
需要 push 到远程吗？(git push && git push --tags)
|
||||
```
|
||||
@@ -0,0 +1,316 @@
|
||||
---
|
||||
name: deploy
|
||||
description: Drone CI + 服务器 CD 全流程引导：从基础设施检查到生成配置文件到验证部署，交互式完成。
|
||||
---
|
||||
|
||||
# Deploy - CI/CD 全流程部署引导
|
||||
|
||||
> **定位**：基于公司 Drone CI + 私有 Docker Registry + Docker Compose 的自动化部署方案，交互式引导用户从零完成 CI/CD 接入。
|
||||
|
||||
当用户调用 `/deploy` 或 `/deploy <指令>` 时，执行以下步骤：
|
||||
|
||||
## 1. 收集项目信息
|
||||
|
||||
快速了解项目情况（已知的不重复问）：
|
||||
|
||||
| 项目 | 说明 | 示例 |
|
||||
|------|------|------|
|
||||
| 项目名称 | 用于镜像命名 | `douyin`, `crm`, `blog` |
|
||||
| 需构建的服务 | 每个服务对应一个镜像 | `backend`, `frontend` |
|
||||
| 各服务的 Dockerfile 路径 | Docker build context | `./backend`, `./frontend` |
|
||||
| 生产服务器 SSH 端口 | 默认 22 | `22`, `3141` |
|
||||
| 部署目录 | 生产服务器上的路径 | `/opt/docker/myproject` |
|
||||
| 数据库迁移命令 | 如有 | `alembic upgrade head`, `npx prisma migrate deploy` |
|
||||
| 健康检查方式 | 三选一 | python / curl / host |
|
||||
| 健康检查 URL | 容器内地址 | `http://127.0.0.1:8000/health` |
|
||||
| 通知 Webhook | 可选，不配则跳过 | 企业微信/钉钉/飞书 |
|
||||
|
||||
确认后进入下一步。
|
||||
|
||||
## 2. 基础设施检查
|
||||
|
||||
输出 Checklist，让用户逐项确认（首次接入需全部完成，后续项目可跳过）：
|
||||
|
||||
```
|
||||
□ 基础设施（一次性，已完成则跳过）
|
||||
□ Drone CI Server + Runner 已部署运行
|
||||
□ 私有 Docker Registry 已运行（默认 :5000）
|
||||
□ insecure-registries 已配置（Drone CI 服务器 + 生产服务器）
|
||||
□ SSH 密钥已配置（Drone CI 服务器 → 生产服务器免密登录）
|
||||
□ 生产服务器用户已加入 docker 组
|
||||
```
|
||||
|
||||
如果用户表示基础设施未就绪，输出对应的一次性搭建指引（参见下方「附录：基础设施搭建」）。
|
||||
|
||||
## 3. 生成配置文件
|
||||
|
||||
基于收集到的信息，生成以下文件：
|
||||
|
||||
### 3.1 `.drone.yml`
|
||||
|
||||
核心原则（踩坑总结，不可违反）：
|
||||
1. 使用 `docker:27-cli` + 宿主机 Docker socket，**不用** `plugins/docker` DinD
|
||||
2. 使用 `environment: { VAR: { from_secret: name } }` 注入密钥，**不用** `secrets:` 字段
|
||||
3. 使用 `${DRONE_TAG:-latest}` 作为镜像 tag，**不自定义中间变量**（Drone 变量替换冲突）
|
||||
4. 触发条件只用 `event: [tag, cron]`，**不叠加** `cron: [name]`（AND 运算陷阱）
|
||||
|
||||
生成内容包括：
|
||||
- `trigger`: tag + cron
|
||||
- `volumes`: 挂载宿主机 Docker socket
|
||||
- 每个服务的 `build-<service>` step
|
||||
- `deploy` step（使用 `appleboy/drone-ssh`）
|
||||
- `notify-success` / `notify-failure` step（如配置了 Webhook）
|
||||
|
||||
### 3.2 `scripts/deploy-remote.sh`
|
||||
|
||||
部署脚本要点：
|
||||
- `set -euo pipefail` 严格模式
|
||||
- 部署锁（PID 文件防并发）
|
||||
- 同时 export `IMAGE_TAG` 和 `VERSION`（兼容不同 compose 变量命名）
|
||||
- 按顺序：pull → 停 beat → 更新核心服务 → 健康检查 → 数据库迁移 → 启动剩余服务 → 最终健康检查
|
||||
- 健康检查根据用户选择的方式生成（python / curl / host）
|
||||
|
||||
### 3.3 生成后展示
|
||||
|
||||
```
|
||||
已生成：
|
||||
📄 .drone.yml — Drone CI 流水线配置
|
||||
📄 scripts/deploy-remote.sh — 远程部署脚本
|
||||
|
||||
确认写入？[Y/n]
|
||||
```
|
||||
|
||||
用户确认后写入文件。
|
||||
|
||||
## 4. Drone 面板配置引导
|
||||
|
||||
生成文件后，输出需要在 Drone 面板手动配置的清单：
|
||||
|
||||
### 4.1 仓库设置
|
||||
|
||||
```
|
||||
在 Drone 面板完成以下配置：
|
||||
|
||||
1. 激活仓库：SYNC → 找到仓库 → ACTIVATE
|
||||
2. 开启 Trusted：Settings → General → Project Settings → 勾选 Trusted
|
||||
```
|
||||
|
||||
### 4.2 Secrets 配置
|
||||
|
||||
根据收集到的信息，输出具体的 Secret 列表：
|
||||
|
||||
```
|
||||
在 Drone 面板 → 仓库 Settings → Secrets 添加：
|
||||
|
||||
| Secret 名称 | 填写内容 |
|
||||
|-------------------|----------------------------------------------------|
|
||||
| backend_repo | docker.internal.intelligrow.cn:5000/{project}-backend |
|
||||
| frontend_repo | docker.internal.intelligrow.cn:5000/{project}-frontend |
|
||||
| deploy_host | {生产服务器 IP} |
|
||||
| deploy_user | {SSH 用户} |
|
||||
| deploy_ssh_key | cat ~/.ssh/drone_deploy 的完整内容 |
|
||||
| deploy_path | {部署目录} |
|
||||
| wecom_webhook | {Webhook URL}（如已配置） |
|
||||
```
|
||||
|
||||
### 4.3 Cron 配置（可选）
|
||||
|
||||
```
|
||||
如需定时构建，在 Settings → Cron Jobs 添加：
|
||||
|
||||
| 字段 | 值 | 说明 |
|
||||
|----------|------------------|-------------------------|
|
||||
| Name | nightly-build | 任务名称 |
|
||||
| Branch | main | 构建分支 |
|
||||
| Schedule | 0 16 * * * | UTC 16:00 = 北京 00:00 |
|
||||
```
|
||||
|
||||
## 5. 生产服务器配置引导
|
||||
|
||||
```
|
||||
在生产服务器上确认：
|
||||
|
||||
1. 部署目录结构：
|
||||
{deploy_path}/
|
||||
├── docker-compose.prod.yml
|
||||
├── .env
|
||||
└── scripts/
|
||||
└── deploy-remote.sh ← 需从代码仓库复制
|
||||
|
||||
2. .env 至少包含：
|
||||
DOCKER_REGISTRY=docker.internal.intelligrow.cn:5000
|
||||
（其他数据库密码等生产配置）
|
||||
|
||||
3. docker-compose.prod.yml 中镜像引用格式：
|
||||
image: ${DOCKER_REGISTRY}/{project}-backend:${VERSION:-latest}
|
||||
|
||||
⚠️ 变量一致性：Drone Secret 的镜像地址前缀 = .env 的 DOCKER_REGISTRY = compose 中的镜像名拼接结果
|
||||
```
|
||||
|
||||
## 6. 验证
|
||||
|
||||
自己执行可执行的验证，不能远程执行的给出命令让用户确认结果：
|
||||
|
||||
### 6.1 本地验证（自己执行）
|
||||
|
||||
```bash
|
||||
# 检查 .drone.yml 语法合法性（YAML 解析）
|
||||
# 检查 deploy-remote.sh 语法（bash -n）
|
||||
# 检查文件是否已正确写入
|
||||
```
|
||||
|
||||
### 6.2 远程验证引导（输出命令，让用户在服务器上执行并反馈结果）
|
||||
|
||||
```bash
|
||||
# 推送 Tag 触发首次构建
|
||||
git tag v{version}
|
||||
git push origin v{version}
|
||||
|
||||
# 观察 Drone 面板 pipeline 状态
|
||||
|
||||
# 生产服务器检查
|
||||
ssh -p {port} {user}@{host} "cd {deploy_path} && docker compose -f docker-compose.prod.yml ps"
|
||||
```
|
||||
|
||||
## 7. 完成输出
|
||||
|
||||
```
|
||||
✅ CI/CD 接入完成！
|
||||
|
||||
📄 生成的文件：
|
||||
- .drone.yml
|
||||
- scripts/deploy-remote.sh
|
||||
|
||||
🔧 Drone 面板配置（需手动）：
|
||||
- [x] 仓库已激活
|
||||
- [x] Trusted 已开启
|
||||
- [x] Secrets 已添加
|
||||
- [ ] Cron Job（可选）
|
||||
|
||||
🖥️ 生产服务器：
|
||||
- [ ] .env 已配置
|
||||
- [ ] deploy-remote.sh 已复制
|
||||
- [ ] 首次部署成功
|
||||
|
||||
📖 回滚方案：
|
||||
方式1: ssh 到生产服务器执行 bash scripts/deploy-remote.sh {旧版本tag}
|
||||
方式2: git tag {旧版本}-rollback {旧版本} && git push origin {旧版本}-rollback
|
||||
|
||||
主人，用不用我沉淀 or git 提交？
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 附录：基础设施搭建
|
||||
|
||||
当用户表示基础设施未就绪时，按需输出以下指引：
|
||||
|
||||
### A. Drone CI 部署
|
||||
|
||||
在 Drone CI 服务器创建 `~/drone/docker-compose.yml`：
|
||||
|
||||
```yaml
|
||||
services:
|
||||
drone-server:
|
||||
image: drone/drone:2
|
||||
container_name: drone-server
|
||||
restart: always
|
||||
ports:
|
||||
- "3080:80"
|
||||
environment:
|
||||
- DRONE_GITEA_SERVER=https://<your-gitea-domain>
|
||||
- DRONE_GITEA_CLIENT_ID=<gitea-oauth-client-id>
|
||||
- DRONE_GITEA_CLIENT_SECRET=<gitea-oauth-client-secret>
|
||||
- DRONE_SERVER_HOST=<your-drone-domain>
|
||||
- DRONE_SERVER_PROTO=https
|
||||
- DRONE_RPC_SECRET=<openssl rand -hex 16 生成>
|
||||
- DRONE_USER_CREATE=username:<gitea用户名>,admin:true
|
||||
volumes:
|
||||
- ./data:/data
|
||||
|
||||
drone-runner:
|
||||
image: drone/drone-runner-docker:1
|
||||
container_name: drone-runner
|
||||
restart: always
|
||||
depends_on:
|
||||
- drone-server
|
||||
environment:
|
||||
- DRONE_RPC_PROTO=http
|
||||
- DRONE_RPC_HOST=drone-server
|
||||
- DRONE_RPC_SECRET=<与 server 相同>
|
||||
- DRONE_RUNNER_CAPACITY=2
|
||||
- DRONE_RUNNER_NAME=drone-runner-1
|
||||
volumes:
|
||||
- /var/run/docker.sock:/var/run/docker.sock
|
||||
```
|
||||
|
||||
关键注意：
|
||||
- `DRONE_RPC_PROTO=http`：Runner 走 Docker 内网直连，不走 HTTPS
|
||||
- `DRONE_USER_CREATE` 的 username 必须与 Gitea **登录用户名**完全一致（不是邮箱）
|
||||
|
||||
### B. 私有 Registry
|
||||
|
||||
```bash
|
||||
docker run -d --name registry \
|
||||
-p 5000:5000 \
|
||||
-v /opt/registry-data:/var/lib/registry \
|
||||
--restart always \
|
||||
registry:2
|
||||
```
|
||||
|
||||
### C. insecure-registries 配置
|
||||
|
||||
在 Drone CI 服务器和生产服务器的 `/etc/docker/daemon.json` 添加：
|
||||
|
||||
```json
|
||||
{
|
||||
"insecure-registries": ["<registry-host>:5000"]
|
||||
}
|
||||
```
|
||||
|
||||
**不要带 `http://` 前缀**，直接写 `host:port`。修改后 `sudo systemctl restart docker`。
|
||||
|
||||
### D. SSH 免密
|
||||
|
||||
```bash
|
||||
# Drone CI 服务器上生成密钥
|
||||
ssh-keygen -t ed25519 -C "drone-ci-deploy" -f ~/.ssh/drone_deploy -N ""
|
||||
|
||||
# 将公钥添加到生产服务器
|
||||
ssh-copy-id -i ~/.ssh/drone_deploy.pub -p <port> <user>@<production-ip>
|
||||
|
||||
# 验证
|
||||
ssh -i ~/.ssh/drone_deploy -p <port> <user>@<production-ip> "echo ok"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 踩坑清单（生成配置时必须规避）
|
||||
|
||||
| # | 坑 | 正确做法 |
|
||||
|---|-----|---------|
|
||||
| 1 | `insecure-registries` 带 `http://` 前缀 | 直接写 `host:port` |
|
||||
| 2 | Drone `${VAR}` 与 shell 变量冲突 | 直接用 `${DRONE_TAG:-latest}`，不赋中间变量 |
|
||||
| 3 | 用 `secrets:` 字段注入 secret | 用 `environment: { VAR: { from_secret: name } }` |
|
||||
| 4 | `plugins/docker` DinD 启动失败 | 用 `docker:27-cli` + 挂载 Docker socket |
|
||||
| 5 | `DRONE_USER_CREATE` 填邮箱 | 必须填 Gitea 登录用户名 |
|
||||
| 6 | `event + cron` 触发条件互斥 | 只用 `event: [tag, cron]`，不加 `cron:` 过滤 |
|
||||
| 7 | Registry 地址不一致（IP vs 域名） | Drone Secret、`.env`、compose 三处统一 |
|
||||
| 8 | SSH 端口不对 | `appleboy/drone-ssh` 显式指定 `port` |
|
||||
| 9 | Docker 权限不足 | `sudo usermod -aG docker <user>` 后重新登录 |
|
||||
| 10 | `daemon.json` 被覆盖 | 修改前先 cat 查看，合并内容 |
|
||||
|
||||
---
|
||||
|
||||
## 故障排查速查表
|
||||
|
||||
| 现象 | 检查方向 |
|
||||
|------|---------|
|
||||
| Pipeline 不触发 | Gitea Webhook 是否勾选"创建"事件；`.drone.yml` trigger |
|
||||
| Step 一直 pending | Runner 是否连通 Server；仓库是否 Trusted |
|
||||
| 构建报 secret 为空 | `environment: from_secret` 而非 `secrets:` |
|
||||
| Docker push 失败 (HTTPS) | 两台服务器 `insecure-registries` 配置 |
|
||||
| SSH 部署超时 | 密钥是否正确；端口是否匹配；Docker 权限 |
|
||||
| 镜像名 invalid reference | `.env` 的 `DOCKER_REGISTRY` 变量是否正确 |
|
||||
| 数据库迁移失败 | `docker compose logs -f <service>` |
|
||||
| 健康检查超时 | 增大 `MAX_ATTEMPTS`；检查服务启动日志 |
|
||||
@@ -0,0 +1,325 @@
|
||||
---
|
||||
name: go
|
||||
description: 终极执行按钮，激进模式一口气完成开发任务，兼容 0->1 和 1->100 场景。
|
||||
---
|
||||
|
||||
# Go - 发射按钮
|
||||
|
||||
> **定位**：执行按钮。无论是从零开始的 0->1，还是迭代优化的 1->100，按下 `/go` 就开始干活，不要停。
|
||||
|
||||
当用户调用 `/go` 或 `/go <任务范围>` 时，执行以下步骤：
|
||||
|
||||
## 1. 前置检查
|
||||
|
||||
### 1.1 必要文档检查
|
||||
|
||||
检查以下文件是否存在：
|
||||
|
||||
| 文件 | 必要性 | 用途 |
|
||||
|------|--------|------|
|
||||
| `doc/tasks.md` | **必须** | 任务清单，执行的圣经 |
|
||||
| `doc/PRD.md` | **必须** | 产品需求，理解业务 |
|
||||
| `doc/FeatureSummary.md` | 建议 | 功能契约 |
|
||||
| `doc/DevelopmentPlan.md` | 建议 | 技术方案 |
|
||||
| `doc/UIDesign.md` | 可选 | 界面设计 |
|
||||
| `doc/tdd.md` | 可选 | 测试用例 |
|
||||
|
||||
**缺少必要文档时**：
|
||||
|
||||
```
|
||||
❌ 缺少必要文档：
|
||||
- doc/tasks.md (必须)
|
||||
- doc/PRD.md (必须)
|
||||
|
||||
请先准备这些文档，或运行：
|
||||
- /wp 生成 PRD
|
||||
- /wt 生成 tasks
|
||||
```
|
||||
|
||||
### 1.2 读取所有可用文档
|
||||
|
||||
读取存在的所有文档，建立完整上下文。
|
||||
|
||||
## 2. 智能判断执行范围
|
||||
|
||||
### 2.1 检测项目状态
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────┐
|
||||
│ 项目状态检测 │
|
||||
├─────────────────────────────────────────────────────────┤
|
||||
│ │
|
||||
│ 检查 src/ 或主代码目录是否存在？ │
|
||||
│ │
|
||||
│ ├── 不存在 ──▶ 0->1 模式（全新项目） │
|
||||
│ │ │
|
||||
│ └── 存在 ──▶ 检查 tasks.md 中的 ITER 标记 │
|
||||
│ │ │
|
||||
│ ├── 有 ITER 标记 ──▶ 1->100 模式 │
|
||||
│ │ │
|
||||
│ └── 无 ITER 标记 ──▶ 继续未完成任务 │
|
||||
│ │
|
||||
└─────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### 2.2 确定任务范围
|
||||
|
||||
**用户指定范围**：
|
||||
|
||||
```bash
|
||||
/go T-005 # 执行单个任务
|
||||
/go T-005~T-010 # 执行任务范围
|
||||
/go T-005 T-008 # 执行多个指定任务
|
||||
```
|
||||
|
||||
**自动判断范围**：
|
||||
|
||||
| 场景 | 执行范围 |
|
||||
|------|----------|
|
||||
| 0->1 全新项目 | tasks.md 中的所有任务，从 T-001 开始 |
|
||||
| 1->100 有 ITER 标记 | 优先执行 `<!-- ITER: -->` 标记的新任务 |
|
||||
| 1->100 无 ITER 标记 | 执行所有状态为 pending/todo 的任务 |
|
||||
|
||||
### 2.3 向用户确认范围（唯一一次交互）
|
||||
|
||||
```
|
||||
检测到项目状态：{0->1 全新项目 / 1->100 迭代项目}
|
||||
|
||||
即将执行任务：
|
||||
- T-001: {任务名}
|
||||
- T-002: {任务名}
|
||||
- ...
|
||||
- T-xxx: {任务名}
|
||||
|
||||
共 X 个任务。确认执行？[Y/n]
|
||||
```
|
||||
|
||||
**用户确认后，不再有任何交互，直到全部完成。**
|
||||
|
||||
## 3. 激进模式执行
|
||||
|
||||
### 3.1 执行原则
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────┐
|
||||
│ 激进模式执行原则 │
|
||||
├─────────────────────────────────────────────────────────┤
|
||||
│ │
|
||||
│ 1. 以 tasks.md 为圣经，严格按顺序执行 │
|
||||
│ │
|
||||
│ 2. 不要停下来问用户，自主决策 │
|
||||
│ │
|
||||
│ 3. 遇到问题自主修复，修复失败则记录并继续 │
|
||||
│ │
|
||||
│ 4. 发现文档冲突，基于架构经验选最优解，注释说明 │
|
||||
│ │
|
||||
│ 5. 利用所有可用工具：搜索、MCP、Skills │
|
||||
│ │
|
||||
│ 6. 每完成一个模块，Git 提交一次 │
|
||||
│ │
|
||||
└─────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### 3.2 任务执行流程
|
||||
|
||||
```
|
||||
对于每个任务 T-xxx：
|
||||
│
|
||||
├── 1. 读取任务详情（描述、验收标准、依赖）
|
||||
│
|
||||
├── 2. 检查依赖任务是否完成
|
||||
│ └── 未完成 → 先执行依赖任务
|
||||
│
|
||||
├── 3. 执行任务
|
||||
│ ├── 根据任务类型选择执行方式
|
||||
│ ├── 编写代码 / 配置 / 测试
|
||||
│ └── 验证验收标准
|
||||
│
|
||||
├── 4. 遇到问题？
|
||||
│ ├── 尝试自主修复（最多 3 次）
|
||||
│ ├── 修复成功 → 继续
|
||||
│ └── 修复失败 → 记录问题，跳过，继续下一个
|
||||
│
|
||||
└── 5. 标记任务完成，更新 tasks.md
|
||||
```
|
||||
|
||||
### 3.3 自主修复策略
|
||||
|
||||
| 问题类型 | 修复策略 |
|
||||
|----------|----------|
|
||||
| 编译错误 | 分析错误信息，修复代码 |
|
||||
| 类型错误 | 检查类型定义，修复类型 |
|
||||
| 依赖缺失 | 安装依赖包 |
|
||||
| 测试失败 | 修复功能代码使测试通过 |
|
||||
| 文档冲突 | 基于架构经验选最优解 |
|
||||
| 未知错误 | 搜索解决方案，尝试修复 |
|
||||
|
||||
## 4. Git 提交规则
|
||||
|
||||
### 4.1 提交时机
|
||||
|
||||
每完成一个**模块/Sprint**后立即提交：
|
||||
|
||||
```
|
||||
T-001 ~ T-004 → 提交一次（初始化模块）
|
||||
T-005 ~ T-008 → 提交一次（核心功能模块）
|
||||
T-009 ~ T-012 → 提交一次（扩展功能模块）
|
||||
...
|
||||
```
|
||||
|
||||
### 4.2 提交信息格式
|
||||
|
||||
```
|
||||
feat(<scope>): <简要描述>
|
||||
|
||||
- 完成 T-xxx: {任务名}
|
||||
- 完成 T-xxx: {任务名}
|
||||
- ...
|
||||
|
||||
Co-Authored-By: Claude <noreply@anthropic.com>
|
||||
```
|
||||
|
||||
**示例**：
|
||||
|
||||
```
|
||||
feat(auth): 完成用户认证模块
|
||||
|
||||
- 完成 T-005: 用户登录功能
|
||||
- 完成 T-006: 用户注册功能
|
||||
- 完成 T-007: JWT Token 管理
|
||||
- 完成 T-008: 权限验证中间件
|
||||
|
||||
Co-Authored-By: Claude <noreply@anthropic.com>
|
||||
```
|
||||
|
||||
## 5. 进度汇报
|
||||
|
||||
### 5.1 模块完成汇报
|
||||
|
||||
每完成一个模块，简要汇报：
|
||||
|
||||
```
|
||||
✅ 模块完成：{模块名}
|
||||
- T-005: 用户登录 ✓
|
||||
- T-006: 用户注册 ✓
|
||||
- T-007: JWT 管理 ✓
|
||||
- T-008: 权限验证 ✓
|
||||
|
||||
Git 提交: feat(auth): 完成用户认证模块
|
||||
|
||||
继续执行下一模块...
|
||||
```
|
||||
|
||||
### 5.2 最终汇报
|
||||
|
||||
全部完成后，输出完整报告：
|
||||
|
||||
```
|
||||
## 🚀 执行完成
|
||||
|
||||
**执行模式**: {0->1 全新项目 / 1->100 迭代}
|
||||
|
||||
**任务统计**:
|
||||
| 状态 | 数量 |
|
||||
|------|------|
|
||||
| ✅ 完成 | X 个 |
|
||||
| ⚠️ 跳过 | X 个 |
|
||||
| ❌ 失败 | X 个 |
|
||||
|
||||
**Git 提交记录**:
|
||||
- feat(init): 项目初始化
|
||||
- feat(auth): 用户认证模块
|
||||
- feat(core): 核心功能模块
|
||||
- ...
|
||||
|
||||
**跳过/失败的任务**（如有）:
|
||||
| 任务 | 原因 |
|
||||
|------|------|
|
||||
| T-xxx | {原因} |
|
||||
|
||||
**下一步建议**:
|
||||
- 运行 `npm run dev` 验证
|
||||
- 运行 `npm run test` 测试
|
||||
- 检查跳过的任务
|
||||
```
|
||||
|
||||
## 6. 特殊场景处理
|
||||
|
||||
### 6.1 技术栈识别
|
||||
|
||||
从文档中识别技术栈，自动适配：
|
||||
|
||||
| 识别来源 | 技术决策 |
|
||||
|----------|----------|
|
||||
| package.json 存在 | Node.js 项目 |
|
||||
| requirements.txt 存在 | Python 项目 |
|
||||
| DevelopmentPlan 指定 | 按文档技术栈 |
|
||||
| 无明确指定 | 询问用户（唯一例外） |
|
||||
|
||||
### 6.2 测试策略
|
||||
|
||||
- 功能开发完成后执行测试任务
|
||||
- 测试失败 → **先修复功能代码使测试通过**
|
||||
- 不跳过失败的测试继续部署
|
||||
|
||||
### 6.3 部署任务
|
||||
|
||||
- 先本地测试验证
|
||||
- 确保 build 和 start 正常
|
||||
- 远程部署需用户额外确认
|
||||
|
||||
---
|
||||
|
||||
## 工作流总览
|
||||
|
||||
```
|
||||
/go
|
||||
│
|
||||
├── 1. 前置检查
|
||||
│ ├── tasks.md 存在？ ──▶ 必须
|
||||
│ └── PRD.md 存在？ ──▶ 必须
|
||||
│
|
||||
├── 2. 读取文档，建立上下文
|
||||
│
|
||||
├── 3. 智能判断
|
||||
│ ├── 项目状态（0->1 / 1->100）
|
||||
│ └── 任务范围
|
||||
│
|
||||
├── 4. 确认执行范围（唯一交互）
|
||||
│
|
||||
├── 5. 激进模式执行
|
||||
│ ├── 按顺序执行任务
|
||||
│ ├── 自主修复问题
|
||||
│ ├── 模块完成 → Git 提交
|
||||
│ └── 汇报进度，继续下一个
|
||||
│
|
||||
└── 6. 最终汇报
|
||||
├── 任务统计
|
||||
├── Git 提交记录
|
||||
└── 下一步建议
|
||||
```
|
||||
|
||||
## 注意事项
|
||||
|
||||
- **tasks.md 是圣经**，严格按其顺序和内容执行
|
||||
- **不要停下来问用户**，自主决策，自主修复
|
||||
- **遇到无法解决的问题**，记录并跳过，最后汇报
|
||||
- **每完成模块立即提交**，避免大量代码丢失风险
|
||||
- **利用所有工具**：搜索、MCP、其他 Skills
|
||||
|
||||
## 与其他 Skill 的关系
|
||||
|
||||
| 场景 | 使用方式 |
|
||||
|------|----------|
|
||||
| 准备文档 | `/wp` `/wf` `/wd` `/wu` `/wt` |
|
||||
| 评审文档 | `/rp` `/rf` `/rd` `/ru` `/rt` |
|
||||
| 修改文档 | `/mp` `/mf` `/md` `/mu` `/mt` |
|
||||
| 迭代变更（更新文档） | `/iter` |
|
||||
| **执行开发（本 Skill）** | `/go` |
|
||||
|
||||
**典型工作流**：
|
||||
|
||||
```
|
||||
0->1：需求 → /wp → /wf → /wd → /wt → /go
|
||||
1->100：发现问题 → /iter → /go
|
||||
```
|
||||
@@ -0,0 +1,210 @@
|
||||
---
|
||||
name: iter
|
||||
description: 迭代变更入口，调研问题后更新 PRD.md 和 tasks.md，支持 Bug 修复、功能迭代、技术重构。
|
||||
---
|
||||
|
||||
# Iterate - 迭代变更
|
||||
|
||||
> **定位**：1-100 阶段的变更入口。项目已上线，需要修复问题或迭代功能时，通过此 skill 调研、澄清、更新文档。
|
||||
|
||||
当用户调用 `/iter` 或 `/iter <问题描述>` 时，执行以下步骤：
|
||||
⚠️ 重要：本 skill 只修改文档（PRD.md、tasks.md），绝不执行代码、不运行命令、不修改源文件。
|
||||
|
||||
## 1. 获取变更描述
|
||||
|
||||
如果用户提供了参数，使用该描述。否则询问：
|
||||
> 请描述需要迭代的内容（Bug/功能/重构）
|
||||
|
||||
**示例输入**：
|
||||
- "登录验证存在漏洞，token 过期后仍可访问"
|
||||
- "列表页需要增加按时间筛选功能"
|
||||
- "用户模块性能太差，需要重构缓存策略"
|
||||
|
||||
## 2. 调研分析
|
||||
|
||||
### 2.1 读取现有文档
|
||||
|
||||
读取以下文件了解当前状态：
|
||||
|
||||
1. `doc/PRD.md` - 了解产品定义
|
||||
2. `doc/tasks.md` - 了解任务现状
|
||||
|
||||
### 2.2 调研相关代码（可选）
|
||||
|
||||
根据问题描述，定位相关代码文件：
|
||||
|
||||
- 搜索关键词定位文件
|
||||
- 读取相关模块代码
|
||||
- 分析现有实现
|
||||
|
||||
### 2.3 分析变更类型
|
||||
|
||||
| 类型 | 特征 | 影响范围 |
|
||||
|------|------|----------|
|
||||
| Bug/漏洞 | 现有功能不符合预期 | 修复逻辑，可能涉及安全 |
|
||||
| 功能迭代 | 在现有功能上增加/调整 | 新增或修改功能点 |
|
||||
| 技术重构 | 不改功能，优化实现 | 性能、架构、代码质量 |
|
||||
|
||||
## 3. 澄清确认
|
||||
|
||||
**【必须】向用户提出澄清问题**，确保理解准确：
|
||||
|
||||
### 3.1 问题理解确认
|
||||
|
||||
向用户确认：
|
||||
> 我理解的变更需求是：{一句话总结}
|
||||
>
|
||||
> 变更类型：{Bug修复 / 功能迭代 / 技术重构}
|
||||
>
|
||||
> 影响范围：{涉及的模块/功能}
|
||||
|
||||
### 3.2 方案选择（如有多种）
|
||||
|
||||
如果有多种解决方案，列出选项让用户选择：
|
||||
|
||||
```
|
||||
方案 A：{描述}
|
||||
- 优点：...
|
||||
- 缺点：...
|
||||
|
||||
方案 B：{描述}
|
||||
- 优点：...
|
||||
- 缺点：...
|
||||
|
||||
请选择方案，或说明其他想法。
|
||||
```
|
||||
|
||||
### 3.3 边界确认
|
||||
|
||||
确认变更边界：
|
||||
> 本次变更**包含**：
|
||||
> - {范围1}
|
||||
> - {范围2}
|
||||
>
|
||||
> 本次变更**不包含**：
|
||||
> - {排除项}
|
||||
>
|
||||
> 是否确认？
|
||||
|
||||
## 4. 用户确认后执行
|
||||
|
||||
**只有用户明确确认后**，才执行以下更新：
|
||||
|
||||
### 4.1 更新 PRD.md
|
||||
|
||||
使用增量修改标记：
|
||||
|
||||
```markdown
|
||||
<!-- ITER: {日期} - {变更简述} -->
|
||||
<!-- NEW START -->
|
||||
新增内容...
|
||||
<!-- NEW END -->
|
||||
```
|
||||
|
||||
或修改现有内容：
|
||||
|
||||
```markdown
|
||||
<!-- ITER: {日期} - {变更简述} -->
|
||||
<!-- MODIFIED: 原内容为 "xxx" -->
|
||||
修改后的内容
|
||||
```
|
||||
|
||||
**更新位置**：
|
||||
- Bug 修复 → 更新对应功能的验收标准
|
||||
- 功能迭代 → 在 3.2 功能详情添加/修改功能点
|
||||
- 技术重构 → 在 4.x 非功能需求或 7.1 技术约束中说明
|
||||
|
||||
### 4.2 更新 tasks.md
|
||||
|
||||
新增任务使用标记：
|
||||
|
||||
```markdown
|
||||
<!-- ITER: {日期} - {变更简述} -->
|
||||
| T-xxx | {任务名} | {描述} | {依赖} | {优先级} | {验收标准} |
|
||||
```
|
||||
|
||||
**任务 ID 规则**：
|
||||
- 查找现有最大 ID，递增分配
|
||||
- 格式：T-xxx（三位数字）
|
||||
|
||||
### 4.3 标记规范
|
||||
|
||||
所有变更使用 `<!-- ITER: -->` 前缀，区分于 `/mp` `/mt` 的标记：
|
||||
|
||||
- `<!-- ITER: 2026-01-23 - 修复登录验证漏洞 -->`
|
||||
- 便于追溯迭代历史
|
||||
|
||||
## 5. 输出摘要
|
||||
|
||||
完成后向用户展示：
|
||||
|
||||
```
|
||||
## 迭代变更完成
|
||||
|
||||
**变更类型**: {Bug修复 / 功能迭代 / 技术重构}
|
||||
|
||||
**变更摘要**: {一句话描述}
|
||||
|
||||
**已更新文档**:
|
||||
- doc/PRD.md: {更新位置}
|
||||
- doc/tasks.md: 新增任务 T-xxx
|
||||
|
||||
**新增任务**:
|
||||
| ID | 任务 | 优先级 |
|
||||
|----|------|--------|
|
||||
| T-xxx | {任务名} | P0/P1/P2 |
|
||||
|
||||
**下一步**:
|
||||
- 执行任务 T-xxx
|
||||
- 或运行 `/rp` `/rt` 评审变更
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 工作流示意
|
||||
|
||||
```
|
||||
用户描述问题
|
||||
│
|
||||
▼
|
||||
┌─────────────┐
|
||||
│ 调研分析 │ ──▶ 读取 PRD、tasks、相关代码
|
||||
└──────┬──────┘
|
||||
│
|
||||
▼
|
||||
┌─────────────┐
|
||||
│ 澄清确认 │ ──▶ 提问 → 用户回答 → 确认方案
|
||||
└──────┬──────┘
|
||||
│
|
||||
▼ 用户确认
|
||||
┌─────────────┐
|
||||
│ 更新文档 │ ──▶ PRD.md + tasks.md
|
||||
└──────┬──────┘
|
||||
│
|
||||
▼
|
||||
┌─────────────┐
|
||||
│ 输出摘要 │
|
||||
└─────────────┘
|
||||
```
|
||||
|
||||
## 注意事项
|
||||
|
||||
- **必须先澄清确认**，不要假设用户意图
|
||||
- 变更范围要明确，避免 scope creep
|
||||
- 优先级根据问题严重程度判断：
|
||||
- 安全漏洞 → P0
|
||||
- 功能 Bug → P0/P1
|
||||
- 功能迭代 → P1/P2
|
||||
- 技术重构 → P1/P2
|
||||
- 只更新 PRD + tasks，保持轻量
|
||||
- 如需更新其他文档，提示用户手动运行 `/mf` `/md` 等
|
||||
|
||||
## 与其他 skill 的关系
|
||||
|
||||
| 场景 | 使用 skill |
|
||||
|------|------------|
|
||||
| 迭代变更入口 | `/iter`（本 skill） |
|
||||
| 需要更新 FeatureSummary | `/iter` 后运行 `/mf` |
|
||||
| 需要更新 DevelopmentPlan | `/iter` 后运行 `/md` |
|
||||
| 需要评审变更 | `/iter` 后运行 `/rp` `/rt` |
|
||||
| 从头生成文档 | 使用 `/wp` `/wf` `/wd` 等 |
|
||||
@@ -0,0 +1,112 @@
|
||||
---
|
||||
name: md
|
||||
description: 增量修改 DevelopmentPlan.md，根据用户指令在现有内容基础上更新开发计划。
|
||||
---
|
||||
|
||||
# Modify DevelopmentPlan
|
||||
|
||||
当用户调用 `/md` 时，执行以下步骤：
|
||||
|
||||
## 1. 读取目标文档
|
||||
|
||||
读取以下文件：
|
||||
|
||||
1. `doc/DevelopmentPlan.md` - 目标文档（必须存在）
|
||||
2. `doc/FeatureSummary.md` - 上游参考文档
|
||||
3. `doc/review-DevelopmentPlan-claude.md` - 评审报告（如果存在，自动作为修改依据）
|
||||
|
||||
如果 DevelopmentPlan.md 不存在，提示用户：
|
||||
> DevelopmentPlan.md 不存在，请先使用 `/wd` 生成开发计划。
|
||||
|
||||
## 2. 确定修改来源
|
||||
|
||||
按以下优先级确定修改内容：
|
||||
|
||||
### 2.1 用户提供了修改指令
|
||||
|
||||
如果用户在调用 `/md` 时附带了参数或说明，直接使用该指令。
|
||||
|
||||
### 2.2 自动检测评审报告
|
||||
|
||||
如果用户未提供修改指令，**自动检测** `doc/review-DevelopmentPlan-claude.md` 是否存在：
|
||||
|
||||
- **存在**：读取评审报告，提取其中的问题清单，作为本次修改的依据。向用户确认：
|
||||
> 检测到评审报告，包含 X 个问题。是否根据评审报告进行修改？
|
||||
|
||||
- **不存在**：询问用户：
|
||||
> 请说明需要修改的内容，或先运行 `/rd` 生成评审报告。
|
||||
|
||||
## 3. 修改原则
|
||||
|
||||
### 3.1 增量修改
|
||||
|
||||
- 保留原有内容结构和格式
|
||||
- 仅修改/新增指定部分
|
||||
- 不删除未明确要求删除的内容
|
||||
|
||||
### 3.2 新增内容标记
|
||||
|
||||
对于新增的段落或章节：
|
||||
|
||||
```markdown
|
||||
<!-- NEW START -->
|
||||
新增内容...
|
||||
<!-- NEW END -->
|
||||
```
|
||||
|
||||
对于行内新增：
|
||||
|
||||
```markdown
|
||||
原有内容 <!-- NEW --> 新增内容
|
||||
```
|
||||
|
||||
### 3.3 修改内容标记
|
||||
|
||||
```markdown
|
||||
<!-- MODIFIED: 原内容为 "xxx" -->
|
||||
修改后的内容
|
||||
```
|
||||
|
||||
### 3.4 与 FeatureSummary 一致性
|
||||
|
||||
- 开发任务必须覆盖所有功能
|
||||
- 技术方案必须支撑功能需求
|
||||
- 阶段划分必须合理
|
||||
|
||||
## 4. 执行修改
|
||||
|
||||
| 修改类型 | 处理方式 |
|
||||
|----------|----------|
|
||||
| 新增开发任务 | 在对应阶段表格中添加行 |
|
||||
| 修改技术方案 | 更新技术方案章节，添加 MODIFIED 标记 |
|
||||
| 调整阶段划分 | 移动任务到新阶段，标记变更 |
|
||||
| 新增风险项 | 在风险管理表格中添加行 |
|
||||
| 修改里程碑 | 更新里程碑表格 |
|
||||
|
||||
## 5. 保存并验证
|
||||
|
||||
1. 保存修改后的文档到 `doc/DevelopmentPlan.md`
|
||||
2. 使用 git diff 展示变更内容
|
||||
3. 向用户确认修改是否符合预期
|
||||
|
||||
## 6. 输出摘要
|
||||
|
||||
向用户展示修改摘要：
|
||||
|
||||
- 修改位置（章节/行号）
|
||||
- 修改类型（新增/修改/删除）
|
||||
- 修改内容概要
|
||||
- 与 FeatureSummary 的一致性确认
|
||||
|
||||
---
|
||||
|
||||
## 注意事项
|
||||
|
||||
- DevelopmentPlan 依赖于 FeatureSummary，修改时需确保与上游一致
|
||||
- 修改后，下游文档（UIDesign、tasks）可能需要同步更新
|
||||
- 技术方案修改需谨慎评估影响范围
|
||||
- 建议修改完成后运行 `/ru` 检查下游一致性
|
||||
|
||||
## 标记清理
|
||||
|
||||
用户确认修改无误后，可手动删除标记或保留作为变更历史参考。
|
||||
@@ -0,0 +1,111 @@
|
||||
---
|
||||
name: mf
|
||||
description: 增量修改 FeatureSummary.md，根据用户指令在现有内容基础上更新功能摘要。
|
||||
---
|
||||
|
||||
# Modify FeatureSummary
|
||||
|
||||
当用户调用 `/mf` 时，执行以下步骤：
|
||||
|
||||
## 1. 读取目标文档
|
||||
|
||||
读取以下文件：
|
||||
|
||||
1. `doc/FeatureSummary.md` - 目标文档（必须存在）
|
||||
2. `doc/PRD.md` - 上游参考文档
|
||||
3. `doc/review-FeatureSummary-claude.md` - 评审报告（如果存在，自动作为修改依据）
|
||||
|
||||
如果 FeatureSummary.md 不存在，提示用户：
|
||||
> FeatureSummary.md 不存在，请先使用 `/wf` 生成功能摘要。
|
||||
|
||||
## 2. 确定修改来源
|
||||
|
||||
按以下优先级确定修改内容：
|
||||
|
||||
### 2.1 用户提供了修改指令
|
||||
|
||||
如果用户在调用 `/mf` 时附带了参数或说明，直接使用该指令。
|
||||
|
||||
### 2.2 自动检测评审报告
|
||||
|
||||
如果用户未提供修改指令，**自动检测** `doc/review-FeatureSummary-claude.md` 是否存在：
|
||||
|
||||
- **存在**：读取评审报告，提取其中的问题清单，作为本次修改的依据。向用户确认：
|
||||
> 检测到评审报告，包含 X 个问题。是否根据评审报告进行修改？
|
||||
|
||||
- **不存在**：询问用户：
|
||||
> 请说明需要修改的内容，或先运行 `/rf` 生成评审报告。
|
||||
|
||||
## 3. 修改原则
|
||||
|
||||
### 3.1 增量修改
|
||||
|
||||
- 保留原有内容结构和格式
|
||||
- 仅修改/新增指定部分
|
||||
- 不删除未明确要求删除的内容
|
||||
|
||||
### 3.2 新增内容标记
|
||||
|
||||
对于新增的段落或章节：
|
||||
|
||||
```markdown
|
||||
<!-- NEW START -->
|
||||
新增内容...
|
||||
<!-- NEW END -->
|
||||
```
|
||||
|
||||
对于行内新增：
|
||||
|
||||
```markdown
|
||||
原有内容 <!-- NEW --> 新增内容
|
||||
```
|
||||
|
||||
### 3.3 修改内容标记
|
||||
|
||||
```markdown
|
||||
<!-- MODIFIED: 原内容为 "xxx" -->
|
||||
修改后的内容
|
||||
```
|
||||
|
||||
### 3.4 与 PRD 一致性
|
||||
|
||||
- 所有功能必须来源于 PRD
|
||||
- 修改后的功能描述必须与 PRD 一致
|
||||
- 优先级必须与 PRD 匹配
|
||||
|
||||
## 4. 执行修改
|
||||
|
||||
| 修改类型 | 处理方式 |
|
||||
|----------|----------|
|
||||
| 新增功能 | 在对应模块表格中添加行 |
|
||||
| 修改描述 | 更新功能描述，添加 MODIFIED 标记 |
|
||||
| 修改优先级 | 更新优先级列 |
|
||||
| 新增模块 | 在功能清单中添加新章节 |
|
||||
| 删除功能 | 标记为删除而非直接移除 |
|
||||
|
||||
## 5. 保存并验证
|
||||
|
||||
1. 保存修改后的文档到 `doc/FeatureSummary.md`
|
||||
2. 使用 git diff 展示变更内容
|
||||
3. 向用户确认修改是否符合预期
|
||||
|
||||
## 6. 输出摘要
|
||||
|
||||
向用户展示修改摘要：
|
||||
|
||||
- 修改位置（章节/行号）
|
||||
- 修改类型（新增/修改/删除）
|
||||
- 修改内容概要
|
||||
- 与 PRD 的一致性确认
|
||||
|
||||
---
|
||||
|
||||
## 注意事项
|
||||
|
||||
- FeatureSummary 依赖于 PRD，修改时需确保与上游一致
|
||||
- 修改后，下游文档（DevelopmentPlan 等）可能需要同步更新
|
||||
- 建议修改完成后运行 `/rd` 检查下游一致性
|
||||
|
||||
## 标记清理
|
||||
|
||||
用户确认修改无误后，可手动删除标记或保留作为变更历史参考。
|
||||
@@ -0,0 +1,144 @@
|
||||
---
|
||||
name: mp
|
||||
description: 增量修改 PRD.md，根据用户指令在现有内容基础上更新产品需求文档。
|
||||
---
|
||||
|
||||
# Modify PRD
|
||||
|
||||
当用户调用 `/mp` 时，执行以下步骤：
|
||||
|
||||
## 1. 读取目标文档
|
||||
|
||||
读取以下文件：
|
||||
|
||||
1. `doc/PRD.md` - 目标文档（必须存在）
|
||||
2. `doc/RequirementsDoc.md` - 上游参考文档
|
||||
3. `doc/review-PRD-claude.md` - 评审报告（如果存在，自动作为修改依据）
|
||||
|
||||
如果 PRD.md 不存在，提示用户：
|
||||
> PRD.md 不存在，请先使用 `/wp` 生成产品需求文档。
|
||||
|
||||
## 2. 确定修改来源
|
||||
|
||||
按以下优先级确定修改内容：
|
||||
|
||||
### 2.1 用户提供了修改指令
|
||||
|
||||
如果用户在调用 `/mp` 时附带了参数或说明，直接使用该指令。
|
||||
|
||||
### 2.2 自动检测评审报告
|
||||
|
||||
如果用户未提供修改指令，**自动检测** `doc/review-PRD-claude.md` 是否存在：
|
||||
|
||||
- **存在**：读取评审报告，提取其中的问题清单（Critical / Major / Minor），作为本次修改的依据。向用户确认：
|
||||
> 检测到评审报告 `doc/review-PRD-claude.md`，包含 X 个问题。是否根据评审报告进行修改？
|
||||
|
||||
- **不存在**：询问用户：
|
||||
> 请说明需要修改的内容，或先运行 `/rp` 生成评审报告。
|
||||
|
||||
### 2.3 支持的修改来源
|
||||
|
||||
- 具体的修改描述（如"在功能需求中增加用户权限管理模块"）
|
||||
- 评审报告（自动检测或手动指定路径）
|
||||
- 对应的 RequirementsDoc 变更（如"/mr 已更新需求，请同步 PRD"）
|
||||
|
||||
## 3. 修改原则
|
||||
|
||||
### 3.1 增量修改
|
||||
- 保留原有内容结构和格式
|
||||
- 仅修改/新增指定部分
|
||||
- 不删除未明确要求删除的内容
|
||||
|
||||
### 3.2 新增内容标记
|
||||
|
||||
对于新增的段落或章节，使用 HTML 注释标记：
|
||||
|
||||
```markdown
|
||||
<!-- NEW START -->
|
||||
新增内容...
|
||||
<!-- NEW END -->
|
||||
```
|
||||
|
||||
对于行内新增，使用：
|
||||
```markdown
|
||||
原有内容 <!-- NEW --> 新增内容
|
||||
```
|
||||
|
||||
### 3.3 修改内容标记
|
||||
|
||||
对于修改的内容，保留原文作为注释：
|
||||
|
||||
```markdown
|
||||
<!-- MODIFIED: 原内容为 "xxx" -->
|
||||
修改后的内容
|
||||
```
|
||||
|
||||
### 3.4 与 RequirementsDoc 一致性
|
||||
|
||||
- 所有 PRD 内容必须可追溯到 RequirementsDoc
|
||||
- 如果修改涉及新功能，先确认 RequirementsDoc 中已有对应需求
|
||||
- 如果 RequirementsDoc 未包含相关需求，提醒用户先更新需求文档
|
||||
|
||||
## 4. 执行修改
|
||||
|
||||
按照用户指令修改文档：
|
||||
|
||||
1. 定位到需要修改的位置
|
||||
2. 执行增量修改
|
||||
3. 添加相应的标记
|
||||
4. 保持文档格式一致性
|
||||
5. 确保修改内容与 RequirementsDoc 一致
|
||||
|
||||
### 4.1 修改类型处理
|
||||
|
||||
| 修改类型 | 处理方式 |
|
||||
|----------|----------|
|
||||
| 新增功能点 | 在对应功能模块表格中添加行，关联用户故事 |
|
||||
| 新增用户故事 | 在 2.2 用户故事列表中添加，分配 US-xxx ID |
|
||||
| 修改优先级 | 更新功能点优先级，必要时调整用户故事分类 |
|
||||
| 修改验收标准 | 更新对应功能点的验收标准列 |
|
||||
| 新增模块 | 在 3.2 功能详情中添加新的子章节 |
|
||||
| 修改非功能需求 | 在对应章节更新指标或要求 |
|
||||
|
||||
## 5. 保存并验证
|
||||
|
||||
1. 保存修改后的文档到 `doc/PRD.md`
|
||||
2. 使用 git diff 展示变更内容
|
||||
3. 向用户确认修改是否符合预期
|
||||
|
||||
## 6. 输出摘要
|
||||
|
||||
向用户展示修改摘要：
|
||||
- 修改位置（章节/行号）
|
||||
- 修改类型（新增/修改/删除）
|
||||
- 修改内容概要
|
||||
- 与 RequirementsDoc 的一致性确认
|
||||
|
||||
---
|
||||
|
||||
## 注意事项
|
||||
|
||||
- PRD 依赖于 RequirementsDoc，修改时需确保与上游文档一致
|
||||
- 修改 PRD 后，下游文档（FeatureSummary、DevelopmentPlan 等）可能需要同步更新
|
||||
- 保持现有文档风格（标题层级、表格格式、列表样式）
|
||||
- 用户故事 ID 必须唯一且连续（US-001, US-002...）
|
||||
- 所有功能点必须关联到用户故事
|
||||
- 重大修改建议先运行 `/rp` 评审确认影响范围
|
||||
- 修改完成后，建议用户运行 `/rf` 检查下游文档一致性
|
||||
|
||||
## 标记清理
|
||||
|
||||
当用户确认修改无误后，可手动删除 `<!-- NEW -->` 和 `<!-- MODIFIED -->` 标记，或保留作为变更历史参考。
|
||||
|
||||
通过 git 可追溯完整修改历史。
|
||||
|
||||
## 质量检查
|
||||
|
||||
修改 PRD 后，自查以下项目：
|
||||
|
||||
- [ ] 修改内容与 RequirementsDoc 一致
|
||||
- [ ] 新增用户故事有唯一 ID
|
||||
- [ ] 新增功能点关联到用户故事
|
||||
- [ ] 新增功能点有明确优先级和验收标准
|
||||
- [ ] 标记格式正确（`<!-- NEW -->` / `<!-- MODIFIED -->`）
|
||||
- [ ] 文档结构完整，格式一致
|
||||
@@ -0,0 +1,95 @@
|
||||
---
|
||||
name: mr
|
||||
description: 增量修改 RequirementsDoc.md，根据用户指令在现有内容基础上更新需求文档。
|
||||
---
|
||||
|
||||
# Modify RequirementsDoc
|
||||
|
||||
当用户调用 `/mr` 时，执行以下步骤：
|
||||
|
||||
## 1. 读取目标文档
|
||||
|
||||
读取 `doc/RequirementsDoc.md` 文件。
|
||||
|
||||
如果文件不存在，提示用户：
|
||||
> RequirementsDoc.md 不存在，请先使用人工方式创建需求文档。
|
||||
|
||||
## 2. 获取修改指令
|
||||
|
||||
向用户确认修改内容。用户应提供以下信息之一：
|
||||
|
||||
- 具体的修改描述（如"在第3节增加性能需求"）
|
||||
- 评审报告路径（如 `doc/review-RequirementsDoc-claude.md`）
|
||||
- 直接的修改内容
|
||||
|
||||
如果用户未提供修改指令，询问：
|
||||
> 请说明需要修改的内容，或提供评审报告路径。
|
||||
|
||||
## 3. 修改原则
|
||||
|
||||
### 3.1 增量修改
|
||||
- 保留原有内容结构和格式
|
||||
- 仅修改/新增指定部分
|
||||
- 不删除未明确要求删除的内容
|
||||
|
||||
### 3.2 新增内容标记
|
||||
|
||||
对于新增的段落或章节，使用 HTML 注释标记：
|
||||
|
||||
```markdown
|
||||
<!-- NEW START -->
|
||||
新增内容...
|
||||
<!-- NEW END -->
|
||||
```
|
||||
|
||||
对于行内新增，使用：
|
||||
```markdown
|
||||
原有内容 <!-- NEW --> 新增内容
|
||||
```
|
||||
|
||||
### 3.3 修改内容标记
|
||||
|
||||
对于修改的内容，保留原文作为注释：
|
||||
|
||||
```markdown
|
||||
<!-- MODIFIED: 原内容为 "xxx" -->
|
||||
修改后的内容
|
||||
```
|
||||
|
||||
## 4. 执行修改
|
||||
|
||||
按照用户指令修改文档：
|
||||
|
||||
1. 定位到需要修改的位置
|
||||
2. 执行增量修改
|
||||
3. 添加相应的标记
|
||||
4. 保持文档格式一致性
|
||||
|
||||
## 5. 保存并验证
|
||||
|
||||
1. 保存修改后的文档到 `doc/RequirementsDoc.md`
|
||||
2. 使用 git diff 展示变更内容
|
||||
3. 向用户确认修改是否符合预期
|
||||
|
||||
## 6. 输出摘要
|
||||
|
||||
向用户展示修改摘要：
|
||||
- 修改位置（章节/行号）
|
||||
- 修改类型（新增/修改/删除）
|
||||
- 修改内容概要
|
||||
|
||||
---
|
||||
|
||||
## 注意事项
|
||||
|
||||
- RequirementsDoc 是文档链源头，修改会影响所有下游文档
|
||||
- 修改前确认用户意图，避免误改
|
||||
- 保持现有文档风格（标题层级、表格格式、列表样式）
|
||||
- 重大修改建议先运行 `/rr` 评审确认影响范围
|
||||
- 修改完成后，建议用户检查下游文档是否需要同步更新
|
||||
|
||||
## 标记清理
|
||||
|
||||
当用户确认修改无误后，可手动删除 `<!-- NEW -->` 和 `<!-- MODIFIED -->` 标记，或保留作为变更历史参考。
|
||||
|
||||
通过 git 可追溯完整修改历史。
|
||||
@@ -0,0 +1,132 @@
|
||||
---
|
||||
name: mt
|
||||
description: 增量修改 tasks.md，根据用户指令在现有内容基础上更新任务列表。
|
||||
---
|
||||
|
||||
# Modify Tasks
|
||||
|
||||
当用户调用 `/mt` 时，执行以下步骤：
|
||||
|
||||
## 1. 读取目标文档
|
||||
|
||||
读取以下文件：
|
||||
|
||||
1. `doc/tasks.md` - 目标文档（必须存在）
|
||||
2. `doc/UIDesign.md` - 上游参考文档
|
||||
3. `doc/DevelopmentPlan.md` - 上游参考文档
|
||||
4. `doc/review-tasks-claude.md` - 评审报告（如果存在，自动作为修改依据）
|
||||
|
||||
如果 tasks.md 不存在，提示用户：
|
||||
> tasks.md 不存在，请先使用 `/wt` 生成任务列表。
|
||||
|
||||
## 2. 确定修改来源
|
||||
|
||||
按以下优先级确定修改内容：
|
||||
|
||||
### 2.1 用户提供了修改指令
|
||||
|
||||
如果用户在调用 `/mt` 时附带了参数或说明，直接使用该指令。
|
||||
|
||||
### 2.2 自动检测评审报告
|
||||
|
||||
如果用户未提供修改指令，**自动检测** `doc/review-tasks-claude.md` 是否存在：
|
||||
|
||||
- **存在**：读取评审报告，提取其中的问题清单，作为本次修改的依据。向用户确认：
|
||||
> 检测到评审报告，包含 X 个问题。是否根据评审报告进行修改？
|
||||
|
||||
- **不存在**：询问用户：
|
||||
> 请说明需要修改的内容，或先运行 `/rt` 生成评审报告。
|
||||
|
||||
## 3. 修改原则
|
||||
|
||||
### 3.1 增量修改
|
||||
|
||||
- 保留原有内容结构和格式
|
||||
- 仅修改/新增指定部分
|
||||
- 不删除未明确要求删除的内容
|
||||
|
||||
### 3.2 新增内容标记
|
||||
|
||||
对于新增的段落或章节：
|
||||
|
||||
```markdown
|
||||
<!-- NEW START -->
|
||||
新增内容...
|
||||
<!-- NEW END -->
|
||||
```
|
||||
|
||||
对于行内新增：
|
||||
|
||||
```markdown
|
||||
原有内容 <!-- NEW --> 新增内容
|
||||
```
|
||||
|
||||
### 3.3 修改内容标记
|
||||
|
||||
```markdown
|
||||
<!-- MODIFIED: 原内容为 "xxx" -->
|
||||
修改后的内容
|
||||
```
|
||||
|
||||
### 3.4 与上游文档一致性
|
||||
|
||||
- 任务必须覆盖 DevelopmentPlan 所有开发项
|
||||
- 任务必须覆盖 UIDesign 所有页面实现
|
||||
- 任务依赖关系必须合理
|
||||
|
||||
## 4. 执行修改
|
||||
|
||||
| 修改类型 | 处理方式 |
|
||||
|----------|----------|
|
||||
| 新增任务 | 在对应阶段表格中添加行，分配新 ID |
|
||||
| 修改描述 | 更新任务描述，添加 MODIFIED 标记 |
|
||||
| 修改优先级 | 更新优先级列 |
|
||||
| 修改依赖 | 更新依赖列，检查循环依赖 |
|
||||
| 修改验收标准 | 更新验收标准列 |
|
||||
| 调整阶段 | 移动任务到新阶段，更新依赖图 |
|
||||
|
||||
### 4.1 任务 ID 规则
|
||||
|
||||
- 新增任务 ID 必须唯一
|
||||
- ID 格式：T-XXX（三位数字，如 T-001）
|
||||
- 在现有最大 ID 基础上递增
|
||||
|
||||
## 5. 保存并验证
|
||||
|
||||
1. 保存修改后的文档到 `doc/tasks.md`
|
||||
2. 使用 git diff 展示变更内容
|
||||
3. 向用户确认修改是否符合预期
|
||||
|
||||
## 6. 输出摘要
|
||||
|
||||
向用户展示修改摘要：
|
||||
|
||||
- 修改位置（章节/行号）
|
||||
- 修改类型（新增/修改/删除）
|
||||
- 修改内容概要
|
||||
- 新增/修改的任务 ID 列表
|
||||
- 与上游文档的一致性确认
|
||||
|
||||
---
|
||||
|
||||
## 注意事项
|
||||
|
||||
- tasks.md 是文档链末端，修改不影响其他文档
|
||||
- 任务 ID 必须唯一，不可重复使用已删除的 ID
|
||||
- 修改依赖关系时需检查是否产生循环依赖
|
||||
- 验收标准必须具体可测试
|
||||
- 任务粒度要适中
|
||||
|
||||
## 标记清理
|
||||
|
||||
用户确认修改无误后，可手动删除标记或保留作为变更历史参考。
|
||||
|
||||
## 质量检查
|
||||
|
||||
修改 tasks 后，自查以下项目：
|
||||
|
||||
- [ ] 任务 ID 唯一且格式正确
|
||||
- [ ] 无循环依赖
|
||||
- [ ] 验收标准明确
|
||||
- [ ] 覆盖所有上游功能
|
||||
- [ ] 标记格式正确
|
||||
@@ -0,0 +1,114 @@
|
||||
---
|
||||
name: mu
|
||||
description: 增量修改 UIDesign.md，根据用户指令在现有内容基础上更新 UI 设计文档。
|
||||
---
|
||||
|
||||
# Modify UIDesign
|
||||
|
||||
当用户调用 `/mu` 时，执行以下步骤：
|
||||
|
||||
## 1. 读取目标文档
|
||||
|
||||
读取以下文件：
|
||||
|
||||
1. `doc/UIDesign.md` - 目标文档（必须存在）
|
||||
2. `doc/DevelopmentPlan.md` - 上游参考文档
|
||||
3. `doc/review-UIDesign-claude.md` - 评审报告（如果存在，自动作为修改依据）
|
||||
|
||||
如果 UIDesign.md 不存在，提示用户：
|
||||
> UIDesign.md 不存在，请先使用 `/wu` 生成 UI 设计文档。
|
||||
|
||||
## 2. 确定修改来源
|
||||
|
||||
按以下优先级确定修改内容：
|
||||
|
||||
### 2.1 用户提供了修改指令
|
||||
|
||||
如果用户在调用 `/mu` 时附带了参数或说明，直接使用该指令。
|
||||
|
||||
### 2.2 自动检测评审报告
|
||||
|
||||
如果用户未提供修改指令，**自动检测** `doc/review-UIDesign-claude.md` 是否存在：
|
||||
|
||||
- **存在**：读取评审报告，提取其中的问题清单，作为本次修改的依据。向用户确认：
|
||||
> 检测到评审报告，包含 X 个问题。是否根据评审报告进行修改？
|
||||
|
||||
- **不存在**：询问用户：
|
||||
> 请说明需要修改的内容，或先运行 `/ru` 生成评审报告。
|
||||
|
||||
## 3. 修改原则
|
||||
|
||||
### 3.1 增量修改
|
||||
|
||||
- 保留原有内容结构和格式
|
||||
- 仅修改/新增指定部分
|
||||
- 不删除未明确要求删除的内容
|
||||
|
||||
### 3.2 新增内容标记
|
||||
|
||||
对于新增的段落或章节：
|
||||
|
||||
```markdown
|
||||
<!-- NEW START -->
|
||||
新增内容...
|
||||
<!-- NEW END -->
|
||||
```
|
||||
|
||||
对于行内新增：
|
||||
|
||||
```markdown
|
||||
原有内容 <!-- NEW --> 新增内容
|
||||
```
|
||||
|
||||
### 3.3 修改内容标记
|
||||
|
||||
```markdown
|
||||
<!-- MODIFIED: 原内容为 "xxx" -->
|
||||
修改后的内容
|
||||
```
|
||||
|
||||
### 3.4 与 DevelopmentPlan 一致性
|
||||
|
||||
- 页面设计必须覆盖所有功能模块
|
||||
- 交互流程必须支撑功能需求
|
||||
- 设计规范必须统一
|
||||
|
||||
## 4. 执行修改
|
||||
|
||||
| 修改类型 | 处理方式 |
|
||||
|----------|----------|
|
||||
| 新增页面 | 在页面设计章节添加新子章节 |
|
||||
| 修改布局 | 更新布局描述，添加 MODIFIED 标记 |
|
||||
| 修改组件 | 更新组件表格 |
|
||||
| 修改交互 | 更新交互说明 |
|
||||
| 新增状态 | 在状态列表中添加项目 |
|
||||
| 修改设计规范 | 更新设计规范章节 |
|
||||
|
||||
## 5. 保存并验证
|
||||
|
||||
1. 保存修改后的文档到 `doc/UIDesign.md`
|
||||
2. 使用 git diff 展示变更内容
|
||||
3. 向用户确认修改是否符合预期
|
||||
|
||||
## 6. 输出摘要
|
||||
|
||||
向用户展示修改摘要：
|
||||
|
||||
- 修改位置（章节/行号）
|
||||
- 修改类型（新增/修改/删除）
|
||||
- 修改内容概要
|
||||
- 与 DevelopmentPlan 的一致性确认
|
||||
|
||||
---
|
||||
|
||||
## 注意事项
|
||||
|
||||
- UIDesign 依赖于 DevelopmentPlan，修改时需确保与上游一致
|
||||
- 修改后，下游文档（tasks）可能需要同步更新
|
||||
- 页面修改需考虑对用户流程的影响
|
||||
- 设计规范修改需检查所有页面的一致性
|
||||
- 建议修改完成后运行 `/rt` 检查下游一致性
|
||||
|
||||
## 标记清理
|
||||
|
||||
用户确认修改无误后，可手动删除标记或保留作为变更历史参考。
|
||||
@@ -0,0 +1,101 @@
|
||||
---
|
||||
name: rd
|
||||
description: 评审 DevelopmentPlan.md，检查技术可行性和与上游文档一致性，输出结构化评审报告。
|
||||
---
|
||||
|
||||
# Review DevelopmentPlan
|
||||
|
||||
当用户调用 `/rd` 时，执行以下步骤：
|
||||
|
||||
## 1. 读取文档
|
||||
|
||||
读取以下文件：
|
||||
|
||||
1. `doc/DevelopmentPlan.md` - 目标文档（必须存在）
|
||||
2. `doc/FeatureSummary.md` - 上游参照文档
|
||||
|
||||
如果 DevelopmentPlan.md 不存在，提示用户：
|
||||
> DevelopmentPlan.md 不存在，请先使用 `/wd` 生成开发计划。
|
||||
|
||||
## 2. 评审维度
|
||||
|
||||
### 2.1 与 FeatureSummary 一致性检查
|
||||
|
||||
- 开发任务是否覆盖所有功能模块
|
||||
- 技术方案是否支撑功能需求
|
||||
- 排期是否合理
|
||||
|
||||
### 2.2 技术可行性检查
|
||||
|
||||
- 技术方案是否可行
|
||||
- 技术栈选择是否合理
|
||||
- 是否存在技术风险
|
||||
- 依赖关系是否明确
|
||||
|
||||
### 2.3 完整性检查
|
||||
|
||||
- 是否有明确的里程碑划分
|
||||
- 是否有资源分配说明
|
||||
- 是否有风险应对措施
|
||||
|
||||
## 3. 生成评审报告
|
||||
|
||||
输出到 `doc/review-DevelopmentPlan-claude.md`，结构如下：
|
||||
|
||||
```markdown
|
||||
# DevelopmentPlan 评审报告
|
||||
|
||||
## 概要
|
||||
|
||||
| 项目 | 内容 |
|
||||
|------|------|
|
||||
| 评审时间 | {YYYY-MM-DD HH:MM} |
|
||||
| 目标文档 | doc/DevelopmentPlan.md |
|
||||
| 参照文档 | doc/FeatureSummary.md |
|
||||
| 问题统计 | X 个严重 / Y 个一般 / Z 个建议 |
|
||||
|
||||
## 功能覆盖分析
|
||||
|
||||
| FeatureSummary 功能 | DevelopmentPlan 对应 | 状态 |
|
||||
|---------------------|----------------------|------|
|
||||
| {功能名} | {对应任务/模块} | ✅/⚠️/❌ |
|
||||
|
||||
## 技术风险分析
|
||||
|
||||
| 风险项 | 影响范围 | 严重程度 | 建议措施 |
|
||||
|--------|----------|----------|----------|
|
||||
| {风险} | {范围} | 高/中/低 | {措施} |
|
||||
|
||||
## 问题清单
|
||||
|
||||
### 严重问题 (Critical)
|
||||
{问题列表，含位置引用}
|
||||
|
||||
### 一般问题 (Major)
|
||||
{问题列表，含位置引用}
|
||||
|
||||
### 改进建议 (Minor)
|
||||
{建议列表}
|
||||
|
||||
## 评审结论
|
||||
|
||||
{通过 / 需修改后通过 / 不通过}
|
||||
|
||||
### 下一步行动
|
||||
- [ ] {待办事项}
|
||||
```
|
||||
|
||||
## 4. 输出规范
|
||||
|
||||
- 输出语言：中文
|
||||
- 问题分级：Critical / Major / Minor
|
||||
- 包含文件引用（如 `doc/DevelopmentPlan.md:28`）
|
||||
- 技术风险需明确影响范围和应对建议
|
||||
|
||||
---
|
||||
|
||||
## 注意事项
|
||||
|
||||
- 只做评审，不修改原文档
|
||||
- 重点关注技术可行性和风险
|
||||
- 评审报告保存后，建议用户根据问题运行 `/md` 修改
|
||||
@@ -0,0 +1,96 @@
|
||||
---
|
||||
name: rf
|
||||
description: 评审 FeatureSummary.md，对比 PRD 检查一致性，输出结构化评审报告。
|
||||
---
|
||||
|
||||
# Review FeatureSummary
|
||||
|
||||
当用户调用 `/rf` 时，执行以下步骤：
|
||||
|
||||
## 1. 读取文档
|
||||
|
||||
读取以下文件：
|
||||
|
||||
1. `doc/FeatureSummary.md` - 目标文档（必须存在）
|
||||
2. `doc/PRD.md` - 上游参照文档
|
||||
|
||||
如果 FeatureSummary.md 不存在，提示用户：
|
||||
> FeatureSummary.md 不存在，请先使用 `/wf` 生成功能摘要。
|
||||
|
||||
## 2. 评审维度
|
||||
|
||||
### 2.1 与 PRD 一致性检查
|
||||
|
||||
- 功能模块是否完整覆盖 PRD 3.2 功能详情
|
||||
- 功能描述是否与 PRD 一致
|
||||
- 优先级标注是否与 PRD 匹配
|
||||
|
||||
### 2.2 完整性检查
|
||||
|
||||
- 每个功能模块是否有清晰的描述
|
||||
- 是否遗漏 PRD 中的功能点
|
||||
- 功能分类是否合理
|
||||
|
||||
### 2.3 质量检查
|
||||
|
||||
- 描述是否简洁准确
|
||||
- 是否有冗余或重复内容
|
||||
- 格式是否规范统一
|
||||
|
||||
## 3. 生成评审报告
|
||||
|
||||
输出到 `doc/review-FeatureSummary-claude.md`，结构如下：
|
||||
|
||||
```markdown
|
||||
# FeatureSummary 评审报告
|
||||
|
||||
## 概要
|
||||
|
||||
| 项目 | 内容 |
|
||||
|------|------|
|
||||
| 评审时间 | {YYYY-MM-DD HH:MM} |
|
||||
| 目标文档 | doc/FeatureSummary.md |
|
||||
| 参照文档 | doc/PRD.md |
|
||||
| 问题统计 | X 个严重 / Y 个一般 / Z 个建议 |
|
||||
|
||||
## 覆盖度分析
|
||||
|
||||
| PRD 功能模块 | FeatureSummary 对应 | 状态 |
|
||||
|--------------|---------------------|------|
|
||||
| {模块名} | {对应位置} | ✅/⚠️/❌ |
|
||||
|
||||
**覆盖率**: X/Y 完全覆盖
|
||||
|
||||
## 问题清单
|
||||
|
||||
### 严重问题 (Critical)
|
||||
{问题列表，含位置引用}
|
||||
|
||||
### 一般问题 (Major)
|
||||
{问题列表，含位置引用}
|
||||
|
||||
### 改进建议 (Minor)
|
||||
{建议列表}
|
||||
|
||||
## 评审结论
|
||||
|
||||
{通过 / 需修改后通过 / 不通过}
|
||||
|
||||
### 下一步行动
|
||||
- [ ] {待办事项}
|
||||
```
|
||||
|
||||
## 4. 输出规范
|
||||
|
||||
- 输出语言：中文
|
||||
- 问题分级：Critical / Major / Minor
|
||||
- 包含文件引用（如 `doc/FeatureSummary.md:15`）
|
||||
- 问题按严重性排序
|
||||
|
||||
---
|
||||
|
||||
## 注意事项
|
||||
|
||||
- 只做评审，不修改原文档
|
||||
- 重点检查与 PRD 的一致性
|
||||
- 评审报告保存后，建议用户根据问题运行 `/mf` 修改
|
||||
@@ -0,0 +1,177 @@
|
||||
---
|
||||
name: rp
|
||||
description: 评审 PRD.md，对比 RequirementsDoc 检查一致性，输出结构化评审报告。
|
||||
---
|
||||
|
||||
# Review PRD
|
||||
|
||||
当用户调用 `/rp` 时，执行以下步骤：
|
||||
|
||||
## 1. 读取文档
|
||||
|
||||
读取以下文件：
|
||||
- 目标文档：`doc/PRD.md`
|
||||
- 上游文档：`doc/RequirementsDoc.md`
|
||||
|
||||
如果 PRD.md 不存在，提示用户：
|
||||
> PRD.md 不存在，请先使用 `/wp` 生成 PRD。
|
||||
|
||||
如果 RequirementsDoc.md 不存在，提示用户：
|
||||
> RequirementsDoc.md 不存在，无法进行一致性检查。请先创建需求文档。
|
||||
|
||||
## 2. 评审维度
|
||||
|
||||
PRD 位于文档链的第二层，需要对比上游 RequirementsDoc 进行评审。
|
||||
|
||||
### 2.1 与 RequirementsDoc 的一致性
|
||||
|
||||
- [ ] PRD 是否覆盖了 RequirementsDoc 中的所有功能需求
|
||||
- [ ] PRD 是否覆盖了 RequirementsDoc 中的所有非功能需求
|
||||
- [ ] PRD 中是否有 RequirementsDoc 中未提及的需求（需标注来源）
|
||||
- [ ] 术语定义是否与 RequirementsDoc 一致
|
||||
- [ ] 优先级划分是否与 RequirementsDoc 一致
|
||||
|
||||
### 2.2 用户故事质量
|
||||
|
||||
- [ ] 所有用户故事是否有唯一 ID（US-xxx）
|
||||
- [ ] 用户故事是否符合格式：作为{角色}，我想要{功能}，以便{价值}
|
||||
- [ ] 用户角色是否明确定义
|
||||
- [ ] 验收标准是否具体可测试
|
||||
- [ ] 用户旅程是否完整描述核心流程
|
||||
|
||||
### 2.3 功能需求完整性
|
||||
|
||||
- [ ] 功能架构是否清晰（模块划分合理）
|
||||
- [ ] 所有功能点是否关联到用户故事
|
||||
- [ ] 功能点是否有明确的优先级
|
||||
- [ ] 功能点是否有验收标准
|
||||
- [ ] 是否遗漏边界情况和异常处理
|
||||
|
||||
### 2.4 非功能需求
|
||||
|
||||
- [ ] 性能需求是否有量化指标
|
||||
- [ ] 安全需求是否明确
|
||||
- [ ] 兼容性需求是否完整
|
||||
- [ ] 可用性需求是否可验证
|
||||
|
||||
### 2.5 文档结构
|
||||
|
||||
- [ ] 文档结构是否完整（无空章节）
|
||||
- [ ] 格式是否统一（表格、列表、标题层级）
|
||||
- [ ] 术语表是否完整
|
||||
|
||||
## 3. 生成评审报告
|
||||
|
||||
按以下格式输出评审报告：
|
||||
|
||||
```markdown
|
||||
# PRD 评审报告
|
||||
|
||||
## 概要
|
||||
|
||||
| 项目 | 内容 |
|
||||
|------|------|
|
||||
| 评审时间 | {YYYY-MM-DD HH:mm} |
|
||||
| 目标文档 | doc/PRD.md |
|
||||
| 参照文档 | doc/RequirementsDoc.md |
|
||||
| 问题统计 | {critical} 个严重 / {major} 个一般 / {minor} 个建议 |
|
||||
|
||||
## 一致性检查
|
||||
|
||||
### 需求覆盖分析
|
||||
|
||||
| RequirementsDoc 需求项 | PRD 对应位置 | 状态 |
|
||||
|------------------------|--------------|------|
|
||||
| {需求1} | {PRD章节/用户故事ID} | ✅ 已覆盖 / ⚠️ 部分覆盖 / ❌ 未覆盖 |
|
||||
|
||||
### 差异说明
|
||||
|
||||
{列出 PRD 中新增的、RequirementsDoc 未提及的内容，需说明来源或理由}
|
||||
|
||||
## 问题清单
|
||||
|
||||
### 严重问题 (Critical)
|
||||
|
||||
> 必须修复，否则影响后续文档生成
|
||||
|
||||
1. **[位置: doc/PRD.md:行号]** 问题描述
|
||||
- 现状：...
|
||||
- 与 RequirementsDoc 的差异：...
|
||||
- 建议：...
|
||||
|
||||
### 一般问题 (Major)
|
||||
|
||||
> 建议修复，可提升文档质量
|
||||
|
||||
1. **[位置]** 问题描述
|
||||
- 建议：...
|
||||
|
||||
### 改进建议 (Minor)
|
||||
|
||||
> 可选优化项
|
||||
|
||||
1. **[位置]** 建议内容
|
||||
|
||||
## 用户故事评估
|
||||
|
||||
| 评估项 | 结果 |
|
||||
|--------|------|
|
||||
| 用户故事总数 | {数量} |
|
||||
| 符合格式规范 | {数量} / {总数} |
|
||||
| 有验收标准 | {数量} / {总数} |
|
||||
| 关联功能点 | {数量} / {总数} |
|
||||
|
||||
### 用户故事问题
|
||||
|
||||
{列出不符合规范的用户故事}
|
||||
|
||||
## 评审结论
|
||||
|
||||
{通过 / 需修改后通过 / 不通过}
|
||||
|
||||
**结论说明**：
|
||||
- 通过：PRD 与 RequirementsDoc 一致，可进入下一阶段
|
||||
- 需修改后通过：存在问题但不影响整体理解，修复后可继续
|
||||
- 不通过：存在严重一致性问题或遗漏，需重新生成
|
||||
|
||||
### 下一步行动
|
||||
|
||||
- [ ] 行动项1
|
||||
- [ ] 行动项2
|
||||
```
|
||||
|
||||
## 4. 保存报告
|
||||
|
||||
将评审报告保存到 `doc/review-PRD-claude.md`。
|
||||
|
||||
如果文件已存在，覆盖原文件（历史版本通过 git 追溯）。
|
||||
|
||||
## 5. 输出摘要
|
||||
|
||||
向用户展示评审摘要：
|
||||
- 一致性检查结果（覆盖率）
|
||||
- 发现的问题数量（按严重程度分类）
|
||||
- 用户故事评估结果
|
||||
- 评审结论
|
||||
- 报告文件路径
|
||||
|
||||
---
|
||||
|
||||
## 注意事项
|
||||
|
||||
- 评审时保持客观，聚焦于文档质量和一致性
|
||||
- 问题描述要具体，给出明确的位置引用（如 `doc/PRD.md:42`）
|
||||
- 一致性检查要逐项对比，不能遗漏
|
||||
- 建议要可操作，避免模糊表述
|
||||
- 不要修改原文档，只输出评审报告
|
||||
|
||||
## 常见问题模式
|
||||
|
||||
在评审时重点关注以下常见问题：
|
||||
|
||||
1. **需求遗漏**：RequirementsDoc 中有但 PRD 中没有的需求
|
||||
2. **需求偏离**：PRD 中的描述与 RequirementsDoc 不一致
|
||||
3. **凭空添加**：PRD 中有但 RequirementsDoc 中没有的需求（需要来源说明）
|
||||
4. **用户故事缺陷**：格式不规范、缺少验收标准、角色不明确
|
||||
5. **功能孤立**：功能点未关联到任何用户故事
|
||||
6. **优先级冲突**：PRD 与 RequirementsDoc 的优先级划分不一致
|
||||
@@ -0,0 +1,111 @@
|
||||
---
|
||||
name: rr
|
||||
description: 评审 RequirementsDoc.md，检查需求文档的完整性、清晰度和可执行性，输出结构化评审报告。
|
||||
---
|
||||
|
||||
# Review RequirementsDoc
|
||||
|
||||
当用户调用 `/rr` 时，执行以下步骤：
|
||||
|
||||
## 1. 读取目标文档
|
||||
|
||||
读取 `doc/RequirementsDoc.md` 文件。
|
||||
|
||||
如果文件不存在，提示用户：
|
||||
> RequirementsDoc.md 不存在，请先创建需求文档。
|
||||
|
||||
## 2. 评审维度
|
||||
|
||||
RequirementsDoc 是文档链的源头，没有上游依赖。重点检查以下维度：
|
||||
|
||||
### 2.1 完整性
|
||||
- [ ] 产品概述是否清晰（定位、目标用户、核心价值）
|
||||
- [ ] 功能需求是否完整列出
|
||||
- [ ] 非功能需求是否涵盖（性能、安全、兼容性）
|
||||
- [ ] 数据规范是否明确（输入输出格式、字段定义）
|
||||
- [ ] 边界条件和异常情况是否考虑
|
||||
|
||||
### 2.2 清晰度
|
||||
- [ ] 术语定义是否一致，无歧义
|
||||
- [ ] 用例描述是否具体可理解
|
||||
- [ ] 优先级是否明确标注
|
||||
- [ ] 是否有模糊表述（"等"、"可能"、"应该"等）
|
||||
|
||||
### 2.3 可执行性
|
||||
- [ ] 需求是否可被验证（有明确的验收标准）
|
||||
- [ ] 技术约束是否合理
|
||||
- [ ] 依赖项是否明确
|
||||
|
||||
### 2.4 结构规范
|
||||
- [ ] 文档结构是否清晰（章节划分合理）
|
||||
- [ ] 格式是否统一（表格、列表、标题层级）
|
||||
|
||||
## 3. 生成评审报告
|
||||
|
||||
按以下格式输出评审报告：
|
||||
|
||||
```markdown
|
||||
# RequirementsDoc 评审报告
|
||||
|
||||
## 概要
|
||||
|
||||
| 项目 | 内容 |
|
||||
|------|------|
|
||||
| 评审时间 | {YYYY-MM-DD HH:mm} |
|
||||
| 目标文档 | doc/RequirementsDoc.md |
|
||||
| 问题统计 | {critical} 个严重 / {major} 个一般 / {minor} 个建议 |
|
||||
|
||||
## 问题清单
|
||||
|
||||
### 严重问题 (Critical)
|
||||
|
||||
> 必须修复，否则影响后续文档生成
|
||||
|
||||
1. **[位置: 第X节/第Y行]** 问题描述
|
||||
- 现状：...
|
||||
- 建议：...
|
||||
|
||||
### 一般问题 (Major)
|
||||
|
||||
> 建议修复，可提升文档质量
|
||||
|
||||
1. **[位置]** 问题描述
|
||||
- 建议：...
|
||||
|
||||
### 改进建议 (Minor)
|
||||
|
||||
> 可选优化项
|
||||
|
||||
1. **[位置]** 建议内容
|
||||
|
||||
## 评审结论
|
||||
|
||||
{通过 / 需修改后通过 / 不通过}
|
||||
|
||||
### 下一步行动
|
||||
|
||||
- [ ] 行动项1
|
||||
- [ ] 行动项2
|
||||
```
|
||||
|
||||
## 4. 保存报告
|
||||
|
||||
将评审报告保存到 `doc/review-RequirementsDoc-claude.md`。
|
||||
|
||||
如果文件已存在，覆盖原文件（历史版本通过 git 追溯）。
|
||||
|
||||
## 5. 输出摘要
|
||||
|
||||
向用户展示评审摘要：
|
||||
- 发现的问题数量（按严重程度分类）
|
||||
- 评审结论
|
||||
- 报告文件路径
|
||||
|
||||
---
|
||||
|
||||
## 注意事项
|
||||
|
||||
- 评审时保持客观，聚焦于文档质量而非业务判断
|
||||
- 问题描述要具体，给出明确的位置引用
|
||||
- 建议要可操作，避免模糊表述
|
||||
- 不要修改原文档，只输出评审报告
|
||||
@@ -0,0 +1,115 @@
|
||||
---
|
||||
name: rt
|
||||
description: 评审 tasks.md，检查任务完整性和与上游文档一致性，输出结构化评审报告。
|
||||
---
|
||||
|
||||
# Review Tasks
|
||||
|
||||
当用户调用 `/rt` 时，执行以下步骤：
|
||||
|
||||
## 1. 读取文档
|
||||
|
||||
读取以下文件：
|
||||
|
||||
1. `doc/tasks.md` - 目标文档（必须存在）
|
||||
2. `doc/UIDesign.md` - 上游参照文档
|
||||
3. `doc/DevelopmentPlan.md` - 上游参照文档
|
||||
|
||||
如果 tasks.md 不存在，提示用户：
|
||||
> tasks.md 不存在，请先使用 `/wt` 生成任务列表。
|
||||
|
||||
## 2. 评审维度
|
||||
|
||||
### 2.1 与上游文档一致性检查
|
||||
|
||||
- 任务是否覆盖 DevelopmentPlan 所有开发项
|
||||
- 任务是否覆盖 UIDesign 所有页面实现
|
||||
- 任务优先级是否与功能优先级匹配
|
||||
|
||||
### 2.2 任务完整性检查
|
||||
|
||||
- 每个任务是否有明确的描述
|
||||
- 任务粒度是否合适（不过大也不过小）
|
||||
- 任务依赖关系是否明确
|
||||
- 验收标准是否清晰
|
||||
|
||||
### 2.3 可执行性检查
|
||||
|
||||
- 任务是否可直接开始执行
|
||||
- 是否有阻塞项未说明
|
||||
- 估时是否合理（如有）
|
||||
|
||||
## 3. 生成评审报告
|
||||
|
||||
输出到 `doc/review-tasks-claude.md`，结构如下：
|
||||
|
||||
```markdown
|
||||
# Tasks 评审报告
|
||||
|
||||
## 概要
|
||||
|
||||
| 项目 | 内容 |
|
||||
|------|------|
|
||||
| 评审时间 | {YYYY-MM-DD HH:MM} |
|
||||
| 目标文档 | doc/tasks.md |
|
||||
| 参照文档 | doc/UIDesign.md, doc/DevelopmentPlan.md |
|
||||
| 问题统计 | X 个严重 / Y 个一般 / Z 个建议 |
|
||||
|
||||
## 覆盖度分析
|
||||
|
||||
### DevelopmentPlan 覆盖
|
||||
|
||||
| 开发项 | 对应任务 | 状态 |
|
||||
|--------|----------|------|
|
||||
| {开发项} | {任务ID/名称} | ✅/⚠️/❌ |
|
||||
|
||||
### UIDesign 覆盖
|
||||
|
||||
| UI 页面 | 对应任务 | 状态 |
|
||||
|---------|----------|------|
|
||||
| {页面名} | {任务ID/名称} | ✅/⚠️/❌ |
|
||||
|
||||
**总覆盖率**: X/Y
|
||||
|
||||
## 任务质量分析
|
||||
|
||||
| 检查项 | 通过数 | 总数 |
|
||||
|--------|--------|------|
|
||||
| 有明确描述 | X | Y |
|
||||
| 有验收标准 | X | Y |
|
||||
| 粒度合适 | X | Y |
|
||||
|
||||
## 问题清单
|
||||
|
||||
### 严重问题 (Critical)
|
||||
{问题列表，含位置引用}
|
||||
|
||||
### 一般问题 (Major)
|
||||
{问题列表，含位置引用}
|
||||
|
||||
### 改进建议 (Minor)
|
||||
{建议列表}
|
||||
|
||||
## 评审结论
|
||||
|
||||
{通过 / 需修改后通过 / 不通过}
|
||||
|
||||
### 下一步行动
|
||||
- [ ] {待办事项}
|
||||
```
|
||||
|
||||
## 4. 输出规范
|
||||
|
||||
- 输出语言：中文
|
||||
- 问题分级：Critical / Major / Minor
|
||||
- 包含文件引用（如 `doc/tasks.md:12`）
|
||||
- 任务问题需说明对开发执行的影响
|
||||
|
||||
---
|
||||
|
||||
## 注意事项
|
||||
|
||||
- 只做评审，不修改原文档
|
||||
- 重点检查任务覆盖度和可执行性
|
||||
- tasks.md 是文档链末端，必须覆盖所有上游功能
|
||||
- 评审报告保存后，建议用户根据问题运行 `/mt` 修改
|
||||
@@ -0,0 +1,105 @@
|
||||
---
|
||||
name: ru
|
||||
description: 评审 UIDesign.md，对比 DevelopmentPlan 检查设计一致性，输出结构化评审报告。
|
||||
---
|
||||
|
||||
# Review UIDesign
|
||||
|
||||
当用户调用 `/ru` 时，执行以下步骤：
|
||||
|
||||
## 1. 读取文档
|
||||
|
||||
读取以下文件：
|
||||
|
||||
1. `doc/UIDesign.md` - 目标文档（必须存在）
|
||||
2. `doc/DevelopmentPlan.md` - 上游参照文档
|
||||
|
||||
如果 UIDesign.md 不存在，提示用户：
|
||||
> UIDesign.md 不存在，请先使用 `/wu` 生成 UI 设计文档。
|
||||
|
||||
## 2. 评审维度
|
||||
|
||||
### 2.1 与 DevelopmentPlan 一致性检查
|
||||
|
||||
- UI 页面是否覆盖所有功能模块
|
||||
- 交互流程是否与开发计划匹配
|
||||
- 页面结构是否支撑功能需求
|
||||
|
||||
### 2.2 设计完整性检查
|
||||
|
||||
- 页面列表是否完整
|
||||
- 每个页面是否有清晰的布局描述
|
||||
- 交互说明是否充分
|
||||
- 状态变化是否考虑全面（加载、错误、空状态等）
|
||||
|
||||
### 2.3 可用性检查
|
||||
|
||||
- 用户流程是否顺畅
|
||||
- 信息架构是否合理
|
||||
- 是否有一致的设计规范
|
||||
|
||||
## 3. 生成评审报告
|
||||
|
||||
输出到 `doc/review-UIDesign-claude.md`，结构如下：
|
||||
|
||||
```markdown
|
||||
# UIDesign 评审报告
|
||||
|
||||
## 概要
|
||||
|
||||
| 项目 | 内容 |
|
||||
|------|------|
|
||||
| 评审时间 | {YYYY-MM-DD HH:MM} |
|
||||
| 目标文档 | doc/UIDesign.md |
|
||||
| 参照文档 | doc/DevelopmentPlan.md |
|
||||
| 问题统计 | X 个严重 / Y 个一般 / Z 个建议 |
|
||||
|
||||
## 页面覆盖分析
|
||||
|
||||
| DevelopmentPlan 功能 | UIDesign 页面 | 状态 |
|
||||
|----------------------|---------------|------|
|
||||
| {功能名} | {对应页面} | ✅/⚠️/❌ |
|
||||
|
||||
**覆盖率**: X/Y 完全覆盖
|
||||
|
||||
## 设计一致性检查
|
||||
|
||||
| 检查项 | 结果 |
|
||||
|--------|------|
|
||||
| 页面命名规范 | ✅/❌ |
|
||||
| 布局风格统一 | ✅/❌ |
|
||||
| 交互模式一致 | ✅/❌ |
|
||||
|
||||
## 问题清单
|
||||
|
||||
### 严重问题 (Critical)
|
||||
{问题列表，含位置引用}
|
||||
|
||||
### 一般问题 (Major)
|
||||
{问题列表，含位置引用}
|
||||
|
||||
### 改进建议 (Minor)
|
||||
{建议列表}
|
||||
|
||||
## 评审结论
|
||||
|
||||
{通过 / 需修改后通过 / 不通过}
|
||||
|
||||
### 下一步行动
|
||||
- [ ] {待办事项}
|
||||
```
|
||||
|
||||
## 4. 输出规范
|
||||
|
||||
- 输出语言：中文
|
||||
- 问题分级：Critical / Major / Minor
|
||||
- 包含文件引用（如 `doc/UIDesign.md:45`）
|
||||
- 设计问题需说明影响的用户体验
|
||||
|
||||
---
|
||||
|
||||
## 注意事项
|
||||
|
||||
- 只做评审，不修改原文档
|
||||
- 重点检查页面覆盖度和设计一致性
|
||||
- 评审报告保存后，建议用户根据问题运行 `/mu` 修改
|
||||
@@ -0,0 +1,410 @@
|
||||
---
|
||||
name: tdd-workflow
|
||||
description: Use this skill when writing new features, fixing bugs, or refactoring code. Enforces test-driven development with 80%+ coverage including unit, integration, and E2E tests.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Test-Driven Development Workflow
|
||||
|
||||
This skill ensures all code development follows TDD principles with comprehensive test coverage.
|
||||
|
||||
## When to Activate
|
||||
|
||||
- Writing new features or functionality
|
||||
- Fixing bugs or issues
|
||||
- Refactoring existing code
|
||||
- Adding API endpoints
|
||||
- Creating new components
|
||||
|
||||
## Core Principles
|
||||
|
||||
### 1. Tests BEFORE Code
|
||||
ALWAYS write tests first, then implement code to make tests pass.
|
||||
|
||||
### 2. Coverage Requirements
|
||||
- Minimum 80% coverage (unit + integration + E2E)
|
||||
- All edge cases covered
|
||||
- Error scenarios tested
|
||||
- Boundary conditions verified
|
||||
|
||||
### 3. Test Types
|
||||
|
||||
#### Unit Tests
|
||||
- Individual functions and utilities
|
||||
- Component logic
|
||||
- Pure functions
|
||||
- Helpers and utilities
|
||||
|
||||
#### Integration Tests
|
||||
- API endpoints
|
||||
- Database operations
|
||||
- Service interactions
|
||||
- External API calls
|
||||
|
||||
#### E2E Tests (Playwright)
|
||||
- Critical user flows
|
||||
- Complete workflows
|
||||
- Browser automation
|
||||
- UI interactions
|
||||
|
||||
## TDD Workflow Steps
|
||||
|
||||
### Step 1: Write User Journeys
|
||||
```
|
||||
As a [role], I want to [action], so that [benefit]
|
||||
|
||||
Example:
|
||||
As a user, I want to search for markets semantically,
|
||||
so that I can find relevant markets even without exact keywords.
|
||||
```
|
||||
|
||||
### Step 2: Generate Test Cases
|
||||
For each user journey, create comprehensive test cases:
|
||||
|
||||
```typescript
|
||||
describe('Semantic Search', () => {
|
||||
it('returns relevant markets for query', async () => {
|
||||
// Test implementation
|
||||
})
|
||||
|
||||
it('handles empty query gracefully', async () => {
|
||||
// Test edge case
|
||||
})
|
||||
|
||||
it('falls back to substring search when Redis unavailable', async () => {
|
||||
// Test fallback behavior
|
||||
})
|
||||
|
||||
it('sorts results by similarity score', async () => {
|
||||
// Test sorting logic
|
||||
})
|
||||
})
|
||||
```
|
||||
|
||||
### Step 3: Run Tests (They Should Fail)
|
||||
```bash
|
||||
npm test
|
||||
# Tests should fail - we haven't implemented yet
|
||||
```
|
||||
|
||||
### Step 4: Implement Code
|
||||
Write minimal code to make tests pass:
|
||||
|
||||
```typescript
|
||||
// Implementation guided by tests
|
||||
export async function searchMarkets(query: string) {
|
||||
// Implementation here
|
||||
}
|
||||
```
|
||||
|
||||
### Step 5: Run Tests Again
|
||||
```bash
|
||||
npm test
|
||||
# Tests should now pass
|
||||
```
|
||||
|
||||
### Step 6: Refactor
|
||||
Improve code quality while keeping tests green:
|
||||
- Remove duplication
|
||||
- Improve naming
|
||||
- Optimize performance
|
||||
- Enhance readability
|
||||
|
||||
### Step 7: Verify Coverage
|
||||
```bash
|
||||
npm run test:coverage
|
||||
# Verify 80%+ coverage achieved
|
||||
```
|
||||
|
||||
## Testing Patterns
|
||||
|
||||
### Unit Test Pattern (Jest/Vitest)
|
||||
```typescript
|
||||
import { render, screen, fireEvent } from '@testing-library/react'
|
||||
import { Button } from './Button'
|
||||
|
||||
describe('Button Component', () => {
|
||||
it('renders with correct text', () => {
|
||||
render(<Button>Click me</Button>)
|
||||
expect(screen.getByText('Click me')).toBeInTheDocument()
|
||||
})
|
||||
|
||||
it('calls onClick when clicked', () => {
|
||||
const handleClick = jest.fn()
|
||||
render(<Button onClick={handleClick}>Click</Button>)
|
||||
|
||||
fireEvent.click(screen.getByRole('button'))
|
||||
|
||||
expect(handleClick).toHaveBeenCalledTimes(1)
|
||||
})
|
||||
|
||||
it('is disabled when disabled prop is true', () => {
|
||||
render(<Button disabled>Click</Button>)
|
||||
expect(screen.getByRole('button')).toBeDisabled()
|
||||
})
|
||||
})
|
||||
```
|
||||
|
||||
### API Integration Test Pattern
|
||||
```typescript
|
||||
import { NextRequest } from 'next/server'
|
||||
import { GET } from './route'
|
||||
|
||||
describe('GET /api/markets', () => {
|
||||
it('returns markets successfully', async () => {
|
||||
const request = new NextRequest('http://localhost/api/markets')
|
||||
const response = await GET(request)
|
||||
const data = await response.json()
|
||||
|
||||
expect(response.status).toBe(200)
|
||||
expect(data.success).toBe(true)
|
||||
expect(Array.isArray(data.data)).toBe(true)
|
||||
})
|
||||
|
||||
it('validates query parameters', async () => {
|
||||
const request = new NextRequest('http://localhost/api/markets?limit=invalid')
|
||||
const response = await GET(request)
|
||||
|
||||
expect(response.status).toBe(400)
|
||||
})
|
||||
|
||||
it('handles database errors gracefully', async () => {
|
||||
// Mock database failure
|
||||
const request = new NextRequest('http://localhost/api/markets')
|
||||
// Test error handling
|
||||
})
|
||||
})
|
||||
```
|
||||
|
||||
### E2E Test Pattern (Playwright)
|
||||
```typescript
|
||||
import { test, expect } from '@playwright/test'
|
||||
|
||||
test('user can search and filter markets', async ({ page }) => {
|
||||
// Navigate to markets page
|
||||
await page.goto('/')
|
||||
await page.click('a[href="/markets"]')
|
||||
|
||||
// Verify page loaded
|
||||
await expect(page.locator('h1')).toContainText('Markets')
|
||||
|
||||
// Search for markets
|
||||
await page.fill('input[placeholder="Search markets"]', 'election')
|
||||
|
||||
// Wait for debounce and results
|
||||
await page.waitForTimeout(600)
|
||||
|
||||
// Verify search results displayed
|
||||
const results = page.locator('[data-testid="market-card"]')
|
||||
await expect(results).toHaveCount(5, { timeout: 5000 })
|
||||
|
||||
// Verify results contain search term
|
||||
const firstResult = results.first()
|
||||
await expect(firstResult).toContainText('election', { ignoreCase: true })
|
||||
|
||||
// Filter by status
|
||||
await page.click('button:has-text("Active")')
|
||||
|
||||
// Verify filtered results
|
||||
await expect(results).toHaveCount(3)
|
||||
})
|
||||
|
||||
test('user can create a new market', async ({ page }) => {
|
||||
// Login first
|
||||
await page.goto('/creator-dashboard')
|
||||
|
||||
// Fill market creation form
|
||||
await page.fill('input[name="name"]', 'Test Market')
|
||||
await page.fill('textarea[name="description"]', 'Test description')
|
||||
await page.fill('input[name="endDate"]', '2025-12-31')
|
||||
|
||||
// Submit form
|
||||
await page.click('button[type="submit"]')
|
||||
|
||||
// Verify success message
|
||||
await expect(page.locator('text=Market created successfully')).toBeVisible()
|
||||
|
||||
// Verify redirect to market page
|
||||
await expect(page).toHaveURL(/\/markets\/test-market/)
|
||||
})
|
||||
```
|
||||
|
||||
## Test File Organization
|
||||
|
||||
```
|
||||
src/
|
||||
├── components/
|
||||
│ ├── Button/
|
||||
│ │ ├── Button.tsx
|
||||
│ │ ├── Button.test.tsx # Unit tests
|
||||
│ │ └── Button.stories.tsx # Storybook
|
||||
│ └── MarketCard/
|
||||
│ ├── MarketCard.tsx
|
||||
│ └── MarketCard.test.tsx
|
||||
├── app/
|
||||
│ └── api/
|
||||
│ └── markets/
|
||||
│ ├── route.ts
|
||||
│ └── route.test.ts # Integration tests
|
||||
└── e2e/
|
||||
├── markets.spec.ts # E2E tests
|
||||
├── trading.spec.ts
|
||||
└── auth.spec.ts
|
||||
```
|
||||
|
||||
## Mocking External Services
|
||||
|
||||
### Supabase Mock
|
||||
```typescript
|
||||
jest.mock('@/lib/supabase', () => ({
|
||||
supabase: {
|
||||
from: jest.fn(() => ({
|
||||
select: jest.fn(() => ({
|
||||
eq: jest.fn(() => Promise.resolve({
|
||||
data: [{ id: 1, name: 'Test Market' }],
|
||||
error: null
|
||||
}))
|
||||
}))
|
||||
}))
|
||||
}
|
||||
}))
|
||||
```
|
||||
|
||||
### Redis Mock
|
||||
```typescript
|
||||
jest.mock('@/lib/redis', () => ({
|
||||
searchMarketsByVector: jest.fn(() => Promise.resolve([
|
||||
{ slug: 'test-market', similarity_score: 0.95 }
|
||||
])),
|
||||
checkRedisHealth: jest.fn(() => Promise.resolve({ connected: true }))
|
||||
}))
|
||||
```
|
||||
|
||||
### OpenAI Mock
|
||||
```typescript
|
||||
jest.mock('@/lib/openai', () => ({
|
||||
generateEmbedding: jest.fn(() => Promise.resolve(
|
||||
new Array(1536).fill(0.1) // Mock 1536-dim embedding
|
||||
))
|
||||
}))
|
||||
```
|
||||
|
||||
## Test Coverage Verification
|
||||
|
||||
### Run Coverage Report
|
||||
```bash
|
||||
npm run test:coverage
|
||||
```
|
||||
|
||||
### Coverage Thresholds
|
||||
```json
|
||||
{
|
||||
"jest": {
|
||||
"coverageThresholds": {
|
||||
"global": {
|
||||
"branches": 80,
|
||||
"functions": 80,
|
||||
"lines": 80,
|
||||
"statements": 80
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Common Testing Mistakes to Avoid
|
||||
|
||||
### ❌ WRONG: Testing Implementation Details
|
||||
```typescript
|
||||
// Don't test internal state
|
||||
expect(component.state.count).toBe(5)
|
||||
```
|
||||
|
||||
### ✅ CORRECT: Test User-Visible Behavior
|
||||
```typescript
|
||||
// Test what users see
|
||||
expect(screen.getByText('Count: 5')).toBeInTheDocument()
|
||||
```
|
||||
|
||||
### ❌ WRONG: Brittle Selectors
|
||||
```typescript
|
||||
// Breaks easily
|
||||
await page.click('.css-class-xyz')
|
||||
```
|
||||
|
||||
### ✅ CORRECT: Semantic Selectors
|
||||
```typescript
|
||||
// Resilient to changes
|
||||
await page.click('button:has-text("Submit")')
|
||||
await page.click('[data-testid="submit-button"]')
|
||||
```
|
||||
|
||||
### ❌ WRONG: No Test Isolation
|
||||
```typescript
|
||||
// Tests depend on each other
|
||||
test('creates user', () => { /* ... */ })
|
||||
test('updates same user', () => { /* depends on previous test */ })
|
||||
```
|
||||
|
||||
### ✅ CORRECT: Independent Tests
|
||||
```typescript
|
||||
// Each test sets up its own data
|
||||
test('creates user', () => {
|
||||
const user = createTestUser()
|
||||
// Test logic
|
||||
})
|
||||
|
||||
test('updates user', () => {
|
||||
const user = createTestUser()
|
||||
// Update logic
|
||||
})
|
||||
```
|
||||
|
||||
## Continuous Testing
|
||||
|
||||
### Watch Mode During Development
|
||||
```bash
|
||||
npm test -- --watch
|
||||
# Tests run automatically on file changes
|
||||
```
|
||||
|
||||
### Pre-Commit Hook
|
||||
```bash
|
||||
# Runs before every commit
|
||||
npm test && npm run lint
|
||||
```
|
||||
|
||||
### CI/CD Integration
|
||||
```yaml
|
||||
# GitHub Actions
|
||||
- name: Run Tests
|
||||
run: npm test -- --coverage
|
||||
- name: Upload Coverage
|
||||
uses: codecov/codecov-action@v3
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. **Write Tests First** - Always TDD
|
||||
2. **One Assert Per Test** - Focus on single behavior
|
||||
3. **Descriptive Test Names** - Explain what's tested
|
||||
4. **Arrange-Act-Assert** - Clear test structure
|
||||
5. **Mock External Dependencies** - Isolate unit tests
|
||||
6. **Test Edge Cases** - Null, undefined, empty, large
|
||||
7. **Test Error Paths** - Not just happy paths
|
||||
8. **Keep Tests Fast** - Unit tests < 50ms each
|
||||
9. **Clean Up After Tests** - No side effects
|
||||
10. **Review Coverage Reports** - Identify gaps
|
||||
|
||||
## Success Metrics
|
||||
|
||||
- 80%+ code coverage achieved
|
||||
- All tests passing (green)
|
||||
- No skipped or disabled tests
|
||||
- Fast test execution (< 30s for unit tests)
|
||||
- E2E tests cover critical user flows
|
||||
- Tests catch bugs before production
|
||||
|
||||
---
|
||||
|
||||
**Remember**: Tests are not optional. They are the safety net that enables confident refactoring, rapid development, and production reliability.
|
||||
@@ -0,0 +1,78 @@
|
||||
---
|
||||
name: update
|
||||
aliases: [up]
|
||||
description: 收集用户反馈并更新最近使用的 skill。可通过 /update 或 /up 调用。在用完某个 skill 后调用此命令来优化该 skill。
|
||||
disable-model-invocation: true
|
||||
argument-hint: [skill-name]
|
||||
---
|
||||
|
||||
# Skill 更新助手
|
||||
|
||||
当用户调用 `/up` 或 `/up <skill-name>` 时，执行以下步骤：
|
||||
|
||||
## 1. 识别目标 Skill
|
||||
|
||||
**如果用户提供了参数 `$ARGUMENTS`**：
|
||||
- 直接使用指定的 skill 名称作为更新目标
|
||||
|
||||
**如果没有提供参数**：
|
||||
分析当前对话历史，找出最近使用的 skill：
|
||||
- 搜索对话中的 `<command-name>` 标签，识别调用过的 skill
|
||||
- 如果找到多个 skill，让用户确认要更新哪一个
|
||||
- 如果没有找到任何 skill 调用记录，提示用户先使用一个 skill
|
||||
|
||||
## 2. 收集用户反馈
|
||||
|
||||
向用户询问以下问题（使用 AskUserQuestion 工具）：
|
||||
|
||||
**问题 1：这次使用体验如何？**
|
||||
- 很好，skill 完全满足需求
|
||||
- 基本满足，但有改进空间
|
||||
- 不太满意，需要较大调整
|
||||
|
||||
**问题 2：具体需要改进的方面？**（多选）
|
||||
- 执行步骤不够清晰
|
||||
- 缺少某些功能
|
||||
- 输出格式需要调整
|
||||
- 提示词需要优化
|
||||
- 其他（用户自定义输入）
|
||||
|
||||
## 3. 分析优化点
|
||||
|
||||
基于用户反馈和本次 skill 使用过程，分析以下方面：
|
||||
|
||||
1. **执行流程**：哪些步骤可以简化或合并？
|
||||
2. **指令清晰度**：哪些指令描述不够明确？
|
||||
3. **遗漏功能**：有哪些场景没有覆盖到？
|
||||
4. **输出质量**：输出格式是否符合用户预期？
|
||||
|
||||
## 4. 定位 Skill 文件
|
||||
|
||||
按以下优先级搜索 skill 文件：
|
||||
1. 项目级：`.claude/skills/<skill-name>/SKILL.md`
|
||||
2. 用户级：`~/.claude/skills/<skill-name>/SKILL.md`
|
||||
|
||||
## 5. 更新 Skill
|
||||
|
||||
读取现有的 SKILL.md 文件内容，根据分析结果进行更新：
|
||||
|
||||
- 保持 frontmatter 格式不变（除非需要修改 description）
|
||||
- 优化执行步骤的描述
|
||||
- 添加缺失的功能说明
|
||||
- 改进提示词的表达方式
|
||||
- 添加必要的注意事项或边界情况处理
|
||||
|
||||
## 6. 确认更新
|
||||
|
||||
在更新前，向用户展示：
|
||||
- 修改前后的对比（diff 格式）
|
||||
- 说明每处修改的原因
|
||||
|
||||
用户确认后才执行实际的文件更新。
|
||||
|
||||
## 注意事项
|
||||
|
||||
- 如果 skill 文件不存在或路径无法确定，提示用户手动指定路径
|
||||
- 更新时保持 skill 的原有风格和结构
|
||||
- 重大修改需要用户明确确认
|
||||
- 保留原有的有效内容，只做增量优化
|
||||
@@ -0,0 +1,323 @@
|
||||
---
|
||||
name: wd
|
||||
description: 从上游文档生成 DevelopmentPlan.md，包含技术方案和开发排期。
|
||||
---
|
||||
|
||||
# Write DevelopmentPlan
|
||||
|
||||
> **文档定位**：DevelopmentPlan 是「执行蓝图」文档，偏技术语言和时间约束。定义技术架构、实现方案、开发阶段、里程碑，是开发团队的行动指南。
|
||||
|
||||
当用户调用 `/wd` 时，执行以下步骤：
|
||||
|
||||
## 1. 读取源文档
|
||||
|
||||
读取以下文件：
|
||||
|
||||
1. `doc/RequirementsDoc.md` - 必须存在
|
||||
2. `doc/PRD.md` - 必须存在
|
||||
3. `doc/FeatureSummary.md` - 必须存在
|
||||
|
||||
如果文件不存在，提示用户：
|
||||
> 缺少上游文档，请先确保 RequirementsDoc.md、PRD.md 和 FeatureSummary.md 存在。
|
||||
|
||||
如果已存在 `doc/DevelopmentPlan.md`，同时读取作为参考（保持风格一致）。
|
||||
|
||||
## 2. 分析开发需求
|
||||
|
||||
从上游文档中提取以下信息：
|
||||
|
||||
### 2.1 功能需求
|
||||
|
||||
- 从 FeatureSummary 获取功能清单和契约
|
||||
- 从 PRD 获取功能详情和验收标准
|
||||
|
||||
### 2.2 技术约束
|
||||
|
||||
- 从 PRD 获取技术约束
|
||||
- 从 RequirementsDoc 获取技术决策
|
||||
|
||||
### 2.3 优先级排序
|
||||
|
||||
- 按 P0 → P1 → P2 顺序规划开发
|
||||
- 考虑功能依赖关系
|
||||
|
||||
## 3. 生成 DevelopmentPlan
|
||||
|
||||
按以下结构生成文档：
|
||||
|
||||
```markdown
|
||||
# {产品名称} - 开发计划
|
||||
|
||||
## 文档信息
|
||||
|
||||
| 项目 | 内容 |
|
||||
|------|------|
|
||||
| 版本 | v1.0 |
|
||||
| 创建日期 | {YYYY-MM-DD} |
|
||||
| 来源文档 | FeatureSummary.md |
|
||||
|
||||
## 1. 项目概述
|
||||
|
||||
### 1.1 项目目标
|
||||
|
||||
{从 PRD 提取的项目目标}
|
||||
|
||||
### 1.2 技术栈
|
||||
|
||||
| 层级 | 技术选型 | 版本 | 说明 |
|
||||
|------|----------|------|------|
|
||||
| 前端 | {技术} | {版本} | {说明} |
|
||||
| 后端 | {技术} | {版本} | {说明} |
|
||||
| 数据库 | {技术} | {版本} | {说明} |
|
||||
| 基础设施 | {技术} | {版本} | {说明} |
|
||||
|
||||
### 1.3 开发原则
|
||||
|
||||
{开发规范和原则}
|
||||
|
||||
## 2. 技术架构
|
||||
|
||||
### 2.1 系统架构图
|
||||
|
||||
**【必须】使用架构图展示系统整体结构：**
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────┐
|
||||
│ 客户端层 │
|
||||
│ ┌──────────────┐ ┌──────────────┐ │
|
||||
│ │ Web App │ │ Mobile App │ │
|
||||
│ └──────┬───────┘ └──────┬───────┘ │
|
||||
└─────────┼─────────────────┼─────────────────────────────┘
|
||||
│ │
|
||||
▼ ▼
|
||||
┌─────────────────────────────────────────────────────────┐
|
||||
│ API 网关层 │
|
||||
│ ┌──────────────────────────────────────────────────┐ │
|
||||
│ │ API Gateway / Load Balancer │ │
|
||||
│ └──────────────────────────────────────────────────┘ │
|
||||
└─────────────────────────────────────────────────────────┘
|
||||
│
|
||||
▼
|
||||
┌─────────────────────────────────────────────────────────┐
|
||||
│ 服务层 │
|
||||
│ ┌────────────┐ ┌────────────┐ ┌────────────┐ │
|
||||
│ │ 服务 A │ │ 服务 B │ │ 服务 C │ │
|
||||
│ └─────┬──────┘ └─────┬──────┘ └─────┬──────┘ │
|
||||
└────────┼───────────────┼───────────────┼────────────────┘
|
||||
│ │ │
|
||||
▼ ▼ ▼
|
||||
┌─────────────────────────────────────────────────────────┐
|
||||
│ 数据层 │
|
||||
│ ┌────────────┐ ┌────────────┐ ┌────────────┐ │
|
||||
│ │ 数据库 │ │ 缓存 │ │ 消息队列 │ │
|
||||
│ └────────────┘ └────────────┘ └────────────┘ │
|
||||
└─────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### 2.2 模块依赖图
|
||||
|
||||
**【必须】使用依赖图展示模块间关系：**
|
||||
|
||||
```
|
||||
┌──────────────┐
|
||||
│ 模块 A │
|
||||
│ (核心模块) │
|
||||
└──────┬───────┘
|
||||
│
|
||||
┌───┴───┐
|
||||
▼ ▼
|
||||
┌──────┐ ┌──────┐
|
||||
│模块B │ │模块C │
|
||||
└──┬───┘ └──┬───┘
|
||||
│ │
|
||||
▼ ▼
|
||||
┌──────────────┐
|
||||
│ 模块 D │
|
||||
│ (基础设施) │
|
||||
└──────────────┘
|
||||
```
|
||||
|
||||
### 2.3 数据流图
|
||||
|
||||
**【必须】使用数据流图展示关键数据流转：**
|
||||
|
||||
```
|
||||
用户请求 ──▶ API Gateway ──▶ 服务A ──▶ 数据库
|
||||
│
|
||||
▼
|
||||
缓存层
|
||||
│
|
||||
▼
|
||||
服务B ──▶ 外部API
|
||||
```
|
||||
|
||||
## 3. 开发阶段
|
||||
|
||||
### 3.1 阶段时间线
|
||||
|
||||
**【必须】使用时间线展示开发阶段：**
|
||||
|
||||
```
|
||||
Phase 1 Phase 2 Phase 3
|
||||
│ │ │
|
||||
{起止日期} {起止日期} {起止日期}
|
||||
│ │ │
|
||||
▼ ▼ ▼
|
||||
┌─────────┐ ┌─────────┐ ┌─────────┐
|
||||
│ 基础 │ ────▶ │ 核心 │ ────▶ │ 优化 │
|
||||
│ 架构 │ │ 功能 │ │ 扩展 │
|
||||
└─────────┘ └─────────┘ └─────────┘
|
||||
|
||||
交付物: 交付物: 交付物:
|
||||
• {交付1} • {交付1} • {交付1}
|
||||
• {交付2} • {交付2} • {交付2}
|
||||
```
|
||||
|
||||
### 3.2 Phase 1: {阶段名称}
|
||||
|
||||
**目标**: {阶段目标}
|
||||
|
||||
**时间**: {起止日期}
|
||||
|
||||
| 任务ID | 任务 | 描述 | 依赖 | 优先级 | 关联功能 |
|
||||
|--------|------|------|------|--------|----------|
|
||||
| T-001 | {任务名} | {描述} | - | P0 | F-001 |
|
||||
| T-002 | {任务名} | {描述} | T-001 | P0 | F-002 |
|
||||
|
||||
**阶段依赖图：**
|
||||
|
||||
```
|
||||
T-001 ──▶ T-002 ──▶ T-003
|
||||
│
|
||||
└──▶ T-004
|
||||
```
|
||||
|
||||
{重复以上结构覆盖所有阶段}
|
||||
|
||||
## 4. 技术方案
|
||||
|
||||
### 4.1 {模块名称}
|
||||
|
||||
**功能**: {功能描述}
|
||||
|
||||
**技术选型**:
|
||||
|
||||
| 组件 | 技术 | 选型理由 |
|
||||
|------|------|----------|
|
||||
| {组件} | {技术} | {理由} |
|
||||
|
||||
**架构设计**:
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────┐
|
||||
│ {模块名称} │
|
||||
├─────────────────────────────────────┤
|
||||
│ ┌─────────┐ ┌─────────┐ │
|
||||
│ │ 组件A │ ───▶ │ 组件B │ │
|
||||
│ └─────────┘ └─────────┘ │
|
||||
│ │ │ │
|
||||
│ ▼ ▼ │
|
||||
│ ┌─────────────────────────┐ │
|
||||
│ │ 数据层 │ │
|
||||
│ └─────────────────────────┘ │
|
||||
└─────────────────────────────────────┘
|
||||
```
|
||||
|
||||
**接口设计**:
|
||||
|
||||
| 接口 | 方法 | 路径 | 说明 |
|
||||
|------|------|------|------|
|
||||
| {接口名} | GET/POST | /api/xxx | {说明} |
|
||||
|
||||
**实现要点**:
|
||||
|
||||
- {技术要点1}
|
||||
- {技术要点2}
|
||||
|
||||
{重复以上结构覆盖所有模块}
|
||||
|
||||
## 5. 风险管理
|
||||
|
||||
| 风险 | 可能性 | 影响 | 应对措施 | 负责人 |
|
||||
|------|--------|------|----------|--------|
|
||||
| {风险} | 高/中/低 | 高/中/低 | {措施} | {负责人} |
|
||||
|
||||
## 6. 里程碑
|
||||
|
||||
**【必须】使用里程碑图展示关键节点：**
|
||||
|
||||
```
|
||||
M1 M2 M3 M4
|
||||
│ │ │ │
|
||||
▼ ▼ ▼ ▼
|
||||
◆───────────────◆───────────────◆───────────────◆
|
||||
│ │ │ │
|
||||
{日期} {日期} {日期} {日期}
|
||||
{里程碑名} {里程碑名} {里程碑名} {里程碑名}
|
||||
```
|
||||
|
||||
| 里程碑 | 日期 | 目标 | 交付物 | 验收标准 |
|
||||
|--------|------|------|--------|----------|
|
||||
| M1 | {日期} | {目标} | {交付物} | {标准} |
|
||||
|
||||
## 7. 资源需求
|
||||
|
||||
| 角色 | 人数 | 职责 | 参与阶段 |
|
||||
|------|------|------|----------|
|
||||
| {角色} | {人数} | {职责} | Phase 1-2 |
|
||||
```
|
||||
|
||||
## 4. 保存文档
|
||||
|
||||
将生成的 DevelopmentPlan 保存到 `doc/DevelopmentPlan.md`。
|
||||
|
||||
如果文件已存在，覆盖原文件（历史版本通过 git 追溯）。
|
||||
|
||||
## 5. 输出摘要
|
||||
|
||||
向用户展示生成摘要：
|
||||
|
||||
- DevelopmentPlan 文件路径
|
||||
- 开发阶段数量
|
||||
- 技术方案模块数量
|
||||
- 建议的下一步操作（运行 `/rd` 评审）
|
||||
|
||||
---
|
||||
|
||||
## 可视化输出要求
|
||||
|
||||
DevelopmentPlan 作为「执行蓝图」文档，需要清晰传达技术方案和时间安排，**必须包含**：
|
||||
|
||||
| 章节 | 可视化形式 | 必要性 |
|
||||
|------|------------|--------|
|
||||
| 2.1 系统架构图 | 架构图（ASCII） | **必须** |
|
||||
| 2.2 模块依赖图 | 依赖图（ASCII） | **必须** |
|
||||
| 2.3 数据流图 | 数据流图（ASCII） | **必须** |
|
||||
| 3.1 阶段时间线 | 时间线（ASCII） | **必须** |
|
||||
| 3.x 阶段依赖图 | 任务依赖图 | **必须** |
|
||||
| 4.x 模块架构 | 模块架构图 | 建议 |
|
||||
| 6. 里程碑 | 里程碑图 | **必须** |
|
||||
|
||||
## 注意事项
|
||||
|
||||
- DevelopmentPlan 使用**技术语言**，面向开发团队
|
||||
- 开发计划必须覆盖 FeatureSummary 所有功能
|
||||
- 技术方案要具体可执行，避免过于抽象
|
||||
- 阶段划分要合理，考虑依赖关系
|
||||
- 时间安排要务实，预留缓冲
|
||||
- 风险评估要全面，有应对措施
|
||||
|
||||
## 质量检查
|
||||
|
||||
生成 DevelopmentPlan 后，自查以下项目：
|
||||
|
||||
- [ ] 覆盖 FeatureSummary 所有功能
|
||||
- [ ] **系统架构图清晰展示整体结构**
|
||||
- [ ] **模块依赖图清晰展示依赖关系**
|
||||
- [ ] **数据流图展示关键数据流转**
|
||||
- [ ] **开发阶段有时间线图**
|
||||
- [ ] **每个阶段有任务依赖图**
|
||||
- [ ] **里程碑有里程碑图**
|
||||
- [ ] 技术方案具体可执行
|
||||
- [ ] 任务 ID 唯一（T-xxx）
|
||||
- [ ] 任务与功能 ID 关联
|
||||
@@ -0,0 +1,234 @@
|
||||
---
|
||||
name: wf
|
||||
description: 从 RequirementsDoc.md 和 PRD.md 生成 FeatureSummary.md，提供功能全貌概览。
|
||||
---
|
||||
|
||||
# Write FeatureSummary
|
||||
|
||||
> **文档定位**：FeatureSummary 是「功能契约」文档，是产品与开发的桥梁。精确定义功能边界、输入输出、依赖关系，确保双方对"做什么"达成共识。
|
||||
|
||||
当用户调用 `/wf` 时，执行以下步骤：
|
||||
|
||||
## 1. 读取源文档
|
||||
|
||||
读取以下文件：
|
||||
|
||||
1. `doc/RequirementsDoc.md` - 必须存在
|
||||
2. `doc/PRD.md` - 必须存在
|
||||
|
||||
如果文件不存在，提示用户：
|
||||
> 缺少上游文档，请先确保 RequirementsDoc.md 和 PRD.md 存在。
|
||||
|
||||
如果已存在 `doc/FeatureSummary.md`，同时读取作为参考（保持风格一致）。
|
||||
|
||||
## 2. 分析功能需求
|
||||
|
||||
从 PRD 中提取以下信息：
|
||||
|
||||
### 2.1 功能模块
|
||||
|
||||
- 从 PRD 3.1 功能架构提取模块结构
|
||||
- 从 PRD 3.2 功能详情提取各模块功能点
|
||||
|
||||
### 2.2 功能分类
|
||||
|
||||
按以下维度整理功能：
|
||||
|
||||
- 按模块分组
|
||||
- 按优先级标注（P0/P1/P2）
|
||||
- 按用户角色关联
|
||||
|
||||
### 2.3 功能边界
|
||||
|
||||
明确每个功能的：
|
||||
|
||||
- 输入：触发条件、输入数据
|
||||
- 输出：预期结果、输出数据
|
||||
- 边界：不包含什么、异常情况
|
||||
|
||||
## 3. 生成 FeatureSummary
|
||||
|
||||
按以下结构生成文档：
|
||||
|
||||
```markdown
|
||||
# {产品名称} - 功能摘要
|
||||
|
||||
## 文档信息
|
||||
|
||||
| 项目 | 内容 |
|
||||
|------|------|
|
||||
| 版本 | v1.0 |
|
||||
| 创建日期 | {YYYY-MM-DD} |
|
||||
| 来源文档 | PRD.md |
|
||||
|
||||
## 1. 功能总览
|
||||
|
||||
### 1.1 功能统计
|
||||
|
||||
| 类别 | 数量 |
|
||||
|------|------|
|
||||
| 功能模块 | X 个 |
|
||||
| P0 功能 | X 个 |
|
||||
| P1 功能 | X 个 |
|
||||
| P2 功能 | X 个 |
|
||||
|
||||
### 1.2 功能架构图
|
||||
|
||||
**【必须】使用模块图展示功能架构和模块关系：**
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────┐
|
||||
│ {产品名称} │
|
||||
├─────────────────────────────────────────────────┤
|
||||
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
|
||||
│ │ 模块A │ │ 模块B │ │ 模块C │ │
|
||||
│ │ ──────── │ │ ──────── │ │ ──────── │ │
|
||||
│ │ • 功能1 │ │ • 功能1 │ │ • 功能1 │ │
|
||||
│ │ • 功能2 │ │ • 功能2 │ │ │ │
|
||||
│ └──────────┘ └──────────┘ └──────────┘ │
|
||||
└─────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### 1.3 模块依赖关系
|
||||
|
||||
**【必须】使用依赖图展示模块间关系：**
|
||||
|
||||
```
|
||||
┌──────────┐
|
||||
│ 模块A │
|
||||
└────┬─────┘
|
||||
│ 依赖
|
||||
▼
|
||||
┌──────────┐ ┌──────────┐
|
||||
│ 模块B │ ◀── │ 模块C │
|
||||
└──────────┘ └──────────┘
|
||||
```
|
||||
|
||||
## 2. 功能清单
|
||||
|
||||
### 2.1 {模块名称}
|
||||
|
||||
**模块职责**: {一句话描述模块职责}
|
||||
|
||||
#### 功能列表
|
||||
|
||||
| ID | 功能 | 描述 | 优先级 | 关联用户故事 |
|
||||
|----|------|------|--------|--------------|
|
||||
| F-001 | {功能名} | {简要描述} | P0 | US-xxx |
|
||||
|
||||
#### 功能契约详情
|
||||
|
||||
**F-001: {功能名}**
|
||||
|
||||
| 契约项 | 说明 |
|
||||
|--------|------|
|
||||
| **触发条件** | {什么情况下触发此功能} |
|
||||
| **输入** | {输入数据/参数} |
|
||||
| **处理逻辑** | {核心处理步骤} |
|
||||
| **输出** | {输出结果/返回值} |
|
||||
| **异常情况** | {可能的错误及处理} |
|
||||
| **边界说明** | {不包含什么、限制条件} |
|
||||
|
||||
{重复以上结构覆盖所有功能}
|
||||
|
||||
{重复以上结构覆盖所有模块}
|
||||
|
||||
## 3. 功能依赖矩阵
|
||||
|
||||
**【必须】使用矩阵表格展示功能间依赖：**
|
||||
|
||||
| 功能 | 依赖 F-001 | 依赖 F-002 | 依赖 F-003 |
|
||||
|------|------------|------------|------------|
|
||||
| F-001 | - | | |
|
||||
| F-002 | ✓ | - | |
|
||||
| F-003 | | ✓ | - |
|
||||
|
||||
说明：
|
||||
- ✓ 表示行功能依赖列功能
|
||||
- 空白表示无依赖
|
||||
|
||||
## 4. 功能流程图
|
||||
|
||||
**【必须】使用流程图展示核心功能流程：**
|
||||
|
||||
### 4.1 {核心流程名称}
|
||||
|
||||
```
|
||||
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
|
||||
│ F-001 │ ──▶ │ F-002 │ ──▶ │ F-003 │ ──▶ │ 完成 │
|
||||
│ {功能} │ │ {功能} │ │ {功能} │ │ │
|
||||
└─────────┘ └─────────┘ └─────────┘ └─────────┘
|
||||
│
|
||||
▼ 异常
|
||||
┌─────────┐
|
||||
│ 错误处理 │
|
||||
└─────────┘
|
||||
```
|
||||
|
||||
## 5. 版本规划
|
||||
|
||||
| 版本 | 包含功能 | 功能ID | 目标 |
|
||||
|------|----------|--------|------|
|
||||
| MVP | {功能列表} | F-001, F-002 | {目标} |
|
||||
| v1.1 | {功能列表} | F-003, F-004 | {目标} |
|
||||
| v2.0 | {功能列表} | F-005+ | {目标} |
|
||||
|
||||
## 6. 接口契约预览
|
||||
|
||||
> 详细接口定义在 DevelopmentPlan 中，此处仅列出关键接口
|
||||
|
||||
| 功能 | 接口类型 | 简要说明 |
|
||||
|------|----------|----------|
|
||||
| F-001 | API | {说明} |
|
||||
| F-002 | Event | {说明} |
|
||||
```
|
||||
|
||||
## 4. 保存文档
|
||||
|
||||
将生成的 FeatureSummary 保存到 `doc/FeatureSummary.md`。
|
||||
|
||||
如果文件已存在，覆盖原文件（历史版本通过 git 追溯）。
|
||||
|
||||
## 5. 输出摘要
|
||||
|
||||
向用户展示生成摘要：
|
||||
|
||||
- FeatureSummary 文件路径
|
||||
- 功能模块数量
|
||||
- 各优先级功能数量
|
||||
- 建议的下一步操作（运行 `/rf` 评审）
|
||||
|
||||
---
|
||||
|
||||
## 可视化输出要求
|
||||
|
||||
FeatureSummary 作为「功能契约」文档，需要精确传达功能定义，**必须包含**：
|
||||
|
||||
| 章节 | 可视化形式 | 必要性 |
|
||||
|------|------------|--------|
|
||||
| 1.2 功能架构图 | 模块图（ASCII） | **必须** |
|
||||
| 1.3 模块依赖关系 | 依赖图（ASCII） | **必须** |
|
||||
| 3. 功能依赖矩阵 | 矩阵表格 | **必须** |
|
||||
| 4. 功能流程图 | 流程图（ASCII） | **必须** |
|
||||
|
||||
## 注意事项
|
||||
|
||||
- FeatureSummary 是产品与开发的**桥梁**，语言要精确、无歧义
|
||||
- 功能摘要必须完全来源于 PRD，不要臆造功能
|
||||
- 每个功能必须有明确的**输入、输出、边界**
|
||||
- 功能 ID 必须唯一（F-xxx 格式）
|
||||
- 优先级必须与 PRD 一致
|
||||
- 功能依赖关系必须明确，避免循环依赖
|
||||
|
||||
## 质量检查
|
||||
|
||||
生成 FeatureSummary 后，自查以下项目：
|
||||
|
||||
- [ ] 所有功能都有唯一 ID（F-xxx）
|
||||
- [ ] 所有功能都有契约详情（输入/输出/边界）
|
||||
- [ ] **功能架构图清晰展示模块结构**
|
||||
- [ ] **模块依赖图清晰展示依赖关系**
|
||||
- [ ] **功能依赖矩阵完整**
|
||||
- [ ] **核心流程有流程图**
|
||||
- [ ] 优先级与 PRD 一致
|
||||
- [ ] 无遗漏 PRD 中的功能
|
||||
@@ -0,0 +1,318 @@
|
||||
---
|
||||
name: wp
|
||||
description: 从 RequirementsDoc.md 生成 PRD.md，将需求文档转化为结构化的产品需求文档。
|
||||
---
|
||||
|
||||
# Write PRD
|
||||
|
||||
> **文档定位**：PRD 是「价值主张」文档，使用业务语言描述产品要解决什么问题、为谁创造什么价值。面向产品、业务、管理层沟通。
|
||||
|
||||
当用户调用 `/wp` 时，执行以下步骤：
|
||||
|
||||
## 1. 读取源文档
|
||||
|
||||
读取 `doc/RequirementsDoc.md` 文件。
|
||||
|
||||
如果文件不存在，提示用户：
|
||||
> RequirementsDoc.md 不存在，请先创建需求文档。
|
||||
|
||||
如果已存在 `doc/PRD.md`，同时读取作为参考（保持风格一致）。
|
||||
|
||||
## 2. 分析需求文档
|
||||
|
||||
从 RequirementsDoc 中提取以下信息：
|
||||
|
||||
### 2.1 产品定位
|
||||
|
||||
- 产品名称
|
||||
- 目标用户
|
||||
- 核心价值主张
|
||||
- 竞品对比（如有）
|
||||
|
||||
### 2.2 功能需求
|
||||
|
||||
- 功能模块划分
|
||||
- 各模块详细需求
|
||||
- 功能优先级（P0/P1/P2）
|
||||
|
||||
### 2.3 非功能需求
|
||||
|
||||
- 性能要求
|
||||
- 安全要求
|
||||
- 兼容性要求
|
||||
- 可用性要求
|
||||
|
||||
### 2.4 约束条件
|
||||
|
||||
- 技术约束
|
||||
- 业务约束
|
||||
- 时间约束
|
||||
|
||||
## 3. 生成 PRD
|
||||
|
||||
按以下结构生成 PRD 文档：
|
||||
|
||||
```markdown
|
||||
# {产品名称} - 产品需求文档 (PRD)
|
||||
|
||||
## 文档信息
|
||||
|
||||
| 项目 | 内容 |
|
||||
|------|------|
|
||||
| 版本 | v1.0 |
|
||||
| 创建日期 | {YYYY-MM-DD} |
|
||||
| 状态 | 草稿 |
|
||||
|
||||
## 1. 产品概述
|
||||
|
||||
### 1.1 产品背景
|
||||
|
||||
{从 RequirementsDoc 提取，说明产品解决的问题和市场机会}
|
||||
|
||||
### 1.2 产品定位
|
||||
|
||||
{目标用户、核心价值、差异化优势}
|
||||
|
||||
### 1.3 产品目标
|
||||
|
||||
| 目标 | 指标 | 衡量方式 |
|
||||
|------|------|----------|
|
||||
| {业务目标} | {量化指标} | {如何衡量} |
|
||||
|
||||
## 2. 用户故事
|
||||
|
||||
PRD 以用户故事为核心驱动，所有功能需求都应对应到具体的用户故事。
|
||||
|
||||
### 2.1 用户角色定义
|
||||
|
||||
| 角色 | 描述 | 核心目标 | 痛点 |
|
||||
|------|------|----------|------|
|
||||
| {角色1} | {角色描述} | {核心目标} | {当前痛点} |
|
||||
|
||||
### 2.2 用户故事列表
|
||||
|
||||
按优先级排列的用户故事：
|
||||
|
||||
#### P0 - 核心故事
|
||||
|
||||
| ID | 用户故事 | 验收标准 |
|
||||
|----|----------|----------|
|
||||
| US-001 | 作为{角色}，我想要{功能}，以便{价值} | {验收标准} |
|
||||
|
||||
#### P1 - 重要故事
|
||||
|
||||
| ID | 用户故事 | 验收标准 |
|
||||
|----|----------|----------|
|
||||
| US-xxx | 作为{角色}，我想要{功能}，以便{价值} | {验收标准} |
|
||||
|
||||
#### P2 - 次要故事
|
||||
|
||||
| ID | 用户故事 | 验收标准 |
|
||||
|----|----------|----------|
|
||||
| US-xxx | 作为{角色}，我想要{功能}，以便{价值} | {验收标准} |
|
||||
|
||||
### 2.3 用户旅程
|
||||
|
||||
**【必须】使用流程图展示核心用户旅程：**
|
||||
|
||||
```
|
||||
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
|
||||
│ 触发点 │ ──▶ │ 关键步骤 │ ──▶ │ 目标达成 │
|
||||
│ {描述} │ │ {描述} │ │ {描述} │
|
||||
└─────────────┘ └─────────────┘ └─────────────┘
|
||||
│ │ │
|
||||
▼ ▼ ▼
|
||||
{用户感受} {用户感受} {用户感受}
|
||||
```
|
||||
|
||||
{描述用户完成核心任务的完整流程，从触发点到目标达成}
|
||||
|
||||
## 3. 功能需求
|
||||
|
||||
> 功能需求与用户故事的对应关系
|
||||
|
||||
### 3.1 功能架构
|
||||
|
||||
**【必须】使用树状图或模块图展示功能架构：**
|
||||
|
||||
```
|
||||
{产品名称}
|
||||
├── {模块A}
|
||||
│ ├── {功能A1}
|
||||
│ └── {功能A2}
|
||||
├── {模块B}
|
||||
│ ├── {功能B1}
|
||||
│ └── {功能B2}
|
||||
└── {模块C}
|
||||
└── {功能C1}
|
||||
```
|
||||
|
||||
### 3.2 功能详情
|
||||
|
||||
#### 3.2.1 {模块名称}
|
||||
|
||||
| 功能点 | 描述 | 关联用户故事 | 优先级 | 验收标准 |
|
||||
|--------|------|--------------|--------|----------|
|
||||
| {功能1} | {描述} | US-001 | P0 | {标准} |
|
||||
|
||||
{重复以上结构覆盖所有模块}
|
||||
|
||||
## 4. 非功能需求
|
||||
|
||||
### 4.1 性能需求
|
||||
|
||||
| 指标 | 要求 | 说明 |
|
||||
|------|------|------|
|
||||
| {响应时间} | {要求} | {场景说明} |
|
||||
|
||||
### 4.2 安全需求
|
||||
|
||||
{数据安全、访问控制、合规要求}
|
||||
|
||||
### 4.3 兼容性需求
|
||||
|
||||
| 平台/环境 | 支持版本 |
|
||||
|-----------|----------|
|
||||
| {平台} | {版本} |
|
||||
|
||||
### 4.4 可用性需求
|
||||
|
||||
{SLA、故障恢复、监控告警}
|
||||
|
||||
## 5. 数据需求
|
||||
|
||||
### 5.1 数据模型
|
||||
|
||||
**【建议】使用 ER 图或表格展示核心实体关系：**
|
||||
|
||||
```
|
||||
┌──────────┐ ┌──────────┐
|
||||
│ 实体A │ 1───n │ 实体B │
|
||||
├──────────┤ ├──────────┤
|
||||
│ 字段1 │ │ 字段1 │
|
||||
│ 字段2 │ │ 字段2 │
|
||||
└──────────┘ └──────────┘
|
||||
```
|
||||
|
||||
### 5.2 数据规范
|
||||
|
||||
| 字段 | 类型 | 说明 | 校验规则 |
|
||||
|------|------|------|----------|
|
||||
| {字段名} | {类型} | {说明} | {规则} |
|
||||
|
||||
## 6. 接口需求
|
||||
|
||||
### 6.1 外部接口
|
||||
|
||||
| 接口 | 用途 | 提供方 |
|
||||
|------|------|--------|
|
||||
| {接口名} | {用途} | {第三方} |
|
||||
|
||||
### 6.2 内部接口
|
||||
|
||||
{模块间接口规范}
|
||||
|
||||
## 7. 约束与依赖
|
||||
|
||||
### 7.1 技术约束
|
||||
|
||||
| 约束 | 说明 | 影响 |
|
||||
|------|------|------|
|
||||
| {约束} | {说明} | {影响范围} |
|
||||
|
||||
### 7.2 业务约束
|
||||
|
||||
{法规、政策、合同限制}
|
||||
|
||||
### 7.3 外部依赖
|
||||
|
||||
{第三方服务、团队依赖}
|
||||
|
||||
## 8. 里程碑规划
|
||||
|
||||
**【建议】使用时间线展示里程碑：**
|
||||
|
||||
```
|
||||
Phase 1 Phase 2 Phase 3
|
||||
│ │ │
|
||||
▼ ▼ ▼
|
||||
┌──────┐ ┌──────┐ ┌──────┐
|
||||
│ MVP │ ────▶ │ v1.1 │ ────▶ │ v2.0 │
|
||||
└──────┘ └──────┘ └──────┘
|
||||
{日期} {日期} {日期}
|
||||
```
|
||||
|
||||
| 阶段 | 目标 | 交付物 |
|
||||
|------|------|--------|
|
||||
| {阶段1} | {目标} | {交付物} |
|
||||
|
||||
## 9. 风险评估
|
||||
|
||||
| 风险 | 可能性 | 影响 | 应对措施 |
|
||||
|------|--------|------|----------|
|
||||
| {风险1} | 高/中/低 | 高/中/低 | {措施} |
|
||||
|
||||
## 附录
|
||||
|
||||
### A. 术语表
|
||||
|
||||
| 术语 | 定义 |
|
||||
|------|------|
|
||||
| {术语} | {定义} |
|
||||
|
||||
### B. 参考文档
|
||||
|
||||
- RequirementsDoc.md
|
||||
```
|
||||
|
||||
## 4. 保存文档
|
||||
|
||||
将生成的 PRD 保存到 `doc/PRD.md`。
|
||||
|
||||
如果文件已存在，覆盖原文件（历史版本通过 git 追溯）。
|
||||
|
||||
## 5. 输出摘要
|
||||
|
||||
向用户展示生成摘要：
|
||||
|
||||
- PRD 文件路径
|
||||
- 包含的功能模块数量
|
||||
- 主要章节概览
|
||||
- 建议的下一步操作（运行 `/rp` 评审）
|
||||
|
||||
---
|
||||
|
||||
## 可视化输出要求
|
||||
|
||||
PRD 作为「价值主张」文档，需要便于业务沟通理解，**必须包含**：
|
||||
|
||||
| 章节 | 可视化形式 | 必要性 |
|
||||
|------|------------|--------|
|
||||
| 2.3 用户旅程 | 流程图（ASCII） | **必须** |
|
||||
| 3.1 功能架构 | 树状图/模块图 | **必须** |
|
||||
| 5.1 数据模型 | ER 图 | 建议 |
|
||||
| 8. 里程碑规划 | 时间线 | 建议 |
|
||||
|
||||
## 注意事项
|
||||
|
||||
- PRD 使用**业务语言**，避免过多技术术语
|
||||
- PRD 内容必须完全来源于 RequirementsDoc，不要臆造需求
|
||||
- 如果 RequirementsDoc 信息不完整，在对应章节标注"待补充"
|
||||
- 保持语言风格与现有文档一致
|
||||
- 优先级标注遵循 P0 > P1 > P2 规则
|
||||
- 验收标准要具体可测试
|
||||
|
||||
## 质量检查
|
||||
|
||||
生成 PRD 后，自查以下项目：
|
||||
|
||||
- [ ] 所有用户故事都有唯一 ID（US-xxx）
|
||||
- [ ] 所有用户故事都符合格式：作为{角色}，我想要{功能}，以便{价值}
|
||||
- [ ] 所有功能点都关联到用户故事
|
||||
- [ ] 所有功能点都有明确的优先级
|
||||
- [ ] 所有功能点都有验收标准
|
||||
- [ ] **用户旅程有流程图**
|
||||
- [ ] **功能架构有模块图**
|
||||
- [ ] 非功能需求有量化指标
|
||||
- [ ] 无遗漏 RequirementsDoc 中的重要需求
|
||||
- [ ] 文档结构完整，无空章节（或标注"待补充"）
|
||||
@@ -0,0 +1,135 @@
|
||||
---
|
||||
name: writeTest
|
||||
description: 从上游文档生成 tdd.md，创建覆盖所有功能的测试用例文档。
|
||||
---
|
||||
|
||||
# Write Test Cases
|
||||
|
||||
> **文档定位**：tdd.md 是测试驱动开发的核心文档，基于 PRD 和功能文档生成结构化测试用例，确保所有功能点有对应的测试覆盖。
|
||||
|
||||
当用户调用 `/writeTest` 时，执行以下步骤：
|
||||
|
||||
## 1. 读取源文档
|
||||
|
||||
读取以下文件：
|
||||
|
||||
1. `doc/PRD.md` - 必须存在（功能需求和验收标准的主要来源）
|
||||
2. `doc/FeatureSummary.md` - 必须存在（功能模块全貌）
|
||||
3. `doc/DevelopmentPlan.md` - 必须存在（技术方案参考）
|
||||
4. `doc/tasks.md` - 可选（任务粒度参考）
|
||||
5. `doc/UIDesign.md` - 可选（界面交互测试参考）
|
||||
|
||||
如果必要文件不存在，提示用户：
|
||||
> 缺少必要文档，请先确保 PRD.md、DevelopmentPlan.md 和 FeatureSummary.md 存在。
|
||||
|
||||
如果已存在 `doc/tdd.md`，同时读取作为参考（保持风格一致）。
|
||||
|
||||
## 2. 分析测试需求
|
||||
|
||||
从上游文档中提取以下信息：
|
||||
|
||||
### 2.1 功能测试点
|
||||
|
||||
- 从 PRD 的用户故事和验收标准提取功能测试点
|
||||
- 从 FeatureSummary 的功能模块提取模块级测试点
|
||||
|
||||
### 2.2 边界与异常场景
|
||||
|
||||
- 分析各功能的边界条件
|
||||
- 识别异常输入和错误处理场景
|
||||
|
||||
### 2.3 非功能测试点
|
||||
|
||||
- 从 PRD 非功能需求提取性能、安全、兼容性测试点
|
||||
|
||||
## 3. 生成 tdd.md
|
||||
|
||||
按以下结构生成文档：
|
||||
|
||||
```markdown
|
||||
# {产品名称} - 测试用例文档 (TDD)
|
||||
|
||||
## 文档信息
|
||||
|
||||
| 项目 | 内容 |
|
||||
|------|------|
|
||||
| 版本 | v1.0 |
|
||||
| 创建日期 | {YYYY-MM-DD} |
|
||||
| 来源文档 | PRD.md, FeatureSummary.md |
|
||||
|
||||
## 1. 测试总览
|
||||
|
||||
| 统计项 | 数量 |
|
||||
|--------|------|
|
||||
| 总用例数 | X |
|
||||
| 功能测试 | X |
|
||||
| 边界测试 | X |
|
||||
| 异常测试 | X |
|
||||
| 非功能测试 | X |
|
||||
|
||||
## 2. {模块名称} 测试
|
||||
|
||||
### 2.1 {功能名称}
|
||||
|
||||
| ID | 测试用例 | 前置条件 | 测试步骤 | 预期结果 | 优先级 | 关联用户故事 |
|
||||
|----|----------|----------|----------|----------|--------|--------------|
|
||||
| TC-001 | {用例名} | {前置条件} | {步骤} | {预期结果} | P0 | US-001 |
|
||||
|
||||
{重复以上结构覆盖所有模块和功能}
|
||||
|
||||
## N. 非功能测试
|
||||
|
||||
### N.1 性能测试
|
||||
|
||||
| ID | 测试用例 | 测试条件 | 预期指标 | 优先级 |
|
||||
|----|----------|----------|----------|--------|
|
||||
| TC-xxx | {用例名} | {条件} | {指标} | P0/P1 |
|
||||
|
||||
### N.2 安全测试
|
||||
|
||||
| ID | 测试用例 | 测试方法 | 预期结果 | 优先级 |
|
||||
|----|----------|----------|----------|--------|
|
||||
| TC-xxx | {用例名} | {方法} | {结果} | P0/P1 |
|
||||
|
||||
## 附录：测试覆盖矩阵
|
||||
|
||||
| 用户故事 | 功能测试 | 边界测试 | 异常测试 | 覆盖状态 |
|
||||
|----------|----------|----------|----------|----------|
|
||||
| US-001 | TC-001 | TC-xxx | TC-xxx | ✅ |
|
||||
```
|
||||
|
||||
## 4. 保存文档
|
||||
|
||||
将生成的测试用例文档保存到 `doc/tdd.md`。
|
||||
|
||||
如果文件已存在，覆盖原文件（历史版本通过 git 追溯）。
|
||||
|
||||
## 5. 输出摘要
|
||||
|
||||
向用户展示生成摘要：
|
||||
|
||||
- tdd.md 文件路径
|
||||
- 测试用例总数
|
||||
- 各模块用例分布
|
||||
- 测试覆盖率概览
|
||||
- 建议的下一步操作（运行‘wt’生成开发任务文档）
|
||||
|
||||
---
|
||||
|
||||
## 注意事项
|
||||
|
||||
- 测试用例必须覆盖 PRD 中所有用户故事的验收标准
|
||||
- 用例 ID 必须唯一（TC-001, TC-002...）
|
||||
- 每个用例必须有明确的预期结果
|
||||
- 优先级与对应功能优先级一致（P0 功能 → P0 测试）
|
||||
- 关注边界条件和异常路径，不仅仅是正向流程
|
||||
- 测试步骤要具体可执行，无歧义
|
||||
|
||||
## 与其他 Skill 的关系
|
||||
|
||||
| 场景 | 使用方式 |
|
||||
|------|----------|
|
||||
| 准备上游文档 | `/wp` `/wf` `/wd` `/wu` `/wt` |
|
||||
| 生成测试用例（本 Skill） | `/writeTest` |
|
||||
| 执行开发（含测试） | `/go` |
|
||||
| 迭代后更新测试 | `/iter` 后重新运行 `/writeTest` |
|
||||
@@ -0,0 +1,129 @@
|
||||
---
|
||||
name: wt
|
||||
description: 从上游文档生成 tasks.md，创建可直接执行的任务列表。
|
||||
---
|
||||
|
||||
# Write Tasks
|
||||
|
||||
当用户调用 `/wt` 时，执行以下步骤：
|
||||
|
||||
## 1. 读取源文档
|
||||
|
||||
读取以下文件：
|
||||
|
||||
1. `doc/RequirementsDoc.md` - 建议存在
|
||||
2. `doc/PRD.md` - 必须存在
|
||||
3. `doc/FeatureSummary.md` - 必须存在
|
||||
4. `doc/DevelopmentPlan.md` - 必须存在
|
||||
5. `doc/UIDesign.md` - 必须存在
|
||||
6. `doc/tdd.md` - 建议存在
|
||||
|
||||
如果文件不存在，提示用户：
|
||||
> 缺少上游文档，请确保所有上游文档存在。
|
||||
|
||||
如果已存在 `doc/tasks.md`，同时读取作为参考（保持风格一致）。
|
||||
|
||||
## 2. 分析任务需求
|
||||
|
||||
从上游文档中提取以下信息：
|
||||
|
||||
### 2.1 开发任务
|
||||
|
||||
- 从 DevelopmentPlan 获取开发阶段和任务
|
||||
- 从 UIDesign 获取页面实现任务
|
||||
|
||||
### 2.2 任务依赖
|
||||
|
||||
- 分析任务间的依赖关系
|
||||
- 确定任务执行顺序
|
||||
|
||||
### 2.3 验收标准
|
||||
|
||||
- 从 PRD 获取功能验收标准
|
||||
- 转化为任务级别的完成标准
|
||||
|
||||
## 3. 生成 Tasks
|
||||
|
||||
按以下结构生成文档：
|
||||
|
||||
```markdown
|
||||
# {产品名称} - 任务列表
|
||||
|
||||
## 文档信息
|
||||
|
||||
| 项目 | 内容 |
|
||||
|------|------|
|
||||
| 版本 | v1.0 |
|
||||
| 创建日期 | {YYYY-MM-DD} |
|
||||
| 来源文档 | UIDesign.md, DevelopmentPlan.md |
|
||||
|
||||
## 1. 任务总览
|
||||
|
||||
| 统计项 | 数量 |
|
||||
|--------|------|
|
||||
| 总任务数 | X |
|
||||
| P0 任务 | X |
|
||||
| P1 任务 | X |
|
||||
| P2 任务 | X |
|
||||
|
||||
## 2. Phase 1 任务
|
||||
|
||||
### 2.1 {模块/功能名}
|
||||
|
||||
| ID | 任务 | 描述 | 优先级 | 依赖 | 验收标准 |
|
||||
|----|------|------|--------|------|----------|
|
||||
| T-001 | {任务名} | {描述} | P0 | - | {标准} |
|
||||
| T-002 | {任务名} | {描述} | P0 | T-001 | {标准} |
|
||||
|
||||
{重复以上结构覆盖所有模块}
|
||||
|
||||
## 3. Phase 2 任务
|
||||
|
||||
{同上结构}
|
||||
|
||||
## 4. Phase N 任务
|
||||
|
||||
{同上结构}
|
||||
|
||||
## 5. 任务依赖图
|
||||
|
||||
```
|
||||
T-001 (基础设施)
|
||||
├── T-002 (功能A)
|
||||
│ └── T-005 (功能A优化)
|
||||
└── T-003 (功能B)
|
||||
└── T-004 (功能B扩展)
|
||||
```
|
||||
|
||||
## 6. 执行检查清单
|
||||
|
||||
- [ ] T-001: {任务名}
|
||||
- [ ] T-002: {任务名}
|
||||
{所有任务的检查清单}
|
||||
```
|
||||
|
||||
## 4. 保存文档
|
||||
|
||||
将生成的 tasks 保存到 `doc/tasks.md`。
|
||||
|
||||
如果文件已存在，覆盖原文件（历史版本通过 git 追溯）。
|
||||
|
||||
## 5. 输出摘要
|
||||
|
||||
向用户展示生成摘要：
|
||||
|
||||
- tasks 文件路径
|
||||
- 任务总数
|
||||
- 各阶段任务分布
|
||||
- 建议的下一步操作（运行 `/rt` 评审）
|
||||
|
||||
---
|
||||
|
||||
## 注意事项
|
||||
|
||||
- 任务必须覆盖 DevelopmentPlan 和 UIDesign 所有内容
|
||||
- 任务 ID 必须唯一（T-001, T-002...）
|
||||
- 每个任务必须有明确的验收标准
|
||||
- 任务粒度要适中，可在合理时间内完成
|
||||
- 依赖关系要明确，避免循环依赖
|
||||
- 任务应可直接执行，无歧义
|
||||
@@ -0,0 +1,352 @@
|
||||
---
|
||||
name: wu
|
||||
description: 从上游文档生成 UIDesign.md，覆盖所有用户界面设计。
|
||||
---
|
||||
|
||||
# Write UIDesign
|
||||
|
||||
> **文档定位**：UIDesign 是「界面蓝图」文档，用 ASCII 原型图精确传达页面布局、组件结构、交互流程，是前端开发的直接参考。
|
||||
|
||||
当用户调用 `/wu` 时，执行以下步骤：
|
||||
|
||||
## 1. 读取源文档
|
||||
|
||||
读取以下文件：
|
||||
|
||||
1. `doc/RequirementsDoc.md` - 必须存在
|
||||
2. `doc/PRD.md` - 必须存在
|
||||
3. `doc/FeatureSummary.md` - 必须存在
|
||||
4. `doc/DevelopmentPlan.md` - 必须存在
|
||||
|
||||
如果文件不存在，提示用户：
|
||||
> 缺少上游文档，请确保所有上游文档存在。
|
||||
|
||||
如果已存在 `doc/UIDesign.md`，同时读取作为参考（保持风格一致）。
|
||||
|
||||
## 2. 分析 UI 需求
|
||||
|
||||
从上游文档中提取以下信息：
|
||||
|
||||
### 2.1 页面需求
|
||||
|
||||
- 从 PRD 用户旅程分析所需页面
|
||||
- 从 FeatureSummary 获取功能对应的界面
|
||||
- 从 DevelopmentPlan 获取技术实现约束
|
||||
|
||||
### 2.2 用户流程
|
||||
|
||||
- 主要用户旅程
|
||||
- 页面跳转关系
|
||||
- 交互流程
|
||||
|
||||
## 3. 生成 UIDesign
|
||||
|
||||
按以下结构生成文档：
|
||||
|
||||
```markdown
|
||||
# {产品名称} - UI 设计文档
|
||||
|
||||
## 文档信息
|
||||
|
||||
| 项目 | 内容 |
|
||||
|------|------|
|
||||
| 版本 | v1.0 |
|
||||
| 创建日期 | {YYYY-MM-DD} |
|
||||
| 来源文档 | DevelopmentPlan.md |
|
||||
|
||||
## 1. 设计概述
|
||||
|
||||
### 1.1 设计原则
|
||||
|
||||
{UI 设计原则和规范}
|
||||
|
||||
### 1.2 页面总览
|
||||
|
||||
| 页面ID | 页面名称 | 描述 | 对应功能 | 优先级 |
|
||||
|--------|----------|------|----------|--------|
|
||||
| P-001 | {页面名} | {描述} | F-001 | P0 |
|
||||
|
||||
### 1.3 页面导航图
|
||||
|
||||
**【必须】使用导航图展示页面跳转关系：**
|
||||
|
||||
```
|
||||
┌─────────────┐
|
||||
│ 首页 │
|
||||
│ P-001 │
|
||||
└──────┬──────┘
|
||||
│
|
||||
┌───────────────┼───────────────┐
|
||||
│ │ │
|
||||
▼ ▼ ▼
|
||||
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
|
||||
│ 功能A页 │ │ 功能B页 │ │ 设置页 │
|
||||
│ P-002 │ │ P-003 │ │ P-004 │
|
||||
└──────┬──────┘ └─────────────┘ └─────────────┘
|
||||
│
|
||||
▼
|
||||
┌─────────────┐
|
||||
│ 详情页 │
|
||||
│ P-005 │
|
||||
└─────────────┘
|
||||
```
|
||||
|
||||
## 2. 页面设计
|
||||
|
||||
### 2.1 P-001: {页面名称}
|
||||
|
||||
**页面信息**
|
||||
|
||||
| 属性 | 值 |
|
||||
|------|-----|
|
||||
| 页面ID | P-001 |
|
||||
| 对应功能 | F-001, F-002 |
|
||||
| 入口 | {从哪些页面可进入} |
|
||||
| 出口 | {可跳转到哪些页面} |
|
||||
|
||||
**【必须】页面布局 - ASCII 原型图**
|
||||
|
||||
```
|
||||
┌────────────────────────────────────────────────────────┐
|
||||
│ ┌─────────────────────────────────────────────────┐ │
|
||||
│ │ Header │ │
|
||||
│ │ [Logo] [Nav Item] [Nav Item] [用户]│ │
|
||||
│ └─────────────────────────────────────────────────┘ │
|
||||
├────────────────────────────────────────────────────────┤
|
||||
│ │
|
||||
│ ┌──────────────────┐ ┌───────────────────────────┐ │
|
||||
│ │ │ │ │ │
|
||||
│ │ Sidebar │ │ Main Content │ │
|
||||
│ │ │ │ │ │
|
||||
│ │ • Menu Item 1 │ │ ┌─────────────────────┐ │ │
|
||||
│ │ • Menu Item 2 │ │ │ Card 1 │ │ │
|
||||
│ │ • Menu Item 3 │ │ │ [Title] │ │ │
|
||||
│ │ │ │ │ [Description...] │ │ │
|
||||
│ │ │ │ │ [Action Button] │ │ │
|
||||
│ │ │ │ └─────────────────────┘ │ │
|
||||
│ │ │ │ │ │
|
||||
│ │ │ │ ┌─────────────────────┐ │ │
|
||||
│ │ │ │ │ Card 2 │ │ │
|
||||
│ │ │ │ └─────────────────────┘ │ │
|
||||
│ │ │ │ │ │
|
||||
│ └──────────────────┘ └───────────────────────────┘ │
|
||||
│ │
|
||||
├────────────────────────────────────────────────────────┤
|
||||
│ ┌─────────────────────────────────────────────────┐ │
|
||||
│ │ Footer │ │
|
||||
│ └─────────────────────────────────────────────────┘ │
|
||||
└────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
**组件清单**
|
||||
|
||||
| 组件ID | 组件名称 | 类型 | 说明 | 交互 |
|
||||
|--------|----------|------|------|------|
|
||||
| C-001 | Header | 导航栏 | 顶部固定 | 点击 Logo 回首页 |
|
||||
| C-002 | Sidebar | 侧边栏 | 左侧固定 | 点击菜单切换内容 |
|
||||
| C-003 | Card | 卡片 | 内容展示 | 点击进入详情 |
|
||||
|
||||
**交互说明**
|
||||
|
||||
| 触发 | 动作 | 结果 |
|
||||
|------|------|------|
|
||||
| 点击 Card | 跳转 | 进入详情页 P-005 |
|
||||
| 点击 Menu Item | 切换 | 更新 Main Content |
|
||||
|
||||
**页面状态**
|
||||
|
||||
| 状态 | 说明 | 展示 |
|
||||
|------|------|------|
|
||||
| 默认 | 正常加载完成 | 显示数据列表 |
|
||||
| 加载中 | 数据请求中 | 骨架屏/Loading |
|
||||
| 空状态 | 无数据 | 空状态插图+引导文案 |
|
||||
| 错误 | 请求失败 | 错误提示+重试按钮 |
|
||||
|
||||
**空状态原型**
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────┐
|
||||
│ │
|
||||
│ ┌─────────────┐ │
|
||||
│ │ (空图标) │ │
|
||||
│ └─────────────┘ │
|
||||
│ │
|
||||
│ 暂无数据 │
|
||||
│ │
|
||||
│ [去添加数据] │
|
||||
│ │
|
||||
└─────────────────────────────────────┘
|
||||
```
|
||||
|
||||
{重复以上结构覆盖所有页面}
|
||||
|
||||
## 3. 用户流程
|
||||
|
||||
### 3.1 {流程名称}
|
||||
|
||||
**【必须】使用流程图展示用户操作流程：**
|
||||
|
||||
```
|
||||
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
|
||||
│ Step 1 │ ──▶ │ Step 2 │ ──▶ │ Step 3 │ ──▶ │ 完成 │
|
||||
│ {操作} │ │ {操作} │ │ {操作} │ │ │
|
||||
│ P-001 │ │ P-002 │ │ P-003 │ │ P-004 │
|
||||
└─────────┘ └────┬────┘ └─────────┘ └─────────┘
|
||||
│
|
||||
▼ 取消
|
||||
┌─────────┐
|
||||
│ 返回 │
|
||||
│ P-001 │
|
||||
└─────────┘
|
||||
```
|
||||
|
||||
**流程步骤**
|
||||
|
||||
| 步骤 | 页面 | 用户操作 | 系统响应 |
|
||||
|------|------|----------|----------|
|
||||
| 1 | P-001 | {操作} | {响应} |
|
||||
| 2 | P-002 | {操作} | {响应} |
|
||||
|
||||
## 4. 组件规范
|
||||
|
||||
### 4.1 基础组件
|
||||
|
||||
**Button 按钮**
|
||||
|
||||
```
|
||||
主按钮: ┌──────────────┐
|
||||
│ 确认提交 │ (填充色背景)
|
||||
└──────────────┘
|
||||
|
||||
次按钮: ┌──────────────┐
|
||||
│ 取消 │ (边框样式)
|
||||
└──────────────┘
|
||||
|
||||
禁用态: ┌──────────────┐
|
||||
│ 不可点击 │ (灰色)
|
||||
└──────────────┘
|
||||
```
|
||||
|
||||
**Input 输入框**
|
||||
|
||||
```
|
||||
默认态: ┌────────────────────────┐
|
||||
│ 请输入... │
|
||||
└────────────────────────┘
|
||||
|
||||
聚焦态: ┌────────────────────────┐
|
||||
│ 输入内容 │ (高亮边框)
|
||||
└────────────────────────┘
|
||||
|
||||
错误态: ┌────────────────────────┐
|
||||
│ 错误输入 │ (红色边框)
|
||||
└────────────────────────┘
|
||||
⚠ 错误提示信息
|
||||
```
|
||||
|
||||
### 4.2 业务组件
|
||||
|
||||
{项目特有的业务组件}
|
||||
|
||||
## 5. 设计规范
|
||||
|
||||
### 5.1 色彩规范
|
||||
|
||||
| 用途 | 色值 | 示例 |
|
||||
|------|------|------|
|
||||
| 主色 | #1890FF | 主按钮、链接 |
|
||||
| 成功 | #52C41A | 成功提示 |
|
||||
| 警告 | #FAAD14 | 警告提示 |
|
||||
| 错误 | #FF4D4F | 错误提示 |
|
||||
| 文字主色 | #262626 | 标题 |
|
||||
| 文字次色 | #8C8C8C | 描述 |
|
||||
|
||||
### 5.2 字体规范
|
||||
|
||||
| 用途 | 字号 | 字重 |
|
||||
|------|------|------|
|
||||
| 大标题 | 24px | Bold |
|
||||
| 标题 | 18px | Medium |
|
||||
| 正文 | 14px | Regular |
|
||||
| 辅助文字 | 12px | Regular |
|
||||
|
||||
### 5.3 间距规范
|
||||
|
||||
| 间距 | 值 | 用途 |
|
||||
|------|-----|------|
|
||||
| xs | 4px | 紧凑间距 |
|
||||
| sm | 8px | 小间距 |
|
||||
| md | 16px | 标准间距 |
|
||||
| lg | 24px | 大间距 |
|
||||
| xl | 32px | 特大间距 |
|
||||
|
||||
### 5.4 响应式断点
|
||||
|
||||
| 断点 | 宽度 | 布局说明 |
|
||||
|------|------|----------|
|
||||
| Mobile | < 768px | 单栏布局 |
|
||||
| Tablet | 768px - 1024px | 双栏布局 |
|
||||
| Desktop | > 1024px | 多栏布局 |
|
||||
```
|
||||
|
||||
## 4. 保存文档
|
||||
|
||||
将生成的 UIDesign 保存到 `doc/UIDesign.md`。
|
||||
|
||||
如果文件已存在，覆盖原文件（历史版本通过 git 追溯）。
|
||||
|
||||
## 5. 输出摘要
|
||||
|
||||
向用户展示生成摘要：
|
||||
|
||||
- UIDesign 文件路径
|
||||
- 页面数量
|
||||
- 用户流程数量
|
||||
- 建议的下一步操作（运行 `/ru` 评审）
|
||||
|
||||
---
|
||||
|
||||
## 可视化输出要求
|
||||
|
||||
UIDesign 作为「界面蓝图」文档，**必须大量使用 ASCII 原型图**：
|
||||
|
||||
| 章节 | 可视化形式 | 必要性 |
|
||||
|------|------------|--------|
|
||||
| 1.3 页面导航图 | 导航关系图（ASCII） | **必须** |
|
||||
| 2.x 页面布局 | **ASCII 原型图** | **必须（每页）** |
|
||||
| 2.x 空状态 | ASCII 原型图 | 建议 |
|
||||
| 3.x 用户流程 | 流程图（ASCII） | **必须** |
|
||||
| 4.x 组件规范 | 组件示意图 | **必须** |
|
||||
|
||||
**ASCII 原型图要求**：
|
||||
|
||||
- 每个页面**必须**有完整的布局原型图
|
||||
- 原型图要体现：页面结构、组件位置、内容区域
|
||||
- 使用 `┌ ┐ └ ┘ ─ │ ├ ┤ ┬ ┴ ┼` 等字符绘制边框
|
||||
- 使用 `[ ]` 表示按钮
|
||||
- 使用 `▼ ▶ ◀ ▲` 表示方向/展开
|
||||
- 关键交互点要标注
|
||||
|
||||
## 注意事项
|
||||
|
||||
- UI 设计必须覆盖 DevelopmentPlan 所有功能模块
|
||||
- **每个页面必须有 ASCII 原型图**
|
||||
- 页面设计要考虑各种状态（默认、加载、空、错误）
|
||||
- 交互说明要清晰具体
|
||||
- 设计规范要统一一致
|
||||
- 页面 ID 格式：P-xxx
|
||||
- 组件 ID 格式：C-xxx
|
||||
|
||||
## 质量检查
|
||||
|
||||
生成 UIDesign 后，自查以下项目：
|
||||
|
||||
- [ ] 覆盖 DevelopmentPlan 所有功能模块
|
||||
- [ ] **页面导航图清晰展示页面关系**
|
||||
- [ ] **每个页面都有 ASCII 原型图**
|
||||
- [ ] **原型图展示了完整的页面结构**
|
||||
- [ ] **用户流程有流程图**
|
||||
- [ ] 每个页面都有状态说明
|
||||
- [ ] 组件清单完整
|
||||
- [ ] 交互说明清晰
|
||||
- [ ] 设计规范统一
|
||||
Reference in New Issue
Block a user