From 423c6079b1b15e09e37e3782d2f5c8aa483a4c15 Mon Sep 17 00:00:00 2001 From: zfc Date: Mon, 9 Mar 2026 21:27:05 +0800 Subject: [PATCH] feat(skills): add codex compatibility --- .codex/skills/AGENTS.md.template | 42 ++++ .codex/skills/RequirementsDoc.md | 1 + .codex/skills/changelog/SKILL.md | 109 ++++++++++ .codex/skills/deploy/SKILL.md | 316 +++++++++++++++++++++++++++ .codex/skills/go/SKILL.md | 324 ++++++++++++++++++++++++++++ .codex/skills/iter/SKILL.md | 210 ++++++++++++++++++ .codex/skills/md/SKILL.md | 112 ++++++++++ .codex/skills/mf/SKILL.md | 111 ++++++++++ .codex/skills/mp/SKILL.md | 144 +++++++++++++ .codex/skills/mr/SKILL.md | 95 +++++++++ .codex/skills/mt/SKILL.md | 132 ++++++++++++ .codex/skills/mu/SKILL.md | 114 ++++++++++ .codex/skills/muse.svg | 93 ++++++++ .codex/skills/rd/SKILL.md | 101 +++++++++ .codex/skills/rf/SKILL.md | 96 +++++++++ .codex/skills/rp/SKILL.md | 177 ++++++++++++++++ .codex/skills/rr/SKILL.md | 111 ++++++++++ .codex/skills/rt/SKILL.md | 115 ++++++++++ .codex/skills/ru/SKILL.md | 105 +++++++++ .codex/skills/up/SKILL.md | 78 +++++++ .codex/skills/wd/SKILL.md | 323 ++++++++++++++++++++++++++++ .codex/skills/wf/SKILL.md | 234 ++++++++++++++++++++ .codex/skills/wp/SKILL.md | 318 ++++++++++++++++++++++++++++ .codex/skills/wt/SKILL.md | 128 +++++++++++ .codex/skills/wu/SKILL.md | 352 +++++++++++++++++++++++++++++++ .gitignore | 5 +- AGENTS.md | 40 ++++ AGENTS.md.template | 42 ++++ README.md | 143 ++++++++----- install.sh | 77 ++++++- 30 files changed, 4195 insertions(+), 53 deletions(-) create mode 100644 .codex/skills/AGENTS.md.template create mode 100644 .codex/skills/RequirementsDoc.md create mode 100644 .codex/skills/changelog/SKILL.md create mode 100644 .codex/skills/deploy/SKILL.md create mode 100644 .codex/skills/go/SKILL.md create mode 100644 .codex/skills/iter/SKILL.md create mode 100644 .codex/skills/md/SKILL.md create mode 100644 .codex/skills/mf/SKILL.md create mode 100644 .codex/skills/mp/SKILL.md create mode 100644 .codex/skills/mr/SKILL.md create mode 100644 .codex/skills/mt/SKILL.md create mode 100644 .codex/skills/mu/SKILL.md create mode 100644 .codex/skills/muse.svg create mode 100644 .codex/skills/rd/SKILL.md create mode 100644 .codex/skills/rf/SKILL.md create mode 100644 .codex/skills/rp/SKILL.md create mode 100644 .codex/skills/rr/SKILL.md create mode 100644 .codex/skills/rt/SKILL.md create mode 100644 .codex/skills/ru/SKILL.md create mode 100644 .codex/skills/up/SKILL.md create mode 100644 .codex/skills/wd/SKILL.md create mode 100644 .codex/skills/wf/SKILL.md create mode 100644 .codex/skills/wp/SKILL.md create mode 100644 .codex/skills/wt/SKILL.md create mode 100644 .codex/skills/wu/SKILL.md create mode 100644 AGENTS.md create mode 100644 AGENTS.md.template diff --git a/.codex/skills/AGENTS.md.template b/.codex/skills/AGENTS.md.template new file mode 100644 index 0000000..147d4c9 --- /dev/null +++ b/.codex/skills/AGENTS.md.template @@ -0,0 +1,42 @@ +# AGENTS.md + +把这个文件放在项目根目录，用来把已安装的 Codex skills 注册给 Codex。项目级约束可以追加在文末的 `Project notes` 一节。 + +## Skills + +### Available skills + +- `rr`: 评审 RequirementsDoc.md，检查需求文档的完整性、清晰度和可执行性，输出结构化评审报告。 (file: `./.codex/skills/rr/SKILL.md`) +- `rp`: 评审 PRD.md，对比 RequirementsDoc 检查一致性，输出结构化评审报告。 (file: `./.codex/skills/rp/SKILL.md`) +- `rf`: 评审 FeatureSummary.md，对比 PRD 检查一致性，输出结构化评审报告。 (file: `./.codex/skills/rf/SKILL.md`) +- `rd`: 评审 DevelopmentPlan.md，检查技术可行性和与上游文档一致性，输出结构化评审报告。 (file: `./.codex/skills/rd/SKILL.md`) +- `ru`: 评审 UIDesign.md，对比 DevelopmentPlan 检查设计一致性，输出结构化评审报告。 (file: `./.codex/skills/ru/SKILL.md`) +- `rt`: 评审 tasks.md，检查任务完整性和与上游文档一致性，输出结构化评审报告。 (file: `./.codex/skills/rt/SKILL.md`) +- `wp`: 从 RequirementsDoc.md 生成 PRD.md，将需求文档转化为结构化的产品需求文档。 (file: `./.codex/skills/wp/SKILL.md`) +- `wf`: 从 RequirementsDoc.md 和 PRD.md 生成 FeatureSummary.md，提供功能全貌概览。 (file: `./.codex/skills/wf/SKILL.md`) +- `wd`: 从上游文档生成 DevelopmentPlan.md，包含技术方案和开发排期。 (file: `./.codex/skills/wd/SKILL.md`) +- `wu`: 从上游文档生成 UIDesign.md，覆盖所有用户界面设计。 (file: `./.codex/skills/wu/SKILL.md`) +- `wt`: 从上游文档生成 tasks.md，创建可直接执行的任务列表。 (file: `./.codex/skills/wt/SKILL.md`) +- `mr`: 增量修改 RequirementsDoc.md，根据用户指令在现有内容基础上更新需求文档。 (file: `./.codex/skills/mr/SKILL.md`) +- `mp`: 增量修改 PRD.md，根据用户指令在现有内容基础上更新产品需求文档。 (file: `./.codex/skills/mp/SKILL.md`) +- `mf`: 增量修改 FeatureSummary.md，根据用户指令在现有内容基础上更新功能摘要。 (file: `./.codex/skills/mf/SKILL.md`) +- `md`: 增量修改 DevelopmentPlan.md，根据用户指令在现有内容基础上更新开发计划。 (file: `./.codex/skills/md/SKILL.md`) +- `mu`: 增量修改 UIDesign.md，根据用户指令在现有内容基础上更新 UI 设计文档。 (file: `./.codex/skills/mu/SKILL.md`) +- `mt`: 增量修改 tasks.md，根据用户指令在现有内容基础上更新任务列表。 (file: `./.codex/skills/mt/SKILL.md`) +- `go`: 终极执行按钮，激进模式一口气完成开发任务，兼容 0->1 和 1->100 场景。 (file: `./.codex/skills/go/SKILL.md`) +- `iter`: 迭代变更入口，调研问题后更新 PRD.md 和 tasks.md，支持 Bug 修复、功能迭代、技术重构。 (file: `./.codex/skills/iter/SKILL.md`) +- `update`: 收集用户反馈并更新最近使用的 skill。别名：`up`。 (file: `./.codex/skills/up/SKILL.md`) +- `deploy`: Drone CI + 服务器 CD 全流程引导：从基础设施检查到生成配置文件到验证部署，交互式完成。 (file: `./.codex/skills/deploy/SKILL.md`) +- `changelog`: 一键发版：生成更新日志 → commit → 打 tag，全流程自动化。 (file: `./.codex/skills/changelog/SKILL.md`) + +### How to use skills + +- Discovery: 以上列表就是当前项目注册给 Codex 的 skills。 +- Trigger rules: 如果用户显式提到 skill 名称（例如 `$rr`、`rr skill`、`用 rr 评审`），或任务明显匹配 skill 描述，优先使用对应 skill。 +- Codex usage: 在 Codex 中优先使用 `$skill-name` 或自然语言；skill 文档里出现的 `/rr`、`/go` 等 slash command 只是 Claude Code 的兼容写法。 +- Missing/blocked: 如果某个 skill 文件不存在或无法读取，简短说明并回退到普通实现方式。 +- Context hygiene: 只按需打开 `SKILL.md`，不要一次性加载整个 skill 仓库。 + +## Project notes + +- 在这里补充项目特定约束，例如技术栈、测试命令、代码风格、提交流程。 diff --git a/.codex/skills/RequirementsDoc.md b/.codex/skills/RequirementsDoc.md new file mode 100644 index 0000000..4039885 --- /dev/null +++ b/.codex/skills/RequirementsDoc.md @@ -0,0 +1 @@ +just empety... diff --git a/.codex/skills/changelog/SKILL.md b/.codex/skills/changelog/SKILL.md new file mode 100644 index 0000000..d20c2c6 --- /dev/null +++ b/.codex/skills/changelog/SKILL.md @@ -0,0 +1,109 @@ +--- +name: changelog +description: 一键发版：生成更新日志 → commit → 打 tag，全流程自动化。 +--- + +# Changelog - 一键发版 + +> **定位**：发版全流程。`/changelog 1.0.0227.1` 一个命令搞定日志生成 + commit + tag。 + +## 用法 + +``` +/changelog # 例: /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) +``` diff --git a/.codex/skills/deploy/SKILL.md b/.codex/skills/deploy/SKILL.md new file mode 100644 index 0000000..b99810c --- /dev/null +++ b/.codex/skills/deploy/SKILL.md @@ -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-` 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:// + - DRONE_GITEA_CLIENT_ID= + - DRONE_GITEA_CLIENT_SECRET= + - DRONE_SERVER_HOST= + - DRONE_SERVER_PROTO=https + - DRONE_RPC_SECRET= + - DRONE_USER_CREATE=username:,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": [":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 @ + +# 验证 +ssh -i ~/.ssh/drone_deploy -p @ "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 ` 后重新登录 | +| 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 ` | +| 健康检查超时 | 增大 `MAX_ATTEMPTS`；检查服务启动日志 | diff --git a/.codex/skills/go/SKILL.md b/.codex/skills/go/SKILL.md new file mode 100644 index 0000000..cacefad --- /dev/null +++ b/.codex/skills/go/SKILL.md @@ -0,0 +1,324 @@ +--- +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/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 标记 | 优先执行 `` 标记的新任务 | +| 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(): <简要描述> + +- 完成 T-xxx: {任务名} +- 完成 T-xxx: {任务名} +- ... + +Co-Authored-By: Claude +``` + +**示例**： + +``` +feat(auth): 完成用户认证模块 + +- 完成 T-005: 用户登录功能 +- 完成 T-006: 用户注册功能 +- 完成 T-007: JWT Token 管理 +- 完成 T-008: 权限验证中间件 + +Co-Authored-By: Claude +``` + +## 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 +``` diff --git a/.codex/skills/iter/SKILL.md b/.codex/skills/iter/SKILL.md new file mode 100644 index 0000000..f03c314 --- /dev/null +++ b/.codex/skills/iter/SKILL.md @@ -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 + + +新增内容... + +``` + +或修改现有内容： + +```markdown + + +修改后的内容 +``` + +**更新位置**： +- Bug 修复 → 更新对应功能的验收标准 +- 功能迭代 → 在 3.2 功能详情添加/修改功能点 +- 技术重构 → 在 4.x 非功能需求或 7.1 技术约束中说明 + +### 4.2 更新 tasks.md + +新增任务使用标记： + +```markdown + +| T-xxx | {任务名} | {描述} | {依赖} | {优先级} | {验收标准} | +``` + +**任务 ID 规则**： +- 查找现有最大 ID，递增分配 +- 格式：T-xxx（三位数字） + +### 4.3 标记规范 + +所有变更使用 `` 前缀，区分于 `/mp` `/mt` 的标记： + +- `` +- 便于追溯迭代历史 + +## 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` 等 | diff --git a/.codex/skills/md/SKILL.md b/.codex/skills/md/SKILL.md new file mode 100644 index 0000000..c955fa5 --- /dev/null +++ b/.codex/skills/md/SKILL.md @@ -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.md` - 评审报告（如果存在，自动作为修改依据） + +如果 DevelopmentPlan.md 不存在，提示用户： +> DevelopmentPlan.md 不存在，请先使用 `/wd` 生成开发计划。 + +## 2. 确定修改来源 + +按以下优先级确定修改内容： + +### 2.1 用户提供了修改指令 + +如果用户在调用 `/md` 时附带了参数或说明，直接使用该指令。 + +### 2.2 自动检测评审报告 + +如果用户未提供修改指令，**自动检测** `doc/review-DevelopmentPlan.md` 是否存在： + +- **存在**：读取评审报告，提取其中的问题清单，作为本次修改的依据。向用户确认： + > 检测到评审报告，包含 X 个问题。是否根据评审报告进行修改？ + +- **不存在**：询问用户： + > 请说明需要修改的内容，或先运行 `/rd` 生成评审报告。 + +## 3. 修改原则 + +### 3.1 增量修改 + +- 保留原有内容结构和格式 +- 仅修改/新增指定部分 +- 不删除未明确要求删除的内容 + +### 3.2 新增内容标记 + +对于新增的段落或章节： + +```markdown + +新增内容... + +``` + +对于行内新增： + +```markdown +原有内容 新增内容 +``` + +### 3.3 修改内容标记 + +```markdown + +修改后的内容 +``` + +### 3.4 与 FeatureSummary 一致性 + +- 开发任务必须覆盖所有功能 +- 技术方案必须支撑功能需求 +- 阶段划分必须合理 + +## 4. 执行修改 + +| 修改类型 | 处理方式 | +|----------|----------| +| 新增开发任务 | 在对应阶段表格中添加行 | +| 修改技术方案 | 更新技术方案章节，添加 MODIFIED 标记 | +| 调整阶段划分 | 移动任务到新阶段，标记变更 | +| 新增风险项 | 在风险管理表格中添加行 | +| 修改里程碑 | 更新里程碑表格 | + +## 5. 保存并验证 + +1. 保存修改后的文档到 `doc/DevelopmentPlan.md` +2. 使用 git diff 展示变更内容 +3. 向用户确认修改是否符合预期 + +## 6. 输出摘要 + +向用户展示修改摘要： + +- 修改位置（章节/行号） +- 修改类型（新增/修改/删除） +- 修改内容概要 +- 与 FeatureSummary 的一致性确认 + +--- + +## 注意事项 + +- DevelopmentPlan 依赖于 FeatureSummary，修改时需确保与上游一致 +- 修改后，下游文档（UIDesign、tasks）可能需要同步更新 +- 技术方案修改需谨慎评估影响范围 +- 建议修改完成后运行 `/ru` 检查下游一致性 + +## 标记清理 + +用户确认修改无误后，可手动删除标记或保留作为变更历史参考。 diff --git a/.codex/skills/mf/SKILL.md b/.codex/skills/mf/SKILL.md new file mode 100644 index 0000000..c0bdbff --- /dev/null +++ b/.codex/skills/mf/SKILL.md @@ -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.md` - 评审报告（如果存在，自动作为修改依据） + +如果 FeatureSummary.md 不存在，提示用户： +> FeatureSummary.md 不存在，请先使用 `/wf` 生成功能摘要。 + +## 2. 确定修改来源 + +按以下优先级确定修改内容： + +### 2.1 用户提供了修改指令 + +如果用户在调用 `/mf` 时附带了参数或说明，直接使用该指令。 + +### 2.2 自动检测评审报告 + +如果用户未提供修改指令，**自动检测** `doc/review-FeatureSummary.md` 是否存在： + +- **存在**：读取评审报告，提取其中的问题清单，作为本次修改的依据。向用户确认： + > 检测到评审报告，包含 X 个问题。是否根据评审报告进行修改？ + +- **不存在**：询问用户： + > 请说明需要修改的内容，或先运行 `/rf` 生成评审报告。 + +## 3. 修改原则 + +### 3.1 增量修改 + +- 保留原有内容结构和格式 +- 仅修改/新增指定部分 +- 不删除未明确要求删除的内容 + +### 3.2 新增内容标记 + +对于新增的段落或章节： + +```markdown + +新增内容... + +``` + +对于行内新增： + +```markdown +原有内容 新增内容 +``` + +### 3.3 修改内容标记 + +```markdown + +修改后的内容 +``` + +### 3.4 与 PRD 一致性 + +- 所有功能必须来源于 PRD +- 修改后的功能描述必须与 PRD 一致 +- 优先级必须与 PRD 匹配 + +## 4. 执行修改 + +| 修改类型 | 处理方式 | +|----------|----------| +| 新增功能 | 在对应模块表格中添加行 | +| 修改描述 | 更新功能描述，添加 MODIFIED 标记 | +| 修改优先级 | 更新优先级列 | +| 新增模块 | 在功能清单中添加新章节 | +| 删除功能 | 标记为删除而非直接移除 | + +## 5. 保存并验证 + +1. 保存修改后的文档到 `doc/FeatureSummary.md` +2. 使用 git diff 展示变更内容 +3. 向用户确认修改是否符合预期 + +## 6. 输出摘要 + +向用户展示修改摘要： + +- 修改位置（章节/行号） +- 修改类型（新增/修改/删除） +- 修改内容概要 +- 与 PRD 的一致性确认 + +--- + +## 注意事项 + +- FeatureSummary 依赖于 PRD，修改时需确保与上游一致 +- 修改后，下游文档（DevelopmentPlan 等）可能需要同步更新 +- 建议修改完成后运行 `/rd` 检查下游一致性 + +## 标记清理 + +用户确认修改无误后，可手动删除标记或保留作为变更历史参考。 diff --git a/.codex/skills/mp/SKILL.md b/.codex/skills/mp/SKILL.md new file mode 100644 index 0000000..8bffff9 --- /dev/null +++ b/.codex/skills/mp/SKILL.md @@ -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.md` - 评审报告（如果存在，自动作为修改依据） + +如果 PRD.md 不存在，提示用户： +> PRD.md 不存在，请先使用 `/wp` 生成产品需求文档。 + +## 2. 确定修改来源 + +按以下优先级确定修改内容： + +### 2.1 用户提供了修改指令 + +如果用户在调用 `/mp` 时附带了参数或说明，直接使用该指令。 + +### 2.2 自动检测评审报告 + +如果用户未提供修改指令，**自动检测** `doc/review-PRD.md` 是否存在： + +- **存在**：读取评审报告，提取其中的问题清单（Critical / Major / Minor），作为本次修改的依据。向用户确认： + > 检测到评审报告 `doc/review-PRD.md`，包含 X 个问题。是否根据评审报告进行修改？ + +- **不存在**：询问用户： + > 请说明需要修改的内容，或先运行 `/rp` 生成评审报告。 + +### 2.3 支持的修改来源 + +- 具体的修改描述（如"在功能需求中增加用户权限管理模块"） +- 评审报告（自动检测或手动指定路径） +- 对应的 RequirementsDoc 变更（如"/mr 已更新需求，请同步 PRD"） + +## 3. 修改原则 + +### 3.1 增量修改 +- 保留原有内容结构和格式 +- 仅修改/新增指定部分 +- 不删除未明确要求删除的内容 + +### 3.2 新增内容标记 + +对于新增的段落或章节，使用 HTML 注释标记： + +```markdown + +新增内容... + +``` + +对于行内新增，使用： +```markdown +原有内容 新增内容 +``` + +### 3.3 修改内容标记 + +对于修改的内容，保留原文作为注释： + +```markdown + +修改后的内容 +``` + +### 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` 检查下游文档一致性 + +## 标记清理 + +当用户确认修改无误后，可手动删除 `` 和 `` 标记，或保留作为变更历史参考。 + +通过 git 可追溯完整修改历史。 + +## 质量检查 + +修改 PRD 后，自查以下项目： + +- [ ] 修改内容与 RequirementsDoc 一致 +- [ ] 新增用户故事有唯一 ID +- [ ] 新增功能点关联到用户故事 +- [ ] 新增功能点有明确优先级和验收标准 +- [ ] 标记格式正确（`` / ``） +- [ ] 文档结构完整，格式一致 diff --git a/.codex/skills/mr/SKILL.md b/.codex/skills/mr/SKILL.md new file mode 100644 index 0000000..0e67236 --- /dev/null +++ b/.codex/skills/mr/SKILL.md @@ -0,0 +1,95 @@ +--- +name: mr +description: 增量修改 RequirementsDoc.md，根据用户指令在现有内容基础上更新需求文档。 +--- + +# Modify RequirementsDoc + +当用户调用 `/mr` 时，执行以下步骤： + +## 1. 读取目标文档 + +读取 `doc/RequirementsDoc.md` 文件。 + +如果文件不存在，提示用户： +> RequirementsDoc.md 不存在，请先使用人工方式创建需求文档。 + +## 2. 获取修改指令 + +向用户确认修改内容。用户应提供以下信息之一： + +- 具体的修改描述（如"在第3节增加性能需求"） +- 评审报告路径（如 `doc/review-RequirementsDoc.md`） +- 直接的修改内容 + +如果用户未提供修改指令，询问： +> 请说明需要修改的内容，或提供评审报告路径。 + +## 3. 修改原则 + +### 3.1 增量修改 +- 保留原有内容结构和格式 +- 仅修改/新增指定部分 +- 不删除未明确要求删除的内容 + +### 3.2 新增内容标记 + +对于新增的段落或章节，使用 HTML 注释标记： + +```markdown + +新增内容... + +``` + +对于行内新增，使用： +```markdown +原有内容 新增内容 +``` + +### 3.3 修改内容标记 + +对于修改的内容，保留原文作为注释： + +```markdown + +修改后的内容 +``` + +## 4. 执行修改 + +按照用户指令修改文档： + +1. 定位到需要修改的位置 +2. 执行增量修改 +3. 添加相应的标记 +4. 保持文档格式一致性 + +## 5. 保存并验证 + +1. 保存修改后的文档到 `doc/RequirementsDoc.md` +2. 使用 git diff 展示变更内容 +3. 向用户确认修改是否符合预期 + +## 6. 输出摘要 + +向用户展示修改摘要： +- 修改位置（章节/行号） +- 修改类型（新增/修改/删除） +- 修改内容概要 + +--- + +## 注意事项 + +- RequirementsDoc 是文档链源头，修改会影响所有下游文档 +- 修改前确认用户意图，避免误改 +- 保持现有文档风格（标题层级、表格格式、列表样式） +- 重大修改建议先运行 `/rr` 评审确认影响范围 +- 修改完成后，建议用户检查下游文档是否需要同步更新 + +## 标记清理 + +当用户确认修改无误后，可手动删除 `` 和 `` 标记，或保留作为变更历史参考。 + +通过 git 可追溯完整修改历史。 diff --git a/.codex/skills/mt/SKILL.md b/.codex/skills/mt/SKILL.md new file mode 100644 index 0000000..af728b7 --- /dev/null +++ b/.codex/skills/mt/SKILL.md @@ -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.md` - 评审报告（如果存在，自动作为修改依据） + +如果 tasks.md 不存在，提示用户： +> tasks.md 不存在，请先使用 `/wt` 生成任务列表。 + +## 2. 确定修改来源 + +按以下优先级确定修改内容： + +### 2.1 用户提供了修改指令 + +如果用户在调用 `/mt` 时附带了参数或说明，直接使用该指令。 + +### 2.2 自动检测评审报告 + +如果用户未提供修改指令，**自动检测** `doc/review-tasks.md` 是否存在： + +- **存在**：读取评审报告，提取其中的问题清单，作为本次修改的依据。向用户确认： + > 检测到评审报告，包含 X 个问题。是否根据评审报告进行修改？ + +- **不存在**：询问用户： + > 请说明需要修改的内容，或先运行 `/rt` 生成评审报告。 + +## 3. 修改原则 + +### 3.1 增量修改 + +- 保留原有内容结构和格式 +- 仅修改/新增指定部分 +- 不删除未明确要求删除的内容 + +### 3.2 新增内容标记 + +对于新增的段落或章节： + +```markdown + +新增内容... + +``` + +对于行内新增： + +```markdown +原有内容 新增内容 +``` + +### 3.3 修改内容标记 + +```markdown + +修改后的内容 +``` + +### 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 唯一且格式正确 +- [ ] 无循环依赖 +- [ ] 验收标准明确 +- [ ] 覆盖所有上游功能 +- [ ] 标记格式正确 diff --git a/.codex/skills/mu/SKILL.md b/.codex/skills/mu/SKILL.md new file mode 100644 index 0000000..6c7ede0 --- /dev/null +++ b/.codex/skills/mu/SKILL.md @@ -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.md` - 评审报告（如果存在，自动作为修改依据） + +如果 UIDesign.md 不存在，提示用户： +> UIDesign.md 不存在，请先使用 `/wu` 生成 UI 设计文档。 + +## 2. 确定修改来源 + +按以下优先级确定修改内容： + +### 2.1 用户提供了修改指令 + +如果用户在调用 `/mu` 时附带了参数或说明，直接使用该指令。 + +### 2.2 自动检测评审报告 + +如果用户未提供修改指令，**自动检测** `doc/review-UIDesign.md` 是否存在： + +- **存在**：读取评审报告，提取其中的问题清单，作为本次修改的依据。向用户确认： + > 检测到评审报告，包含 X 个问题。是否根据评审报告进行修改？ + +- **不存在**：询问用户： + > 请说明需要修改的内容，或先运行 `/ru` 生成评审报告。 + +## 3. 修改原则 + +### 3.1 增量修改 + +- 保留原有内容结构和格式 +- 仅修改/新增指定部分 +- 不删除未明确要求删除的内容 + +### 3.2 新增内容标记 + +对于新增的段落或章节： + +```markdown + +新增内容... + +``` + +对于行内新增： + +```markdown +原有内容 新增内容 +``` + +### 3.3 修改内容标记 + +```markdown + +修改后的内容 +``` + +### 3.4 与 DevelopmentPlan 一致性 + +- 页面设计必须覆盖所有功能模块 +- 交互流程必须支撑功能需求 +- 设计规范必须统一 + +## 4. 执行修改 + +| 修改类型 | 处理方式 | +|----------|----------| +| 新增页面 | 在页面设计章节添加新子章节 | +| 修改布局 | 更新布局描述，添加 MODIFIED 标记 | +| 修改组件 | 更新组件表格 | +| 修改交互 | 更新交互说明 | +| 新增状态 | 在状态列表中添加项目 | +| 修改设计规范 | 更新设计规范章节 | + +## 5. 保存并验证 + +1. 保存修改后的文档到 `doc/UIDesign.md` +2. 使用 git diff 展示变更内容 +3. 向用户确认修改是否符合预期 + +## 6. 输出摘要 + +向用户展示修改摘要： + +- 修改位置（章节/行号） +- 修改类型（新增/修改/删除） +- 修改内容概要 +- 与 DevelopmentPlan 的一致性确认 + +--- + +## 注意事项 + +- UIDesign 依赖于 DevelopmentPlan，修改时需确保与上游一致 +- 修改后，下游文档（tasks）可能需要同步更新 +- 页面修改需考虑对用户流程的影响 +- 设计规范修改需检查所有页面的一致性 +- 建议修改完成后运行 `/rt` 检查下游一致性 + +## 标记清理 + +用户确认修改无误后，可手动删除标记或保留作为变更历史参考。 diff --git a/.codex/skills/muse.svg b/.codex/skills/muse.svg new file mode 100644 index 0000000..32decb4 --- /dev/null +++ b/.codex/skills/muse.svg @@ -0,0 +1,93 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + \ No newline at end of file diff --git a/.codex/skills/rd/SKILL.md b/.codex/skills/rd/SKILL.md new file mode 100644 index 0000000..2d20087 --- /dev/null +++ b/.codex/skills/rd/SKILL.md @@ -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.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` 修改 diff --git a/.codex/skills/rf/SKILL.md b/.codex/skills/rf/SKILL.md new file mode 100644 index 0000000..363cec4 --- /dev/null +++ b/.codex/skills/rf/SKILL.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.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` 修改 diff --git a/.codex/skills/rp/SKILL.md b/.codex/skills/rp/SKILL.md new file mode 100644 index 0000000..0e96209 --- /dev/null +++ b/.codex/skills/rp/SKILL.md @@ -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.md`。 + +如果文件已存在，覆盖原文件（历史版本通过 git 追溯）。 + +## 5. 输出摘要 + +向用户展示评审摘要： +- 一致性检查结果（覆盖率） +- 发现的问题数量（按严重程度分类） +- 用户故事评估结果 +- 评审结论 +- 报告文件路径 + +--- + +## 注意事项 + +- 评审时保持客观，聚焦于文档质量和一致性 +- 问题描述要具体，给出明确的位置引用（如 `doc/PRD.md:42`） +- 一致性检查要逐项对比，不能遗漏 +- 建议要可操作，避免模糊表述 +- 不要修改原文档，只输出评审报告 + +## 常见问题模式 + +在评审时重点关注以下常见问题： + +1. **需求遗漏**：RequirementsDoc 中有但 PRD 中没有的需求 +2. **需求偏离**：PRD 中的描述与 RequirementsDoc 不一致 +3. **凭空添加**：PRD 中有但 RequirementsDoc 中没有的需求（需要来源说明） +4. **用户故事缺陷**：格式不规范、缺少验收标准、角色不明确 +5. **功能孤立**：功能点未关联到任何用户故事 +6. **优先级冲突**：PRD 与 RequirementsDoc 的优先级划分不一致 diff --git a/.codex/skills/rr/SKILL.md b/.codex/skills/rr/SKILL.md new file mode 100644 index 0000000..1e03f4c --- /dev/null +++ b/.codex/skills/rr/SKILL.md @@ -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.md`。 + +如果文件已存在，覆盖原文件（历史版本通过 git 追溯）。 + +## 5. 输出摘要 + +向用户展示评审摘要： +- 发现的问题数量（按严重程度分类） +- 评审结论 +- 报告文件路径 + +--- + +## 注意事项 + +- 评审时保持客观，聚焦于文档质量而非业务判断 +- 问题描述要具体，给出明确的位置引用 +- 建议要可操作，避免模糊表述 +- 不要修改原文档，只输出评审报告 diff --git a/.codex/skills/rt/SKILL.md b/.codex/skills/rt/SKILL.md new file mode 100644 index 0000000..2480613 --- /dev/null +++ b/.codex/skills/rt/SKILL.md @@ -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.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` 修改 diff --git a/.codex/skills/ru/SKILL.md b/.codex/skills/ru/SKILL.md new file mode 100644 index 0000000..39a478b --- /dev/null +++ b/.codex/skills/ru/SKILL.md @@ -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.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` 修改 diff --git a/.codex/skills/up/SKILL.md b/.codex/skills/up/SKILL.md new file mode 100644 index 0000000..5bdeddb --- /dev/null +++ b/.codex/skills/up/SKILL.md @@ -0,0 +1,78 @@ +--- +name: update +aliases: [up] +description: 收集用户反馈并更新最近使用的 skill。在用完某个 skill 后调用此命令来优化该 skill。 +disable-model-invocation: true +argument-hint: [skill-name] +--- + +# Skill 更新助手 + +当用户请求使用 `update` 或 `up` skill 时，执行以下步骤： + +## 1. 识别目标 Skill + +**如果用户提供了参数 `$ARGUMENTS`**： +- 直接使用指定的 skill 名称作为更新目标 + +**如果没有提供参数**： +分析当前对话历史，找出最近使用的 skill： +- 从最近几轮对话中识别调用过的 skill 名称 +- 如果找到多个 skill，让用户确认要更新哪一个 +- 如果没有找到任何 skill 调用记录，提示用户先使用一个 skill + +## 2. 收集用户反馈 + +直接向用户询问以下问题： + +**问题 1：这次使用体验如何？** +- 很好，skill 完全满足需求 +- 基本满足，但有改进空间 +- 不太满意，需要较大调整 + +**问题 2：具体需要改进的方面？**（多选） +- 执行步骤不够清晰 +- 缺少某些功能 +- 输出格式需要调整 +- 提示词需要优化 +- 其他（用户自定义输入） + +## 3. 分析优化点 + +基于用户反馈和本次 skill 使用过程，分析以下方面： + +1. **执行流程**：哪些步骤可以简化或合并？ +2. **指令清晰度**：哪些指令描述不够明确？ +3. **遗漏功能**：有哪些场景没有覆盖到？ +4. **输出质量**：输出格式是否符合用户预期？ + +## 4. 定位 Skill 文件 + +按以下优先级搜索 skill 文件： +1. 项目级：`.codex/skills//SKILL.md` +2. 用户级：`~/.codex/skills//SKILL.md` + +## 5. 更新 Skill + +读取现有的 SKILL.md 文件内容，根据分析结果进行更新： + +- 保持 frontmatter 格式不变（除非需要修改 description） +- 优化执行步骤的描述 +- 添加缺失的功能说明 +- 改进提示词的表达方式 +- 添加必要的注意事项或边界情况处理 + +## 6. 确认更新 + +在更新前，向用户展示： +- 修改前后的对比（diff 格式） +- 说明每处修改的原因 + +用户确认后才执行实际的文件更新。 + +## 注意事项 + +- 如果 skill 文件不存在或路径无法确定，提示用户手动指定路径 +- 更新时保持 skill 的原有风格和结构 +- 重大修改需要用户明确确认 +- 保留原有的有效内容，只做增量优化 diff --git a/.codex/skills/wd/SKILL.md b/.codex/skills/wd/SKILL.md new file mode 100644 index 0000000..9343961 --- /dev/null +++ b/.codex/skills/wd/SKILL.md @@ -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 关联 diff --git a/.codex/skills/wf/SKILL.md b/.codex/skills/wf/SKILL.md new file mode 100644 index 0000000..c8ac3c4 --- /dev/null +++ b/.codex/skills/wf/SKILL.md @@ -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 中的功能 diff --git a/.codex/skills/wp/SKILL.md b/.codex/skills/wp/SKILL.md new file mode 100644 index 0000000..e647daf --- /dev/null +++ b/.codex/skills/wp/SKILL.md @@ -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 中的重要需求 +- [ ] 文档结构完整，无空章节（或标注"待补充"） diff --git a/.codex/skills/wt/SKILL.md b/.codex/skills/wt/SKILL.md new file mode 100644 index 0000000..253fe91 --- /dev/null +++ b/.codex/skills/wt/SKILL.md @@ -0,0 +1,128 @@ +--- +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` - 必须存在 + +如果文件不存在，提示用户： +> 缺少上游文档，请确保所有上游文档存在。 + +如果已存在 `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...） +- 每个任务必须有明确的验收标准 +- 任务粒度要适中，可在合理时间内完成 +- 依赖关系要明确，避免循环依赖 +- 任务应可直接执行，无歧义 diff --git a/.codex/skills/wu/SKILL.md b/.codex/skills/wu/SKILL.md new file mode 100644 index 0000000..3b17b58 --- /dev/null +++ b/.codex/skills/wu/SKILL.md @@ -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 原型图** +- [ ] **原型图展示了完整的页面结构** +- [ ] **用户流程有流程图** +- [ ] 每个页面都有状态说明 +- [ ] 组件清单完整 +- [ ] 交互说明清晰 +- [ ] 设计规范统一 diff --git a/.gitignore b/.gitignore index 1323208..4db4617 100644 --- a/.gitignore +++ b/.gitignore @@ -3,7 +3,10 @@ doc/ # 其他开发文件 write-skills/ -.codex/ +.codex/* +!.codex/skills/ +!.codex/skills/** +.agents/ # macOS .DS_Store diff --git a/AGENTS.md b/AGENTS.md new file mode 100644 index 0000000..dd2e9fb --- /dev/null +++ b/AGENTS.md @@ -0,0 +1,40 @@ +## Skills + +### Available skills + +- `rr`: 评审 RequirementsDoc.md，检查需求文档的完整性、清晰度和可执行性，输出结构化评审报告。 (file: `./.codex/skills/rr/SKILL.md`) +- `rp`: 评审 PRD.md，对比 RequirementsDoc 检查一致性，输出结构化评审报告。 (file: `./.codex/skills/rp/SKILL.md`) +- `rf`: 评审 FeatureSummary.md，对比 PRD 检查一致性，输出结构化评审报告。 (file: `./.codex/skills/rf/SKILL.md`) +- `rd`: 评审 DevelopmentPlan.md，检查技术可行性和与上游文档一致性，输出结构化评审报告。 (file: `./.codex/skills/rd/SKILL.md`) +- `ru`: 评审 UIDesign.md，对比 DevelopmentPlan 检查设计一致性，输出结构化评审报告。 (file: `./.codex/skills/ru/SKILL.md`) +- `rt`: 评审 tasks.md，检查任务完整性和与上游文档一致性，输出结构化评审报告。 (file: `./.codex/skills/rt/SKILL.md`) +- `wp`: 从 RequirementsDoc.md 生成 PRD.md，将需求文档转化为结构化的产品需求文档。 (file: `./.codex/skills/wp/SKILL.md`) +- `wf`: 从 RequirementsDoc.md 和 PRD.md 生成 FeatureSummary.md，提供功能全貌概览。 (file: `./.codex/skills/wf/SKILL.md`) +- `wd`: 从上游文档生成 DevelopmentPlan.md，包含技术方案和开发排期。 (file: `./.codex/skills/wd/SKILL.md`) +- `wu`: 从上游文档生成 UIDesign.md，覆盖所有用户界面设计。 (file: `./.codex/skills/wu/SKILL.md`) +- `wt`: 从上游文档生成 tasks.md，创建可直接执行的任务列表。 (file: `./.codex/skills/wt/SKILL.md`) +- `mr`: 增量修改 RequirementsDoc.md，根据用户指令在现有内容基础上更新需求文档。 (file: `./.codex/skills/mr/SKILL.md`) +- `mp`: 增量修改 PRD.md，根据用户指令在现有内容基础上更新产品需求文档。 (file: `./.codex/skills/mp/SKILL.md`) +- `mf`: 增量修改 FeatureSummary.md，根据用户指令在现有内容基础上更新功能摘要。 (file: `./.codex/skills/mf/SKILL.md`) +- `md`: 增量修改 DevelopmentPlan.md，根据用户指令在现有内容基础上更新开发计划。 (file: `./.codex/skills/md/SKILL.md`) +- `mu`: 增量修改 UIDesign.md，根据用户指令在现有内容基础上更新 UI 设计文档。 (file: `./.codex/skills/mu/SKILL.md`) +- `mt`: 增量修改 tasks.md，根据用户指令在现有内容基础上更新任务列表。 (file: `./.codex/skills/mt/SKILL.md`) +- `go`: 终极执行按钮，激进模式一口气完成开发任务，兼容 0->1 和 1->100 场景。 (file: `./.codex/skills/go/SKILL.md`) +- `iter`: 迭代变更入口，调研问题后更新 PRD.md 和 tasks.md，支持 Bug 修复、功能迭代、技术重构。 (file: `./.codex/skills/iter/SKILL.md`) +- `update`: 收集用户反馈并更新最近使用的 skill。别名：`up`。 (file: `./.codex/skills/up/SKILL.md`) +- `deploy`: Drone CI + 服务器 CD 全流程引导：从基础设施检查到生成配置文件到验证部署，交互式完成。 (file: `./.codex/skills/deploy/SKILL.md`) +- `changelog`: 一键发版：生成更新日志 → commit → 打 tag，全流程自动化。 (file: `./.codex/skills/changelog/SKILL.md`) + +### How to use skills + +- Discovery: 以上列表就是当前仓库提供给 Codex 的 skills。 +- Trigger rules: 如果用户显式提到 skill 名称（例如 `$rr`、`rr skill`、`用 rr 评审`），或任务明显匹配 skill 描述，优先使用对应 skill。 +- Codex usage: 在 Codex 中优先使用 `$skill-name` 或自然语言；skill 文档里出现的 `/rr`、`/go` 等 slash command 只是 Claude Code 的兼容写法。 +- Missing/blocked: 如果某个 skill 文件不存在或无法读取，简短说明并回退到普通实现方式。 +- Context hygiene: 只按需打开 `SKILL.md`，不要一次性加载整个 skill 仓库。 + +### Repo notes + +- `./.claude/skills/` 保留给 Claude Code。 +- `./.codex/skills/` 是 Codex 的实际安装源。 +- 迁移或新增 skill 时，优先同步更新 `README.md`、`AGENTS.md`、`AGENTS.md.template`。 diff --git a/AGENTS.md.template b/AGENTS.md.template new file mode 100644 index 0000000..147d4c9 --- /dev/null +++ b/AGENTS.md.template @@ -0,0 +1,42 @@ +# AGENTS.md + +把这个文件放在项目根目录，用来把已安装的 Codex skills 注册给 Codex。项目级约束可以追加在文末的 `Project notes` 一节。 + +## Skills + +### Available skills + +- `rr`: 评审 RequirementsDoc.md，检查需求文档的完整性、清晰度和可执行性，输出结构化评审报告。 (file: `./.codex/skills/rr/SKILL.md`) +- `rp`: 评审 PRD.md，对比 RequirementsDoc 检查一致性，输出结构化评审报告。 (file: `./.codex/skills/rp/SKILL.md`) +- `rf`: 评审 FeatureSummary.md，对比 PRD 检查一致性，输出结构化评审报告。 (file: `./.codex/skills/rf/SKILL.md`) +- `rd`: 评审 DevelopmentPlan.md，检查技术可行性和与上游文档一致性，输出结构化评审报告。 (file: `./.codex/skills/rd/SKILL.md`) +- `ru`: 评审 UIDesign.md，对比 DevelopmentPlan 检查设计一致性，输出结构化评审报告。 (file: `./.codex/skills/ru/SKILL.md`) +- `rt`: 评审 tasks.md，检查任务完整性和与上游文档一致性，输出结构化评审报告。 (file: `./.codex/skills/rt/SKILL.md`) +- `wp`: 从 RequirementsDoc.md 生成 PRD.md，将需求文档转化为结构化的产品需求文档。 (file: `./.codex/skills/wp/SKILL.md`) +- `wf`: 从 RequirementsDoc.md 和 PRD.md 生成 FeatureSummary.md，提供功能全貌概览。 (file: `./.codex/skills/wf/SKILL.md`) +- `wd`: 从上游文档生成 DevelopmentPlan.md，包含技术方案和开发排期。 (file: `./.codex/skills/wd/SKILL.md`) +- `wu`: 从上游文档生成 UIDesign.md，覆盖所有用户界面设计。 (file: `./.codex/skills/wu/SKILL.md`) +- `wt`: 从上游文档生成 tasks.md，创建可直接执行的任务列表。 (file: `./.codex/skills/wt/SKILL.md`) +- `mr`: 增量修改 RequirementsDoc.md，根据用户指令在现有内容基础上更新需求文档。 (file: `./.codex/skills/mr/SKILL.md`) +- `mp`: 增量修改 PRD.md，根据用户指令在现有内容基础上更新产品需求文档。 (file: `./.codex/skills/mp/SKILL.md`) +- `mf`: 增量修改 FeatureSummary.md，根据用户指令在现有内容基础上更新功能摘要。 (file: `./.codex/skills/mf/SKILL.md`) +- `md`: 增量修改 DevelopmentPlan.md，根据用户指令在现有内容基础上更新开发计划。 (file: `./.codex/skills/md/SKILL.md`) +- `mu`: 增量修改 UIDesign.md，根据用户指令在现有内容基础上更新 UI 设计文档。 (file: `./.codex/skills/mu/SKILL.md`) +- `mt`: 增量修改 tasks.md，根据用户指令在现有内容基础上更新任务列表。 (file: `./.codex/skills/mt/SKILL.md`) +- `go`: 终极执行按钮，激进模式一口气完成开发任务，兼容 0->1 和 1->100 场景。 (file: `./.codex/skills/go/SKILL.md`) +- `iter`: 迭代变更入口，调研问题后更新 PRD.md 和 tasks.md，支持 Bug 修复、功能迭代、技术重构。 (file: `./.codex/skills/iter/SKILL.md`) +- `update`: 收集用户反馈并更新最近使用的 skill。别名：`up`。 (file: `./.codex/skills/up/SKILL.md`) +- `deploy`: Drone CI + 服务器 CD 全流程引导：从基础设施检查到生成配置文件到验证部署，交互式完成。 (file: `./.codex/skills/deploy/SKILL.md`) +- `changelog`: 一键发版：生成更新日志 → commit → 打 tag，全流程自动化。 (file: `./.codex/skills/changelog/SKILL.md`) + +### How to use skills + +- Discovery: 以上列表就是当前项目注册给 Codex 的 skills。 +- Trigger rules: 如果用户显式提到 skill 名称（例如 `$rr`、`rr skill`、`用 rr 评审`），或任务明显匹配 skill 描述，优先使用对应 skill。 +- Codex usage: 在 Codex 中优先使用 `$skill-name` 或自然语言；skill 文档里出现的 `/rr`、`/go` 等 slash command 只是 Claude Code 的兼容写法。 +- Missing/blocked: 如果某个 skill 文件不存在或无法读取，简短说明并回退到普通实现方式。 +- Context hygiene: 只按需打开 `SKILL.md`，不要一次性加载整个 skill 仓库。 + +## Project notes + +- 在这里补充项目特定约束，例如技术栈、测试命令、代码风格、提交流程。 diff --git a/README.md b/README.md index dec1d8e..3b531c0 100644 --- a/README.md +++ b/README.md @@ -1,60 +1,78 @@ # Spec Coding Skills -一套 Claude Code Skills，支持产品文档工作流的完整生命周期管理。 +一套同时支持 Claude Code 和 Codex 的 Skills，覆盖产品文档工作流的完整生命周期管理。 + +## 平台适配 + +| 平台 | 安装目录 | 触发方式 | +|------|----------|----------| +| Claude Code | `.claude/skills/` | `/rr`、`/wp`、`/go` 这类 slash commands | +| Codex | `.codex/skills/` | `$rr`、`$wp`，或直接自然语言说明“用 rr skill 评审需求文档” | + +> Codex 额外需要项目根目录存在 `AGENTS.md`。本仓库已提供 `AGENTS.md.template`，安装脚本在 Codex 模式下会自动生成。 ## 功能概览 ``` RequirementsDoc ──▶ PRD ──▶ FeatureSummary ──▶ DevelopmentPlan ──▶ UIDesign ──▶ tasks │ │ │ │ │ │ - /rr /rp /rf /rd /ru /rt ← Review - /mr /mp /mf /md /mu /mt ← Modify - /wp /wf /wd /wu /wt ← Write + rr rp rf rd ru rt ← Review + mr mp mf md mu mt ← Modify + wp wf wd wu wt ← Write ``` ### Skills 列表 -| 类型 | 命令 | 描述 | -|------|------|------| -| **Review** | `/rr` | 评审 RequirementsDoc.md | -| | `/rp` | 评审 PRD.md | -| | `/rf` | 评审 FeatureSummary.md | -| | `/rd` | 评审 DevelopmentPlan.md | -| | `/ru` | 评审 UIDesign.md | -| | `/rt` | 评审 tasks.md | -| **Write** | `/wp` | 从 RequirementsDoc 生成 PRD | -| | `/wf` | 从 PRD 生成 FeatureSummary | -| | `/wd` | 从 FeatureSummary 生成 DevelopmentPlan | -| | `/wu` | 从 DevelopmentPlan 生成 UIDesign | -| | `/wt` | 从 DevelopmentPlan 生成 tasks | -| **Modify** | `/mr` | 增量修改 RequirementsDoc | -| | `/mp` | 增量修改 PRD（自动读取评审报告） | -| | `/mf` | 增量修改 FeatureSummary | -| | `/md` | 增量修改 DevelopmentPlan | -| | `/mu` | 增量修改 UIDesign | -| | `/mt` | 增量修改 tasks | -| **执行** | `/go` | 🚀 发射按钮，激进模式一口气完成开发 | -| **辅助** | `/iter` | 迭代变更入口（Bug/功能/重构） | -| | `/up` | Skill 升级优化 | -| | `/deploy` | Drone CI/CD 全流程部署引导 | -| | `/changelog` | 一键发版（日志 + commit + tag） | +| 类型 | Skill | Claude Code | Codex | 描述 | +|------|-------|-------------|-------|------| +| **Review** | `rr` | `/rr` | `$rr` | 评审 RequirementsDoc.md | +| | `rp` | `/rp` | `$rp` | 评审 PRD.md | +| | `rf` | `/rf` | `$rf` | 评审 FeatureSummary.md | +| | `rd` | `/rd` | `$rd` | 评审 DevelopmentPlan.md | +| | `ru` | `/ru` | `$ru` | 评审 UIDesign.md | +| | `rt` | `/rt` | `$rt` | 评审 tasks.md | +| **Write** | `wp` | `/wp` | `$wp` | 从 RequirementsDoc 生成 PRD | +| | `wf` | `/wf` | `$wf` | 从 PRD 生成 FeatureSummary | +| | `wd` | `/wd` | `$wd` | 从 FeatureSummary 生成 DevelopmentPlan | +| | `wu` | `/wu` | `$wu` | 从 DevelopmentPlan 生成 UIDesign | +| | `wt` | `/wt` | `$wt` | 从 DevelopmentPlan 生成 tasks | +| **Modify** | `mr` | `/mr` | `$mr` | 增量修改 RequirementsDoc | +| | `mp` | `/mp` | `$mp` | 增量修改 PRD（自动读取评审报告） | +| | `mf` | `/mf` | `$mf` | 增量修改 FeatureSummary | +| | `md` | `/md` | `$md` | 增量修改 DevelopmentPlan | +| | `mu` | `/mu` | `$mu` | 增量修改 UIDesign | +| | `mt` | `/mt` | `$mt` | 增量修改 tasks | +| **执行** | `go` | `/go` | `$go` | 🚀 发射按钮，激进模式一口气完成开发 | +| **辅助** | `iter` | `/iter` | `$iter` | 迭代变更入口（Bug/功能/重构） | +| | `update` | `/up` | `$update` 或 `$up` | Skill 升级优化 | +| | `deploy` | `/deploy` | `$deploy` | Drone CI/CD 全流程部署引导 | +| | `changelog` | `/changelog` | `$changelog` | 一键发版（日志 + commit + tag） | ## 安装 & 更新 一行命令搞定安装和更新。脚本会智能处理：新 skill 直接装，已有的对比更新，本地魔改自动备份。 ```bash -# 在你的项目根目录执行（首次安装 & 后续更新都用这条） -bash <(curl -sL https://git.internal.intelligrow.cn/zhangfucai/spec-coding-skills/raw/branch/main/install.sh) +# Codex（默认） +bash <(curl -sL https://git.internal.intelligrow.cn/zhangfucai/spec-coding-skills/raw/branch/main/install.sh) codex + +# Claude Code +bash <(curl -sL https://git.internal.intelligrow.cn/zhangfucai/spec-coding-skills/raw/branch/main/install.sh) claude ``` 或者先下载再执行： ```bash curl -sL https://git.internal.intelligrow.cn/zhangfucai/spec-coding-skills/raw/branch/main/install.sh -o /tmp/install-skills.sh -bash /tmp/install-skills.sh +bash /tmp/install-skills.sh codex ``` +### 安装脚本行为 + +- `codex` 模式：安装到 `.codex/skills/`，并在项目根目录生成或更新 `AGENTS.md` +- `claude` 模式：安装到 `.claude/skills/`，并在项目根目录生成或更新 `CLAUDE.md` +- 如果传入自定义目标目录，脚本会优先安装 Codex 版 skills；目标路径包含 `.claude/skills` 时自动切到 Claude 版 + ### 更新策略 | 情况 | 处理方式 | @@ -71,25 +89,48 @@ bash /tmp/install-skills.sh ### 0->1 阶段：从需求到开发 -```bash -# 1. 准备文档 -/wp # 生成 PRD -/wf # 生成 FeatureSummary -/wd # 生成 DevelopmentPlan -/wt # 生成 tasks +Claude Code: -# 2. 发射！ -/go # 激进模式，一口气完成所有任务 +```bash +/wp +/wf +/wd +/wt +/go +``` + +Codex: + +```text +$wp +$wf +$wd +$wt +$go ``` ### 1->100 阶段：持续迭代 -```bash -# 1. 描述变更需求 -/iter # 调研 → 澄清 → 更新 PRD 和 tasks +Claude Code: -# 2. 执行变更 -/go # 自动识别新任务并执行 +```bash +/iter +/go +``` + +Codex: + +```text +$iter +$go +``` + +也可以直接说自然语言，例如： + +```text +请用 rr skill 评审 doc/RequirementsDoc.md +请用 wf skill 根据 PRD 生成 FeatureSummary +请用 go skill 按 doc/tasks.md 执行未完成任务 ``` ### 工作流总览 @@ -98,12 +139,12 @@ bash /tmp/install-skills.sh ┌─────────────────────────────────────────────────────────┐ │ 0->1 全新项目 │ │ │ -│ 需求 → /wp → /wf → /wd → /wt → /go 🚀 │ +│ 需求 → wp → wf → wd → wt → go 🚀 │ │ │ ├─────────────────────────────────────────────────────────┤ │ 1->100 持续迭代 │ │ │ -│ 发现问题 → /iter → /go 🚀 │ +│ 发现问题 → iter → go 🚀 │ │ │ └─────────────────────────────────────────────────────────┘ ``` @@ -122,8 +163,16 @@ bash /tmp/install-skills.sh ``` your-project/ +├── AGENTS.md # ← Codex 项目入口（Codex 模式） +├── CLAUDE.md # ← Claude Code 项目入口（Claude 模式） +├── .codex/ +│ └── skills/ # ← Codex Skills 安装位置 +│ ├── rr/ +│ ├── rp/ +│ ├── ... +│ └── iter/ ├── .claude/ -│ └── skills/ # ← Skills 安装位置 +│ └── skills/ # ← Claude Code Skills 安装位置 │ ├── rr/ │ ├── rp/ │ ├── ... diff --git a/install.sh b/install.sh index f16bb47..c3ac141 100644 --- a/install.sh +++ b/install.sh @@ -1,21 +1,64 @@ #!/usr/bin/env bash # ============================================================ # spec-coding-skills 安装/更新脚本 -# 用法: bash <(curl -sL /install.sh) -# 或: bash install.sh [目标目录] +# 用法: bash <(curl -sL /install.sh) [codex|claude] +# 或: bash install.sh [codex|claude|目标目录] # ============================================================ set -euo pipefail REPO_URL="https://git.internal.intelligrow.cn/zhangfucai/spec-coding-skills.git" -SKILLS_SRC=".claude/skills" -DEFAULT_TARGET=".claude/skills" +DEFAULT_MODE="codex" GREEN='\033[0;32m'; YELLOW='\033[1;33m'; CYAN='\033[0;36m'; NC='\033[0m' log_info() { echo -e "${GREEN}[INFO]${NC} $1"; } log_warn() { echo -e "${YELLOW}[WARN]${NC} $1"; } log_title() { echo -e "${CYAN}$1${NC}"; } -TARGET="${1:-$DEFAULT_TARGET}" +MODE="" +TARGET="" +SKILLS_SRC="" +GUIDE_SRC="" +GUIDE_DST="" + +resolve_layout() { + local input="$1" + + case "$input" in + ""|codex) + MODE="codex" + TARGET=".codex/skills" + SKILLS_SRC=".codex/skills" + GUIDE_SRC="AGENTS.md.template" + GUIDE_DST="AGENTS.md" + ;; + claude) + MODE="claude" + TARGET=".claude/skills" + SKILLS_SRC=".claude/skills" + GUIDE_SRC="CLAUDE.md.template" + GUIDE_DST="CLAUDE.md" + ;; + *) + TARGET="$input" + case "$TARGET" in + *".claude/skills"*) + MODE="claude" + SKILLS_SRC=".claude/skills" + GUIDE_SRC="CLAUDE.md.template" + GUIDE_DST="CLAUDE.md" + ;; + *) + MODE="codex" + SKILLS_SRC=".codex/skills" + GUIDE_SRC="AGENTS.md.template" + GUIDE_DST="AGENTS.md" + ;; + esac + ;; + esac +} + +resolve_layout "${1:-$DEFAULT_MODE}" TMP_DIR=$(mktemp -d) trap "rm -rf $TMP_DIR" EXIT @@ -27,6 +70,12 @@ git clone --depth 1 --quiet "$REPO_URL" "$TMP_DIR" VERSION=$(git -C "$TMP_DIR" describe --tags --always 2>/dev/null || git -C "$TMP_DIR" rev-parse --short HEAD) log_info "版本: $VERSION" +log_info "模式: $MODE" + +if [ ! -d "$TMP_DIR/$SKILLS_SRC" ]; then + log_warn "上游仓库中不存在技能目录: $SKILLS_SRC" + exit 1 +fi # ---------- 统计变更 ---------- NEW=0 @@ -85,10 +134,28 @@ for tpl_file in "$TMP_DIR/$SKILLS_SRC"/*.template "$TMP_DIR/$SKILLS_SRC"/*.md; d fi done +# 安装项目根目录引导文件 +guide_src_path="$TMP_DIR/$GUIDE_SRC" +if [ -f "$guide_src_path" ]; then + if [ ! -f "$GUIDE_DST" ]; then + cp "$guide_src_path" "$GUIDE_DST" + log_info "✨ 新增项目引导: $GUIDE_DST" + NEW=$((NEW + 1)) + elif ! diff -q "$guide_src_path" "$GUIDE_DST" >/dev/null 2>&1; then + cp "$GUIDE_DST" "$GUIDE_DST.local.bak" + cp "$guide_src_path" "$GUIDE_DST" + log_warn "🔄 更新项目引导: $GUIDE_DST （本地版本已备份为 ${GUIDE_DST}.local.bak）" + UPDATED=$((UPDATED + 1)) + else + SKIPPED=$((SKIPPED + 1)) + fi +fi + # ---------- 汇总 ---------- echo "" log_title "✅ 完成！" echo "" +echo " 🧭 模式: $MODE" echo " 📁 目标目录: $TARGET" echo " 📦 版本: $VERSION" echo ""