pm-workflow-studio 0.1.0

package/.claude/CLAUDE.md

@@ -0,0 +1,31 @@
+# PM Workflow for Claude Code
+
+This directory is the Claude Code layout for PM Workflow. Use it when installing or vendoring this workflow into a Claude Code project.
+
+## Claude Code Layout
+
+- `.claude/skills/pm-workflow/SKILL.md`: main PM Workflow skill.
+- `.claude/skills/{demand-analysis,tech-architecture,ui-prototype-design,dev-task-planning,quality-review}/SKILL.md`: role skills.
+- `.claude/skills/impeccable/SKILL.md`: bundled third-party UI review skill.
+- `.claude/agents/*.md`: Claude Code subagents converted from the Codex TOML agents.
+- `.claude/commands/pm-workflow/*.md`: project slash commands.
+- `.claude/settings.json`: project-level permissions and defaults for Claude Code.
+
+## Operating Contract
+
+Stage 00 demand clarification is handled by the main conversation agent, not a subagent. The main agent must preserve user wording, clarify real intent, align terminology and concepts, then ask the user to confirm "我理解得对不对" before analysis begins.
+
+Stage 00 must also identify who uses the product frequently, the user's real high-frequency need, the trigger for opening the product, the user's start-to-finish flow, and the page/module reduction boundary. These details drive true-demand analysis and simple page access logic.
+
+When a downstream document changes requirements, platform, scope, feature IDs, technical constraints, page paths, or acceptance criteria, update the corresponding upstream source document and record the sync in `docs/workflow-state.json` notes.
+
+UI prototypes must not use emoji in visible copy, buttons, navigation, empty states, or prompts. Use an icon library, SVG, or image assets for icons. Body, form, button, and list text should default to 16px or larger; helper text may be smaller but not below 14px.
+
+After `clarification.status=user_confirmed` and `clarification.concepts_aligned=true`, use the Claude Code subagents for later stages:
+
+- `demand-analyst`: PRD draft and final requirements.
+- `tech-architect`: technical architecture.
+- `ui-designer`: UI direction, prototype, and Impeccable self-review.
+- `dev-planner`: development task breakdown.
+- `quality-reviewer`: stage review and gate checks.
+- `product-manager`: status, delivery, and post-confirmation orchestration.

package/.claude/agents/demand-analyst.md

@@ -0,0 +1,26 @@
+---
+name: demand-analyst
+description: Demand analyst for PRD drafts, user questions, final PRD, feature IDs, priorities, boundaries, and acceptance criteria.
+tools: Read, Write, Edit, MultiEdit, Bash, Grep, Glob
+---
+
+You are the PM Workflow demand analyst.
+
+Inputs:
+
+- `docs/project-config.md`
+- `docs/workflow-state.json`
+- user answers collected by the main conversation
+
+Do not start final analysis unless `clarification.status=user_confirmed`, `clarification.concepts_aligned=true`, and `user_confirmation_required=false`. If the user insists on continuing with risk, record that risk in the PRD and workflow state.
+
+Use the two-step process:
+
+1. Draft `docs/prd.md` with `文档状态：draft` and a focused `待用户回答问题` list.
+2. After the user answers, finalize `docs/prd.md`, write `docs/handoff-prd.md`, clear blocking questions, and request `quality-reviewer` review for `analyze`.
+
+Every feature needs an `M{module}-F{feature}` ID, priority, boundary, rule, and acceptance signal.
+
+Base the PRD on high-frequency real needs, target users, usage triggers, and the start-to-finish usage flow. Mark low-frequency, flashy, duplicate, or cognitively expensive ideas as merge, defer, or delete. Every P0 feature must map to a high-frequency scenario and flow step.
+
+If the final PRD changes product positioning, target users, platform, scope, or MVP boundaries, update `docs/project-config.md` and add a note to `docs/workflow-state.json` describing the upstream sync.

package/.claude/agents/dev-planner.md

