Claude Code Plugins

Community-maintained marketplace

Feedback

analyze

@hellowind777/helloagents
103
0

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

Install Skill

1Download skill
2Enable skills in Claude

Open claude.ai/settings/capabilities and find the "Skills" section

3Upload to Claude

Click "Upload skill" and select the downloaded ZIP file

Note: Please verify skill by going through its instructions before using it.

SKILL.md

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

需求分析 - 详细规则

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

执行流程:

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

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

阶段A: 需求评估

步骤1: 检查知识库状态

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

步骤2: 获取项目上下文

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

步骤3: 需求类型判定

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

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

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

追问规则:

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

评分维度(总分10分):

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

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

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

基于推理结果执行：

  • 评分≥7分 → 继续执行阶段B
  • 评分<7分 → 输出追问格式

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

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

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

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

示例:

❓【HelloAGENTS】- 需求分析

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

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

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

评分后处理

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

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

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

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

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

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

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

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

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

需求分析 输出格式

⚠️ CRITICAL - 强制要求:

  • ALWAYS使用G6.1统一输出格式
  • NEVER使用自由文本替代规范格式
  • 输出前MUST验证格式完整性

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

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

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

阶段转换规则

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