菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when the user needs DevOps or SRE help including CI/CD pipelines, Docker optimization, Kubernetes manifests, infrastructure safety, or production log analysis.
Use when the user needs expert Python engineering help including code review, performance profiling, pytest generation, package scaffolding, or static type guidance.
Use when the user needs DevOps or SRE help including CI/CD pipelines, Docker optimization, Kubernetes manifests, infrastructure safety, or production log analysis.
Use when the user needs expert Python engineering help including code review, performance profiling, pytest generation, package scaffolding, or static type guidance.
Use when debugging complex issues involving multiple modalities (frontend + backend, API + UI, terminal + browser). Coordinates Hermes Agent's built-in debugger, browser, terminal, and vision tools for systematic root-cause analysis.
Use when implementing logic, fixing bugs, or changing behavior. Enforces strict RED-GREEN-REFACTOR cycle with the test pyramid (80/15/5) and Beyonce Rule — tests before code, always.
| name | requirement-analyzer |
| description | 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. |
| triggers | ["requirement","需求","需求分析","clarify","interview","澄清","what should I build","我该做什么","vague","模糊"] |
| version | 1.0.0 |
| author | Ow1onp |
软件开发最大的浪费来源于需求不清。本技能在编写任何代码之前，通过结构化的多轮对话，将模糊的用户意图转化为明确、可执行的需求文档。核心理念：宁可在需求阶段多花 20 分钟，也不要在编码阶段浪费 2 小时。
融入 Hermes Agent 的持久记忆能力——跨会话保持需求上下文，即使隔天继续，也不丢失已澄清的约束。
第一轮：目标与范围 (Goal & Scope)
├─ 这个功能/项目的最终目标是什么？
├─ 谁会使用它？在什么场景下？
└─ 成功的定义是什么？(可量化指标)
第二轮：约束与边界 (Constraints & Boundaries)
├─ 技术栈限制？(语言、框架、平台)
├─ 性能要求？(响应时间、吞吐量)
├─ 安全/合规要求？
└─ 明确 "不做什么" (Out of Scope)
第三轮：数据与接口 (Data & Interfaces)
├─ 输入是什么？格式？来源？
├─ 输出是什么？格式？目标？
├─ 需要集成哪些外部系统？
└─ 数据量级估计？
第四轮：异常与边缘 (Edge Cases & Errors)
├─ 输入为空/非法时怎么办？
├─ 依赖服务不可用时怎么办？
├─ 并发/竞态条件如何处理？
└─ 用户最可能犯的 3 个错误是什么？
第五轮：优先级与分期 (Priority & Phasing)
├─ 哪些是 MVP 必须有的？
├─ 哪些可以 v1.1 / v2.0 再做？
└─ 有没有 20% 工作量带来 80% 价值的切入点？
# 在 Hermes 会话中直接加载本技能
/skill requirement-analyzer
# 需求分析结果自动保存到 Hermes 记忆
# 下次会话可通过记忆回溯已澄清的约束
# Hermes 会使用 memory 工具保存关键需求结论
技能执行完毕后，自动触发以下自学习流程：
triggers 列表可通过 Hermes 的 /curator run 触发技能优化审查。
读取 Hermes 的 SOUL.md 身份配置（如果存在），根据 Agent 的人设调整沟通风格：
任务完成前必须通过以下检查点：
| 借口 | 反驳 |
|---|---|
| "这个需求很简单，不需要分析" | 历史上 80% 的返工源于 "简单" 需求的隐性假设不一致。花 5 分钟写下来能省 5 小时。 |
| "用户没说清楚，我先猜着做" | 猜测是浪费的根源。使用 clarify 工具向用户提问，比猜错了重做高效 10 倍。 |
| "我是 AI，不需要问这么多" | 正因为是 AI，才更需要结构化澄清——你没有人类的直觉来填补空白。 |
| "等做完再回头改需求文档" | 需求文档不是事后记录，而是事前的灯塔。没有灯塔的航行注定偏航。 |
| "问了太多问题用户会烦" | 用户更烦的是交付了一个不是他们想要的东西。每轮问题不超过 3 个，保持聚焦。 |