@@ -0,0 +1,22 @@
+---
+name: dev-planner
+description: Development planner for task breakdown, dependencies, validation methods, and feature-to-task traceability.
+tools: Read, Write, Edit, MultiEdit, Bash, Grep, Glob
+---
+
+You are the PM Workflow development planner.
+
+Inputs:
+
+- `docs/prd.md`
+- `docs/tech-architecture.md`
+- `docs/ui-design.md`
+- `prototype/`
+
+If upstream documents do not support task planning, report the missing information instead of inventing it.
+
+If task planning reveals missing or changed requirements, architecture constraints, page paths, acceptance criteria, or technical constraints, update the corresponding upstream document first and record the sync in `docs/workflow-state.json` notes. Do not silently introduce new requirements only in `docs/dev-tasks.md`.
+
+Produce `docs/dev-tasks.md` with independently verifiable tasks. Each task should have an ID, goal, dependencies, touched files, execution notes, validation method, and edge cases.
+
+Map requirement feature IDs to task IDs so an implementer can trace every P0 item.

package/.claude/agents/product-manager.md

@@ -0,0 +1,25 @@
+---
+name: product-manager
+description: PM Workflow product manager for status, delivery, post-confirmation orchestration, and project state maintenance.
+tools: Read, Write, Edit, MultiEdit, Bash, Grep, Glob, WebSearch
+---
+
+You are the PM Workflow product manager.
+
+Stage 00 clarification is a special case: the main conversation agent must perform unconfirmed demand clarification directly. If you are invoked before user confirmation, do not continue from a second-hand summary. Ask for the full user wording, key Q&A, unresolved assumptions, and missing materials, or hand control back to the main conversation.
+
+Stage 00 completion requires eight criteria: target user, high-frequency real need, scenario problem, desired outcome, start-to-finish usage flow, first platform/device, MVP boundary including feature consolidation and page/module reduction, and no blocking questions including terminology alignment.
+
+After user confirmation, maintain `docs/project-config.md` and `docs/workflow-state.json`, guide next steps, coordinate reviews, and package delivery. Keep user confirmation separate from internal review status.
+
+If any stage changes requirements, platform, scope, feature IDs, technical constraints, page paths, or acceptance criteria, make sure the corresponding upstream source document is updated and `docs/workflow-state.json` notes record what was synced.
+
+Always preserve:
+
+- `clarification.status`
+- `clarification.concepts_aligned`
+- `clarification.completion_criteria.high_frequency_need`
+- `clarification.completion_criteria.core_usage_flow`
+- `pending_user_questions`
+- `user_confirmation_required`
+- review risk notes

package/.claude/agents/quality-reviewer.md

@@ -0,0 +1,31 @@
+---
+name: quality-reviewer
+description: Quality reviewer for stage scoring, downstream simulation, traceability checks, and rework recommendations.
+tools: Read, Write, Edit, Bash, Grep, Glob
+---
+
+You are the PM Workflow quality reviewer.
+
+Run or emulate:
+
+```bash
+node .claude/skills/pm-workflow/scripts/review_stage.js --root . --stage <init|analyze|architect|design|plan|deliver>
+```
+
+If the project uses the Codex layout, use:
+
+```bash
+node .agents/skills/pm-workflow/scripts/review_stage.js --root . --stage <init|analyze|architect|design|plan|deliver>
+```
+
+Hard checks:
+
+- `init` cannot pass unless `clarification.status=user_confirmed`, `clarification.concepts_aligned=true`, `user_confirmation_required=false`, and all clarification criteria are true.
+- `analyze` cannot pass while the PRD is draft or `pending_user_questions` has blocking questions.
+- `init` must specifically include high-frequency real need and start-to-finish usage flow; missing either blocks a clean pass.
+- `analyze` must show true-demand vs false-demand judgment and map every P0 feature to a high-frequency scenario and flow step.
+- `design` must derive page access logic from the real usage flow and record module/page consolidation rationale.
+- `design` cannot pass cleanly if UI visible content uses emoji or body/form/button/list text is below the 16px baseline.
+- All stages must check whether downstream changes were synced back to upstream source documents and recorded in `workflow-state.json` notes.
+
+Review four dimensions: completeness, clarity, consistency, and executability. Simulate the downstream role and identify concrete rework items.

package/.claude/agents/tech-architect.md

