starmen1265/ChildHood
1
0
Fork 0
Code Issues 11 Pull Requests Actions Packages Projects 2 Releases Wiki Activity

config(commands): 重构PM工作流，新增/pmstart替代/zqstart，精简PM Agent和/plan职责

Browse Source
This commit is contained in:
DESKTOP-2K5TJI4\admin
2026-06-03 19:10:34 +08:00
parent 2dce98662f
commit 487249e34e
4 changed files with 167 additions and 75 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.claude/agents/game-project-pm.md
+6 -17
View File
@@ -1,6 +1,6 @@
---
name: "game-project-pm"
description: "Use this agent when you need to manage project plans, track milestones, prioritize tasks, coordinate between design/programming/art roles, discuss roadmap adjustments, or execute project management workflows for the ChildHood UE5 game project. This includes planning sessions, progress reviews, task breakdown, and multi-role coordination.\\n\\nExamples:\\n\\n<example>\\nContext: The user wants to start a planning session to discuss what to work on next.\\nuser: \"/plan 我们接下来应该做什么？\"\\nassistant: \"让我启动 PM 代理来综合三个角色视角讨论优先级和目标调整。\"\\n<commentary>\\nSince the user is initiating a planning discussion, use the Agent tool to launch the game-project-pm agent to facilitate multi-role planning and priority discussion.\\n</commentary>\\n</example>\\n\\n<example>\\nContext: The user wants to update the roadmap after completing a milestone.\\nuser: \"我们完成了第一个里程碑，更新一下路线图和当前计划\"\\nassistant: \"让我启动 PM 代理来更新进度文档和路线图。\"\\n<commentary>\\nSince the user wants to update project tracking documents, use the Agent tool to launch the game-project-pm agent to update current.md and roadmap.md.\\n</commentary>\\n</example>\\n\\n<example>\\nContext: The user wants to break down a feature into manageable tasks.\\nuser: \"把校园探索系统的开发拆解成具体任务\"\\nassistant: \"让我启动 PM 代理来拆解任务并制定执行计划。\"\\n<commentary>\\nSince the user needs task breakdown and planning, use the Agent tool to launch the game-project-pm agent to create a structured task list with role assignments.\\n</commentary>\\n</example>\\n\\n<example>\\nContext: The user wants to review overall progress and identify blockers.\\nuser: \"看看我们目前进度怎么样，有什么问题\"\\nassistant: \"让我启动 PM 代理来审查当前进度并识别风险。\"\\n<commentary>\\nSince the user wants a progress review, use the Agent tool to launch the game-project-pm agent to assess status across all roles and flag issues.\\n</commentary>\\n</example>"
description: "Use this agent for deep PM discussions that benefit from persistent memory — weighing tradeoffs, analyzing risks, reviewing historical decisions, or answering project management questions for the ChildHood UE5 game project.\\n\\nFor routine work sessions, use `/pmstart` instead. For structured quality gate reviews and pipeline diagnosis, use `/plan` instead.\\n\\nExamples:\\n\\n<example>\\nContext: The user wants to weigh two competing priorities.\\nuser: \"你觉得先做弹珠小游戏还是先做时间系统？\"\\nassistant: \"让我启动 PM 代理来综合分析两个方向的依赖和收益。\"\\n<commentary>\\nThe user needs a PM's judgment call weighing tradeoffs — this benefits from the PM agent's memory of past decisions and project context.\\n</commentary>\\n</example>\\n\\n<example>\\nContext: The user wants to understand why a past quality gate failed.\\nuser: \"上次执行案质量门为什么没过？\"\\nassistant: \"让我启动 PM 代理，利用记忆回顾上次审查的具体问题。\"\\n<commentary>\\nThe user is asking about historical context stored in the PM agent's memory.\\n</commentary>\\n</example>\\n\\n<example>\\nContext: The user wants to assess scope creep risk.\\nuser: \"v0.2 的范围会不会太大？\"\\nassistant: \"让我启动 PM 代理来分析范围蔓延风险。\"\\n<commentary>\\nScope analysis is a PM judgment call that benefits from the agent's accumulated project knowledge.\\n</commentary>\\n</example>"
model: opus
color: green
memory: project
@@ -32,24 +32,13 @@ You are an experienced game project manager (PM) specializing in indie game deve
- **识别风险**：发现延期风险、依赖阻塞、范围蔓延等问题及时预警
- **里程碑检查**：对照 `docs/plans/roadmap.md` 检查里程碑达成情况
### 4. /plan 命令工作流
### 4. 与技能的关系
当用户触发 `/plan` 相关讨论时，执行以下流程：
日常 PM 工作通过两个技能完成，本 Agent 不重复这些流程：
1. **现状评估**：读取 `docs/plans/current.md` 和 `docs/plans/roadmap.md`，了解当前进度
2. **三角色分析**：
- 策划视角：哪些设计文档需要补充/更新？玩法和数值是否需要调整？
- 程序视角：技术架构是否合理？有哪些技术债务？系统能否按时实现？
- 美术视角：美术资产是否就绪？风格是否统一？是否有资产瓶颈？
3. **综合建议**：基于三角色分析，给出优先级排序和下一步建议
4. **计划更新**：经开发者确认后，更新 `docs/plans/current.md`
### 5. /zqstart 命令工作流
当用户触发启动流程时：
1. 展示 `docs/plans/current.md` 中的当前进度
2. 列出待办任务和优先级
3. 提示开发者选择任务开始
- **`/pmstart`**：每次工作的主入口。执行 git 同步、检查更新、展示待办、建议下一步。建议开发者每次工作前先用 `/pmstart`。
- **`/plan`**：深度审查工具。执行流水线诊断、质量门审查、风险检测、文档更新。当 `/pmstart` 建议审查时使用。
- **本 Agent**：用于需要 PM 记忆的深度讨论——权衡取舍、分析风险、回顾历史决策等。通过 `/agents` 手动启动。
## 工作原则
.claude/commands/plan.md
+14 -26
View File
@@ -1,7 +1,9 @@
# /plan — 计划模式（游戏项目经理）
# /plan — 深度项目审查
进入**项目经理**角色，主动诊断项目状态、梳理优先级、规划下一步工作。
深度审查项目状态：流水线诊断、质量门审查、风险检测、文档更新。
> **定位**：本命令是深度审查工具，通常由 `/pmstart` 建议触发，也可手动调用。日常启动请先用 `/pmstart`。
>
> **背景知识**：本命令基于 [`docs/development-workflow.md`](../../docs/development-workflow.md) 中定义的版本开发流水线和质量门。PM 必须先读取该文档了解完整的流水线定义、角色职责、产出标准和质量检查规则，再执行本命令的步骤。
---
@@ -22,25 +24,11 @@ PM 的核心价值不是汇报状态，而是**主动发现问题、预判风险
## 执行步骤
### 步骤 0：同步远端
1. 执行 `git pull origin <当前分支名>` 拉取远端最新内容
2. **如果有更新**：
a. 查看提交记录和变更文件列表（`git log --oneline -5` 和 `git diff HEAD~N --stat`）
b. Review 更新内容，评估对当前任务清单的影响：
- 其他角色是否提交了新产出？是否需要进入质量门审查？
- 是否有新的设计文档、技术方案或美术资产？
- 已完成的任务是否需要更新标记？
- 任务优先级是否需要调整？
c. 如有影响，更新 `docs/plans/current.md` 中的任务清单
d. 向开发者简要汇报：远端更新了什么、todo 是否有调整
3. **如果没有更新**：直接继续下一步
### 步骤 1：读取背景知识
### 步骤 0：读取背景知识
读取 `docs/development-workflow.md`，掌握当前定义的流水线阶段、质量门标准和角色产出要求。
### 步骤 2：扫描项目上下文
### 步骤 1：扫描项目上下文
扫描以下位置，全面了解项目实际状态：
@@ -53,7 +41,7 @@ PM 的核心价值不是汇报状态，而是**主动发现问题、预判风险
| 程序产出 | `docs/technical/`、`Source/`、`Content/` | 技术方案、代码、蓝图 |
| 美术产出 | `docs/art/`、`Content/` | 风格指南、资产 |
### 步骤 3：判断当前流水线阶段
### 步骤 2：判断当前流水线阶段
对照 `docs/development-workflow.md` 中的「PM 诊断检查清单」，按顺序逐项检查，**定位当前版本处于流水线的哪个阶段**。
@@ -62,7 +50,7 @@ PM 的核心价值不是汇报状态，而是**主动发现问题、预判风险
- **流水线产出缺失**：某阶段的文档/资产不存在 → 该阶段是当前应推进的工作
- **PM 质量门未通过**：产出存在但质量不达标 → 需要退回对应角色修改
### 步骤 4：质量门审查（如适用）
### 步骤 3：质量门审查（如适用）
如果当前阶段涉及 PM 质量门（执行案质量门 / 程序设计质量门 / 美术资产验收门），执行审查：
@@ -99,7 +87,7 @@ PM 的核心价值不是汇报状态，而是**主动发现问题、预判风险
2. [具体问题描述]
```
### 步骤 5：诊断与建议
### 步骤 4：诊断与建议
基于流水线判断和审查结果，产出诊断和建议：
@@ -116,11 +104,11 @@ PM 的核心价值不是汇报状态，而是**主动发现问题、预判风险
3. 如果当前流水线阶段的前置条件未满足 → 先补齐前置
4. 建议一个具体的执行顺序（本次开发 session 该做什么）
### 步骤 6：更新 PM 文档
### 步骤 5：更新 PM 文档
根据诊断结果，按需更新以下文档：
#### 6a. 更新 `docs/plans/current.md`
#### 5a. 更新 `docs/plans/current.md`
**更新时机**：每次 `/plan` 调用后，根据确认的诊断结果更新。
@@ -158,7 +146,7 @@ PM 的核心价值不是汇报状态，而是**主动发现问题、预判风险
- 开发者确认后，由 PM 勾选
- 每项任务标注对应的流水线阶段（①~⑦）
#### 6b. 更新 `docs/plans/roadmap.md`
#### 5b. 更新 `docs/plans/roadmap.md`
**更新时机**：
- 初始创建：全局设计案基本成型后
@@ -193,13 +181,13 @@ PM 的核心价值不是汇报状态，而是**主动发现问题、预判风险
（待前一版本完成后详细规划）
```
#### 6c. 写入 `docs/plans/review-log.md`
#### 5c. 写入 `docs/plans/review-log.md`
**更新时机**：每次执行质量门审查时。
按时间倒序追加审查记录。格式见步骤 4。
### 步骤 7：输出并互动
### 步骤 6：输出并互动
**输出格式**：每次 `/plan` 调用后，按以下结构输出：
.claude/commands/pmstart.md
+147
View File
@@ -0,0 +1,147 @@
# /pmstart — 项目启动入口
每次工作会话的起点。执行 git 同步、检查更新、展示待办、建议下一步。
> **定位**：轻量快速入口，可在对话中途随时触发。深度审查请使用 `/plan`。
---
## 执行步骤
### Step 0：加载上下文
1. 执行 `git pull origin <当前分支名>` 拉取远端最新内容
2. 执行 `git status --short --branch` 获取分支名、同步状态和工作区变更
3. 执行 `git log --oneline -5` 查看最近 5 条提交记录
4. 读取 `docs/GIT-GUIDE-LITE.md`，将其中 Git 规范作为本次会话的操作依据
记录 pull 结果，用于 Step 1 判断。
### Step 1：检查更新
根据 Step 0 的 pull 结果判断：
- **无远端更新**（Already up to date）→ 跳到 **Step 3**
- **有远端更新** → 进入 **Step 2**
### Step 2：Review 更新内容
**2a. 列出变更摘要**
查看提交记录和变更文件列表：
- `git log --oneline <旧HEAD>..HEAD` 查看新提交
- `git diff <旧HEAD>..HEAD --stat` 查看变更文件列表
- 按角色归类变更（策划产出 / 程序产出 / 美术产出 / 计划文档 / 其他）
**2b. 评估影响**
对照 `docs/plans/current.md` 中的任务清单，评估：
1. **新产出**：其他角色是否提交了新的产出文件？（设计文档、技术方案、美术资产）
2. **质量门触发**：新产出是否处于需要 PM 审查的阶段？如果需要 → 标记为「建议使用 `/plan` 进行审查」
3. **进度标记**：已完成的任务是否需要更新 `[ ]` → `[x]`？
4. **优先级调整**：任务优先级是否需要因新产出而调整？
**2c. 决策**
- **不需要修改 current.md** → 输出变更摘要，跳到 **Step 3**
- **需要修改 current.md** → 进入 **2d**
**2d. 展示拟定变更，等用户确认**
向用户展示：
1. 远端更新了什么（按角色归类）
2. 建议对 `current.md` 做哪些修改（具体到每一行的增/删/改）
3. 如果涉及质量门审查，建议后续使用 `/plan`
等待用户反馈：
| 用户反馈 | 处理 |
|----------|------|
| **确认** | 按拟定内容更新 `current.md` → 提议提交并推送到远端 |
| **有其他想法** | 按用户的想法修改 → 提议提交并推送到远端 |
提交推送后，继续 **Step 3**。
### Step 3：展示 TODO + 建议下一步
1. 读取 `docs/plans/current.md`，展示未完成任务（仅 `[ ]` 未勾选项）
2. 读取 `docs/development-workflow.md`，判断当前流水线阶段
3. 综合分析后给出建议：
- 接下来由**哪个角色**做什么**具体任务**（附理由）
- 如果需要深度审查（质量门、流水线诊断）→ 建议使用 `/plan`
- 给出具体命令建议
---
## 输出格式
### 标准输出（无更新 或 无需修改）
```markdown
## 📡 同步状态
**分支**: main ↑ synced
**工作区**: 干净 / 有 N 个未提交修改
**最近提交**:
- `abc1234` commit message 1
- `def5678` commit message 2
- ...
## 📋 当前 TODO
**流水线阶段**: ④执行案（①②③基本就绪）
- [ ] 任务1 — ④执行案
- [ ] 任务2 — ④执行案
- ...
## 🎯 建议下一步
**建议角色**: [策划/程序/美术]
**建议任务**: [具体任务描述]
**理由**: [为什么是这个任务]
**命令**: `/design` 或 `/dev` 或 `/art`
```
### 有更新需确认时的输出
```markdown
## 📡 同步状态
**分支**: main ↑ pulled (N new commits)
**工作区**: 干净
### 📥 远端更新摘要
**策划产出**:
- 新增 `docs/design/systems/interaction-system-execution.md`
- 更新 `docs/design/systems/collection-system.md`
**其他**:
- ...
### 📝 建议更新 current.md
1. 将 `[ ] 产出交互系统执行案` → `[x]` （文件已存在）
2. 新增任务：`[ ] 执行案质量门审查` （执行案阶段完成，需审查）
3. ⚠️ 建议：执行案已就绪，建议使用 `/plan` 进行质量门审查
---
等待确认后执行更新和推送。
```
---
## Git 操作规范（来自 GIT-GUIDE-LITE.md）
以下规范在本次会话中自动生效，后续所有 Git 操作必须遵守：
- **分支策略**：轻量 Feature Branch。从 `main` 切出 `feature/`、`fix/`、`prototype/` 分支开发，完成后合并回 `main` 并删除。`main` 永远可玩可编译。
- **分支命名**：`<类型>/<小写连字符描述>`，如 `feature/player-movement`、`fix/camera-clipping`
- **提交格式**：`<type>(<scope>): <中文描述>`，subject ≤ 50 字符
- **Type**：`feat` `fix` `art` `level` `audio` `bp` `refactor` `config` `docs` `wip`
- **Scope**（可选）：`player` `enemy` `combat` `ui` `camera` `inventory` `dialogue` `quest` `save` `audio` `animation` `ai` `level` `vfx`
- **UE5**：蓝图与 C++ 分开提交；`.uasset`/`.umap` 无法 diff，commit message 必须写清改了什么
.claude/commands/zqstart.md
-32
View File
@@ -1,32 +0,0 @@
# /zqstart — 项目状态快照
快速查看当前 Git 仓库状态，加载提交/分支规范，为开始工作提供上下文。
## 执行步骤
1. 运行 `git status --short --branch` 获取当前分支名、同步状态和工作区变更
2. 运行 `git log --oneline -3` 查看最近 3 条提交记录
3. 读取 `docs/GIT-GUIDE-LITE.md`，将其中规范作为本次会话的 Git 操作依据
4. 读取 `docs/plans/current.md`，展示当前进度摘要
## 输出格式
请按以下格式**简洁**汇总（不要输出多余信息）：
**`当前分支`** branch-name ↑↓ synced/behind/ahead
- 工作区：干净 / 有 N 个未提交修改 / 有 N 个未跟踪文件（仅列出文件名）
- 最近提交：列出 3 条（哈希 + 消息），无多余表格装饰
- 当前进度：列出 current.md 中的进行中和待开始项（仅 `[ ]` 未勾选项），不展示已完成项
---
## Git 操作规范（来自 GIT-GUIDE-LITE.md）
以下规范在本次会话中自动生效，后续所有 Git 操作必须遵守：
- **分支策略**：轻量 Feature Branch。从 `main` 切出 `feature/`、`fix/`、`prototype/` 分支开发，完成后合并回 `main` 并删除。`main` 永远可玩可编译。
- **分支命名**：`<类型>/<小写连字符描述>`，如 `feature/player-movement`、`fix/camera-clipping`
- **提交格式**：`<type>(<scope>): <中文描述>`，subject ≤ 50 字符
- **Type**：`feat` `fix` `art` `level` `audio` `bp` `refactor` `config` `docs` `wip`
- **Scope**（可选）：`player` `enemy` `combat` `ui` `camera` `inventory` `dialogue` `quest` `save` `audio` `animation` `ai` `level` `vfx`
- **UE5**：蓝图与 C++ 分开提交；`.uasset`/`.umap` 无法 diff，commit message 必须写清改了什么