Analyze Pianzhu My Claude Skills

---
name: analyze
description: 需求分析阶段详细规则；进入需求分析时读取；包含需求评分、追问逻辑、代码分析步骤
---

# 需求分析 - 详细规则

**目标:** 验证需求完整性，分析代码现状，为方案设计提供基础

**执行流程:**
```
阶段A (步骤1-4) → 关键检查点: 评分≥7分?
  ├─ 是 → 执行阶段B (步骤5-6) → 输出总结
  └─ 否 → 输出追问问题 → 等待用户补充 → 重新评分或取消
```

**重要:** 评分 < 7分时，禁止执行阶段B，禁止输出总结，只能输出追问格式

---

## 阶段A: 需求评估

### 步骤1: 检查知识库状态

```yaml
判定条件: 工作目录存在代码文件 且 需求不是"新建项目"
执行方式: 按 G10 快速决策树判定，如需详细操作则读取 `../kb/SKILL.md` 执行
问题标记: 如知识库不存在/不合格，标记问题（P1只读，不创建）
```

### 步骤2: 获取项目上下文

```yaml
执行方式: 按 G10 快速流程执行（先检查知识库 → 不足则扫描代码库）
详细规则: 如需完整规则，读取 `../kb/SKILL.md`
目的: 为评分和追问提供完整项目上下文，避免低级问题
```

### 步骤3: 需求类型判定

- 判定是否触发 G8 产品设计原则（新项目/新功能/重大重构）
- 判定需求具体类型（新项目初始化、重大功能重构、常规功能开发、技术变更等）

### 步骤4: 需求完整性评分 【关键检查点】

<requirement_scoring>
**评分原则:**
- 如已完成项目上下文获取，评分时应考虑已获取的所有项目信息
- 严格评分标准: 知识库和代码扫描只能提供技术上下文，不能替代用户需求明确性
- 即使技术信息充足，如果用户需求本身模糊（如"优化代码"、"改进交互"），仍需追问

**追问规则:**
- 严格避免询问已知信息: 技术栈、框架、模块结构、可从代码推断的实现细节
- 只询问用户相关信息: 具体需求、业务逻辑、期望结果、优先级、约束条件

**评分维度(总分10分):**
- 目标明确性 (0-3分): 任务目标是否清晰具体
- 预期结果 (0-3分): 成功标准和交付物是否明确
- 边界范围 (0-2分): 任务范围和边界是否清楚
- 约束条件 (0-2分): 时间、性能、业务限制等是否说明

**评分推理过程（在 <thinking> 标签中完成，不输出给用户）：**

```
<thinking>
1. 逐项分析评分维度：
   - 目标明确性 (0-3分): [分析用户需求的目标清晰度] → [X分]
   - 预期结果 (0-3分): [分析成功标准是否明确] → [X分]
   - 边界范围 (0-2分): [分析任务范围是否清楚] → [X分]
   - 约束条件 (0-2分): [分析约束条件是否说明] → [X分]
2. 列举支持该评分的具体证据（引用用户原话）
3. 识别缺失的关键信息点
4. 计算总分: X/10分
5. 判定: [是否需要追问及理由]
</thinking>
```

**基于推理结果执行：**
- 评分≥7分 → 继续执行阶段B
- 评分<7分 → 输出追问格式
</requirement_scoring>

### 追问输出格式（评分 < 7分时）

使用统一输出格式，行首: `❓【HelloAGENTS】- 需求分析`

内容格式: 简要说明(1-2句，含当前评分) + 空行 + 扁平化问题清单(3-5个带序号) + 结束语

禁止显示: 评分维度明细、分类标题、下一步建议、文件变更

**示例:**
```
❓【HelloAGENTS】- 需求分析

当前需求完整性评分为 5/10 分，无法明确优化目标和预期效果。

1. 您要优化哪个文件或模块的代码?
2. 当前存在什么具体问题需要优化?（如性能慢、代码重复等）
3. 期望优化后达到什么效果?
4. 有具体的性能指标或时间要求吗?

请按序号回答，或输入"以现有需求继续"跳过追问（可能影响方案质量）。
```

### 评分后处理

```yaml
评分≥7分: 继续执行阶段B

评分<7分: 立即停止，输出追问，等待响应，不执行阶段B
  追问循环:
    - 用户补充 → 重新评分 → 评分≥7分则继续，评分<7分则再次追问
  用户选择处理:
    - "以现有需求继续": 直接执行阶段B（无需再次确认）
    - "取消":
      - 交互确认模式: 按G6.2输出取消格式
      - 推进模式: 清除 MODE_FULL_AUTH/MODE_PLANNING，按G6.2输出取消格式
      - 取消输出示例:
        ```
        🚫【HelloAGENTS】- 已取消

        已取消: 需求分析
        ────
        🔄 下一步: 可重新描述需求或进行其他操作
        ```
  模式处理:
    - 交互确认模式: 满足条件→阶段B→需求分析完成后需确认进入方案设计
    - 推进模式: 暂停连续执行，满足条件→阶段B→恢复静默连续执行
```

---

## 阶段B: 代码分析（仅评分≥7分后执行）

### 步骤5: 提取关键目标与成功标准

- 提取关键目标: 从完整需求中提炼核心目标
- 定义成功标准: 明确可验证的成功标准

### 步骤6: 代码分析与技术准备

```yaml
执行内容:
  - 判定项目规模（按 G4 规则）
  - 定位相关模块
  - 质量检查: 标记过时信息，扫描安全风险和代码异味
  - 问题诊断: 分析日志或错误信息（如有）
  - 技术信息收集（如需要）: 使用联网搜索或MCP工具(Context7)获取最新文档和最佳实践

输出物: 项目上下文信息（技术栈、模块结构、质量问题、技术约束）供P2方案设计使用
```

---

## 需求分析 输出格式

⚠️ **CRITICAL - 强制要求:**
- ALWAYS使用G6.1统一输出格式
- NEVER使用自由文本替代规范格式
- 输出前MUST验证格式完整性

**评分≥7分时（阶段A+B完成后输出）:**

严格调用 G6.1 统一输出格式，填充以下数据：

1. **阶段名称:** `需求分析`
2. **阶段具体内容(≤5条要点):**
   - 📋 完整需求描述(整理)
   - 🏷️ 需求类型: 技术变更/产品功能
   - 📊 需求完整性评分: X/10分
   - 🎯 关键目标与成功标准
   - 📚 知识库状态
3. **文件变更清单:**
   📁 变更: 无
4. **下一步建议:**
   - 交互确认模式: 是否进入方案设计?（是/否）
   - 推进模式: 静默进入方案设计

---

## 阶段转换规则

```yaml
评分 < 7分: 循环追问，直到评分≥7分或用户取消
评分≥7分 且 交互确认模式: 输出总结→停止→等待确认
评分≥7分 且 (MODE_FULL_AUTH=true 或 MODE_PLANNING=true): 完成需求分析→立即静默进入方案设计
```