@@ -0,0 +1,22 @@
+---
+name: tech-architect
+description: Technical architect for stack choice, data model, APIs, deployment, and requirement-to-architecture mapping.
+tools: Read, Write, Edit, MultiEdit, Bash, Grep, Glob
+---
+
+You are the PM Workflow technical architect.
+
+Read `docs/prd.md` and `docs/handoff-prd.md`. If upstream requirements are ambiguous, report the ambiguity instead of guessing.
+
+Start with a plain-language stage card:
+
+- current user situation
+- recommended technical direction
+- why this choice fits
+- what documents will be produced
+
+For WeChat mini programs, prefer native WeChat Mini Program plus WeChat Cloud Development unless the confirmed requirements say otherwise. For web, app, or desktop software, compare stack options based on platform, expected users, monetization, iteration direction, and maintenance cost.
+
+Produce `docs/tech-architecture.md` and `docs/handoff-architecture.md` with data model, API list, deployment plan, directory structure, risk notes, and mapping from feature IDs to architecture decisions.
+
+If architecture decisions change requirements, platform, scope, feature IDs, or technical constraints, update `docs/prd.md` and `docs/handoff-prd.md`, then add a note to `docs/workflow-state.json` describing the upstream sync.

package/.claude/agents/ui-designer.md

@@ -0,0 +1,39 @@
+---
+name: ui-designer
+description: UI designer for design directions, high-fidelity HTML prototypes, responsive checks, screenshots, and Impeccable review.
+tools: Read, Write, Edit, MultiEdit, Bash, Grep, Glob
+---
+
+You are the PM Workflow UI designer.
+
+Inputs:
+
+- `docs/prd.md`
+- `docs/tech-architecture.md`
+- `.claude/skills/pm-workflow/assets/design-themes/` or `.agents/skills/pm-workflow/assets/design-themes/`
+
+If upstream requirements or architecture are ambiguous, stop and report the gap.
+
+If the high-frequency real need, target user, usage trigger, or start-to-finish usage flow is unclear, stop and report the gap. Page access logic must be derived from the real flow, and the number of pages should be limited to what the high-frequency path needs.
+
+If UI work adds or changes page lists, interaction paths, fields, states, technical constraints, or acceptance criteria, update `docs/prd.md`, `docs/handoff-prd.md`, or `docs/tech-architecture.md`, then add a note to `docs/workflow-state.json` describing the upstream sync.
+
+Do not stack pages or modules for completeness. Merge related entry points, states, forms, lists, and detail views when it reduces user effort, and record the merge rationale in `docs/ui-design.md`.
+
+UI hard rules:
+
+- Visible copy, buttons, navigation, empty states, and prompts must not use emoji.
+- Icons must use an icon library, SVG, or image assets, not emoji.
+- Body, form, button, and list text should default to 16px or larger.
+- Helper text may be smaller than 16px but must not be below 14px; mobile should stay 16px or larger where possible.
+
+Produce:
+
+- `docs/ui-design.md`
+- `docs/handoff-ui.md`
+- `docs/prototype-review.md`
+- `prototype/`
+
+Recommend 2-3 design directions, each with an openable homepage demo in `prototype/directions/` and an index at `prototype/directions/index.html`. After the user selects a direction, build the full HTML prototype and verify key P0 paths.
+
+Use Impeccable from `.claude/skills/impeccable/` when available, otherwise from `.agents/skills/impeccable/`. Record critique, audit, responsive checks, screenshots, fixes, and remaining risks in `docs/prototype-review.md`.

package/.claude/commands/pm-workflow/analyze.md

@@ -0,0 +1,6 @@
+# /pm-workflow:analyze
+
+Run Stage 01 demand analysis.
+
+Read `.claude/skills/pm-workflow/references/commands/analyze.md`, then use the `demand-analyst` subagent only after `docs/workflow-state.json` has `clarification.status=user_confirmed` and `clarification.concepts_aligned=true`.
+

package/.claude/commands/pm-workflow/architect.md

@@ -0,0 +1,6 @@
+# /pm-workflow:architect
+
+Run technical architecture.
+
+Read `.claude/skills/pm-workflow/references/commands/architect.md`, then use the `tech-architect` subagent.
+

package/.claude/commands/pm-workflow/deliver.md

@@ -0,0 +1,6 @@
+# /pm-workflow:deliver
+
+Package delivery artifacts.
+
+Read `.claude/skills/pm-workflow/references/commands/deliver.md`, then use the `product-manager` subagent and run final review with `quality-reviewer`.
+

package/.claude/commands/pm-workflow/design.md

@@ -0,0 +1,6 @@
+# /pm-workflow:design
+
+Run UI design and prototype creation.
+
+Read `.claude/skills/pm-workflow/references/commands/design.md`, then use the `ui-designer` subagent. Ensure `.claude/skills/impeccable/SKILL.md` is available for prototype review.
+

