Requirement analyzer

Skill Ow1onp/hermes-agent-skills/skills/define/requirement-analyzer

Production-grade skills for Hermes Agent - self-evolving, persona-aware, slash-command native

Install

npx -y skills add Ow1onp/hermes-agent-skills --skill requirement-analyzer

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use when the user presents a vague, ambiguous, or underspecified task. Conducts structured multi-turn dialogue to extract true requirements with ~95% clarity before any code is written.

SKILL.md

4.4 KB, as published. Nobody here has run it

需求分析器 (Requirement Analyzer)

1. 概述

软件开发最大的浪费来源于需求不清。本技能在编写任何代码之前，通过结构化的多轮对话，将模糊的用户意图转化为明确、可执行的需求文档。核心理念：宁可在需求阶段多花 20 分钟，也不要在编码阶段浪费 2 小时。

融入 Hermes Agent 的持久记忆能力——跨会话保持需求上下文，即使隔天继续，也不丢失已澄清的约束。

2. 核心流程

2.1 五轮需求澄清框架

第一轮：目标与范围 (Goal & Scope)
  ├─ 这个功能/项目的最终目标是什么？
  ├─ 谁会使用它？在什么场景下？
  └─ 成功的定义是什么？(可量化指标)

第二轮：约束与边界 (Constraints & Boundaries)
  ├─ 技术栈限制？(语言、框架、平台)
  ├─ 性能要求？(响应时间、吞吐量)
  ├─ 安全/合规要求？
  └─ 明确 "不做什么" (Out of Scope)

第三轮：数据与接口 (Data & Interfaces)
  ├─ 输入是什么？格式？来源？
  ├─ 输出是什么？格式？目标？
  ├─ 需要集成哪些外部系统？
  └─ 数据量级估计？

第四轮：异常与边缘 (Edge Cases & Errors)
  ├─ 输入为空/非法时怎么办？
  ├─ 依赖服务不可用时怎么办？
  ├─ 并发/竞态条件如何处理？
  └─ 用户最可能犯的 3 个错误是什么？

第五轮：优先级与分期 (Priority & Phasing)
  ├─ 哪些是 MVP 必须有的？
  ├─ 哪些可以 v1.1 / v2.0 再做？
  └─ 有没有 20% 工作量带来 80% 价值的切入点？

2.2 Hermes 命令体系集成

# 在 Hermes 会话中直接加载本技能
/skill requirement-analyzer

# 需求分析结果自动保存到 Hermes 记忆
# 下次会话可通过记忆回溯已澄清的约束
# Hermes 会使用 memory 工具保存关键需求结论

2.3 自进化机制

技能执行完毕后，自动触发以下自学习流程：

记录对话深度：统计本次需求澄清的轮数和覆盖率
识别遗漏模式：如果项目后期因需求不清而返工，分析是哪个维度的澄清不足
优化提问模板：针对项目领域（Web/ML/嵌入式等）调整默认提问集
更新触发词：根据用户实际使用的触发短语扩展 triggers 列表

可通过 Hermes 的 /curator run 触发技能优化审查。

2.4 身份感知 (SOUL.md)

读取 Hermes 的 SOUL.md 身份配置（如果存在），根据 Agent 的人设调整沟通风格：

如果 SOUL.md 定义 Agent 为 "严谨的架构师" → 输出更正式的结构化文档
如果 SOUL.md 定义 Agent 为 "敏捷教练" → 输出更口语化、迭代式的需求卡片
如果 SOUL.md 不存在 → 使用默认中立的分析师语气

3. 门禁标准

任务完成前必须通过以下检查点：

五个维度（目标/约束/数据/异常/优先级）至少各有一个明确回答
"不做什么" (Out of Scope) 已明确列出并得到用户确认
成功的可量化指标已定义（如"页面加载 < 200ms"而非"要快"）
至少识别了 3 个边缘情况
需求文档已保存到项目目录或 Hermes 记忆中
用户明确表示 "需求已清晰，可以开始编码"

4. 常见逃避借口与反驳

借口	反驳
"这个需求很简单，不需要分析"	历史上 80% 的返工源于 "简单" 需求的隐性假设不一致。花 5 分钟写下来能省 5 小时。
"用户没说清楚，我先猜着做"	猜测是浪费的根源。使用 `clarify` 工具向用户提问，比猜错了重做高效 10 倍。
"我是 AI，不需要问这么多"	正因为是 AI，才更需要结构化澄清——你没有人类的直觉来填补空白。
"等做完再回头改需求文档"	需求文档不是事后记录，而是事前的灯塔。没有灯塔的航行注定偏航。
"问了太多问题用户会烦"	用户更烦的是交付了一个不是他们想要的东西。每轮问题不超过 3 个，保持聚焦。