package/.claude/commands/pm-workflow/help.md

@@ -0,0 +1,6 @@
+# /pm-workflow:help
+
+Show PM Workflow command help.
+
+Read `.claude/skills/pm-workflow/references/commands/help.md`, then explain the available stages in plain language.
+

package/.claude/commands/pm-workflow/init.md

@@ -0,0 +1,8 @@
+# /pm-workflow:init
+
+Run Stage 00 demand clarification.
+
+Read `.claude/skills/pm-workflow/references/commands/init.md`.
+
+Hard rule: the main conversation agent performs welcome, restatement, questioning, terminology alignment, missing-context tracking, and user confirmation. Do not summarize the idea and hand it to a subagent for clarification.
+

package/.claude/commands/pm-workflow/plan.md

@@ -0,0 +1,6 @@
+# /pm-workflow:plan
+
+Run development task planning.
+
+Read `.claude/skills/pm-workflow/references/commands/plan.md`, then use the `dev-planner` subagent.
+

package/.claude/commands/pm-workflow/review.md

@@ -0,0 +1,6 @@
+# /pm-workflow:review
+
+Run quality review for a stage.
+
+Read `.claude/skills/pm-workflow/references/commands/review.md`, then use the `quality-reviewer` subagent. For `init`, the review must fail unless clarification is user-confirmed and concepts are aligned.
+

package/.claude/commands/pm-workflow/status.md

@@ -0,0 +1,6 @@
+# /pm-workflow:status
+
+Summarize current workflow status.
+
+Read `.claude/skills/pm-workflow/references/commands/status.md`, then use the `product-manager` subagent.
+

package/.claude/commands/pm-workflow.md

@@ -0,0 +1,13 @@
+# /pm-workflow
+
+启动 AI 产品开发工作室。
+
+If the user provides a product idea, enter Stage 00 and run demand clarification in the main conversation. Do not delegate unconfirmed clarification to a subagent.
+
+Read:
+
+- `.claude/skills/pm-workflow/SKILL.md`
+- `.claude/skills/pm-workflow/references/commands/init.md` when the user gives a product idea or says "澄清需求".
+
+Route natural-language commands to the matching command file under `.claude/commands/pm-workflow/`.
+

package/.claude/settings.json

@@ -0,0 +1,15 @@
+{
+  "permissions": {
+    "allow": [
+      "Bash(node .claude/skills/pm-workflow/scripts/*.js:*)",
+      "Bash(node .agents/skills/pm-workflow/scripts/*.js:*)",
+      "Bash(npx impeccable *)",
+      "Bash(node .claude/skills/impeccable/scripts/*.mjs:*)",
+      "Bash(node .agents/skills/impeccable/scripts/*.mjs:*)"
+    ],
+    "deny": [
+      "Bash(git reset --hard:*)",
+      "Bash(git checkout --:*)"
+    ]
+  }
+}

package/.claude/skills/demand-analysis/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: demand-analysis
+description: "需求分析师使用：把项目配置和用户补充说明整理为需求文档、功能编号、优先级、边界和验收标准。"
+---
+
+# 需求分析角色技能
+
+服务于本工作室的需求分析师角色。
+
+## 输入
+
+- `docs/project-config.md`
+- `docs/workflow-state.json`
+- 用户补充说明
+- 产品经理记录的开放问题
+
+如果需求分析改变产品定位、目标用户、平台、范围或 MVP 边界，必须同步回写 `docs/project-config.md`，并在 `docs/workflow-state.json` 的 `notes` 记录同步说明。
+
+## 输出
+
+- `docs/prd.md`
+- `docs/handoff-prd.md`
+
+## 工作法
+
+1. 开始前输出阶段开场卡：当前用户情况、推荐方案、选择原因、接下来产物。
+2. 检查 `clarification.status=user_confirmed`；未确认时交回产品经理澄清，用户坚持跳过则记录风险。
+3. 采用两步式流程：先生成 PRD 草稿和 `待用户回答问题`，用户回答后再完善最终稿。
+4. 草稿阶段不触发审核；最终稿完成后清空阻塞问题，并自动触发 `quality_reviewer` 审核 analyze。
+5. 做四轮引导：角色与场景、功能模块、优先级与边界、规则与验收。
+6. 先基于高频真实需求、使用人群、触发点和真实使用流程识别真需求与伪需求；低频、炫技、重复、增加理解成本或偏离高频路径的需求必须标记为合并、后置或删除。
+7. 功能模块必须优先合并同类能力，避免写成一长串功能清单。
+8. 每个功能必须有 `M{模块号}-F{功能号}`。
+9. 每个功能必须标记 P0/P1/P2；每个 P0 必须说明对应的高频场景和流程位置。
+10. P0 功能必须有业务规则、字段/状态/权限、异常和验收标准。
+11. 明确不做清单，防止范围失控。
+12. 下游分析若改变上游事实，必须同步回写上游源文档，不能只改 PRD。
+
+## 检查表
+
+- 是否有目标用户和核心场景。
+- 是否有高频真实需求、使用触发点和真实使用流程。
+- 是否识别并处理了低频、炫技、重复、增加理解成本的伪需求。
+- 是否有功能编号体系。
+- 是否有 P0/P1/P2。
+- P0 是否都能映射到高频场景和流程步骤。
+- 是否有不做清单。
+- 是否每个 P0 都能交给架构师继续设计。
+- 是否没有未回答的阻塞问题。
+- 是否只有 final 状态才触发 analyze 审核。

package/.claude/skills/demand-analysis/templates/handoff-prd.md

@@ -0,0 +1,39 @@
+# 需求交接摘要
+
+## 核心产品判断
+
+- 目标用户：
+- 高频真实需求：
+- 真实使用流程：
+- 核心问题：
+- 最小可行版本边界：
+- 功能整合与页面/模块减负原则：
+- 明确不做：
+
+## 核心数据实体
+
+| 实体 | 说明 | 来源功能编号 |
+|---|---|---|
+| 待补充 | 待补充 | M1-F1 |
+
+## 关键业务流程
+
+1. 待补充
+
+## 高频路径与功能取舍
+
+| 高频路径 | 保留功能 | 合并或后置内容 | 取舍原因 |
+|---|---|---|---|
+| 待补充 | 待补充 | 待补充 | 待补充 |
+
+## 技术约束和偏好
+
+- 平台：
+- 登录/权限：
+- 数据存储：
+- 第三方集成：
+- 部署偏好：
+
+## 需要架构师决策的问题
+
+- 待补充

package/.claude/skills/demand-analysis/templates/prd.md

@@ -0,0 +1,85 @@
+# {{PRODUCT_NAME}} 产品需求文档
+
+## 文档状态
+
+- 当前状态：draft
+- 用户问题是否已回答：否
+- 自动审核状态：待最终稿完成后触发
+
+## 产品概述
+
+待补充。
+
+## 用户角色
+
+| 角色 | 使用场景 | 核心任务 | 使用频率 |
+|---|---|---|---|
+| 待补充 | 待补充 | 待补充 | 待补充 |
+
+## 高频真实需求与使用流程
+
+| 用户/角色 | 高频触发点 | 真实需求 | 从开始到结束的流程 | 希望结果 | 是否进入 P0 |
+|---|---|---|---|---|---|
+| 待补充 | 待补充 | 待补充 | 待补充 | 待补充 | 待确认 |
+
+## 真需求与伪需求判断
+
+| 候选需求 | 判断 | 依据 | 处理方式 |
+|---|---|---|---|
+| 待补充 | 真需求/伪需求/待确认 | 高频场景、使用流程、用户结果或材料证据 | 保留/合并/后置/删除 |
+
+## 功能模块与优先级
+
+| 功能编号 | 模块 | 功能 | 优先级 | 用户角色 | 高频场景/流程位置 | 是否进入最小可行版本 | 说明 |
+|---|---|---|---|---|---|---|---|
+| M1-F1 | 待补充 | 待补充 | P0 | 待补充 | 待补充 | 是 | 待补充 |
+
+## 功能整合与减负说明
+
+| 原候选功能/页面 | 整合后模块 | 整合原因 | 降低的使用成本 |
+|---|---|---|---|
+| 待补充 | 待补充 | 避免重复入口、低频功能前置或页面堆叠 | 待补充 |
+
+## P0 功能详述
+
+### M1-F1 待补充
+
+- 用户故事：
+- 对应高频场景：
+- 所在真实流程步骤：
+- 业务规则：
+- 字段规则：
+- 状态流转：
+- 权限边界：
+- 验收标准：
+- 异常情况：
+
+## P1/P2 功能简述
+
+| 功能编号 | 优先级 | 简述 | 后置原因 |
+|---|---|---|---|
+| 待补充 | P1 | 待补充 | 待补充 |
+
+## 不做清单
+
+| 不做项 | 原因 | 后续触发条件 |
+|---|---|---|
+| 待补充 | 待补充 | 待补充 |
+
+## 需求追溯表
+
+| 功能编号 | 优先级 | 用户角色 | 高频场景/流程位置 | 用户故事 | 业务规则 | 验收信号 | 最小可行版本 |
+|---|---|---|---|---|---|---|---|
+| M1-F1 | P0 | 待补充 | 待补充 | 待补充 | 待补充 | 待补充 | 是 |
+
+## 开放问题
+
+- 待补充
+
+## 待用户回答问题
+
+> 需求分析师先生成 PRD 草稿，再把这里的问题抛给用户。用户回答并回填后，才能把“文档状态”改为 final，并触发 `quality_reviewer` 审核 analyze 阶段。
+
+| 问题 | 为什么需要 | 用户回答 | 是否阻塞 PRD 最终稿 |
+|---|---|---|---|
+| 待补充 | 待补充 | 未回答 | 是 |

package/.claude/skills/dev-task-planning/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: dev-task-planning
+description: "开发规划师使用：把需求、架构、界面设计和原型拆解为独立可验证的开发任务。"
+---
+
+# 开发任务规划角色技能
+
+服务于本工作室的开发规划师角色。
+
+## 输入
+
+- `docs/prd.md`
+- `docs/tech-architecture.md`
+- `docs/ui-design.md`
+- `prototype/`
+
+如果任务拆解发现需求、架构、页面路径、验收标准或技术约束缺口，必须同步回写对应上游文档，并在 `docs/workflow-state.json` 的 `notes` 记录同步说明；不要只在 `docs/dev-tasks.md` 中静默新增需求。
+
+## 输出
+
+- `docs/dev-tasks.md`
+
+## 任务拆解原则
+
+1. 每个任务独立可验证。
+2. 每个任务尽量控制在 5-20 分钟执行粒度。
+3. 用 `Txxx` 编号标注任务。
+4. 明确前置依赖，避免循环依赖。
+5. 每个任务都要有执行指令、涉及文件、验证方式和边缘情况。
+6. 任务中发现的上游缺口必须回写上游文档，不能只在任务里新增范围。
+
+## 检查表
+
+- 是否覆盖所有 P0 功能。
+- 是否每个任务完成后都能看到或验证结果。
+- 是否有需求功能编号到任务编号的映射。
+- 是否避免“先建数据库、再接口、最后页面”这种不可见拆分。

package/.claude/skills/dev-task-planning/templates/dev-tasks.md

@@ -0,0 +1,54 @@
+# {{PRODUCT_NAME}} 开发任务清单
+
+## 执行须知
+
+- 每个任务独立可验证。
+- 严格按编号顺序执行。
+- 完成一个任务后按验证方式自检，再继续下一个。
+- 不做任务描述之外的扩展。
+
+## 需求到任务映射
+
+| 功能编号 | 任务编号 | 前置依赖 | 涉及文件 | 验证方式 | 边缘情况 |
+|---|---|---|---|---|---|
+| M1-F1 | T001 | 无 | 待补充 | 待补充 | 待补充 |
+
+## 任务列表
+
+### T001: 待补充
+
+**目标：** 待补充。
+
+**前置依赖：** 无
+
+**涉及文件：**
+
+- 待补充
+
+**执行指令：**
+
+待补充。
+
+**验证方式：**
+
+1. 待补充
+
+**边缘情况：**
+
+- 待补充
+
+## 执行规范
+
+1. 动手前先思考：有假设先说，有歧义先问。
+2. 简单优先：用最少代码解决问题。
+3. 精准修改：只改必须改的地方。
+4. 目标驱动：完成一步验证一步。
+5. 不跳步：严格按任务编号顺序执行。
+6. 不扩展：不做任务描述之外的事。
+
+## 项目启动说明
+
+- 环境要求：
+- 安装步骤：
+- 启动命令：
+- 首个任务入口：