agentsclimarketplace

Requirements analysis

Skill RainLib/full-stack-skill/.claude/skills/requirements-analysis

从产品原型或用户描述中梳理功能点与细节要求,产出结构化需求文档。全栈工作流第 1 阶段。From its SKILL.md

Install
npx -y skills add RainLib/full-stack-skill --skill requirements-analysis

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

  • 0 stars0 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.

SKILL.md

4.6 KB, ~1.7k tokens by cl100k_base, as published. Nobody here has run it

需求分析

何时使用

  • 用户描述了产品想法、提供了原型文档或需求草稿,需要整理成可执行需求时。
  • 全栈工作流第 1 阶段,由编排器调用。

与用户交流(必须)

本阶段在主对话中执行,需与用户多轮对话,不得臆造需求。

交互原则

  • 对模糊点必须用 1~3 轮提问补全,等待用户回复后再写入文档
  • 所有决策点都应以结构化选项呈现,让用户选择而非自由输入。例如向用户提供编号选项("请选择 1/2/3"),可同时选多个时说明"可多选"。
  • 允许用户在选项之外补充说明(如选了"其他"后追加描述)。
  • 一次不要问超过 3 个问题,避免用户信息过载。

执行要点

  1. 原型/文档识别:若用户提供了产品原型截图、PRD 文档或草稿,先提取其中的功能描述与页面流程。
  2. 功能点梳理:按「功能模块 → 功能点」提取列表,不遗漏、不臆造。每个功能点含简要描述与输入输出。
  3. 用户故事:核心功能点转写为用户故事格式(As a ... I want ... So that ...)。
  4. 验收标准:每个功能点附 1~3 条验收标准(Given/When/Then 或要点式)。
  5. 细节追问:对模糊点(角色、边界、数据来源、异常情况)用 1~3 轮简短提问补全,等待用户回复后再写入
  6. 输出格式:使用 templates/requirements-template.md 填写并产出需求文档。

结构化提问引导

以下每组为一轮提问。每轮向用户呈现结构化选项,用户选择后再进入下一轮。

第 1 轮:基础信息

向用户确认以下内容(可合并为一组选项):

Q1 — 是否有原型图或设计稿?

  • A. 有(原型图/设计稿/Figma 链接等)
  • B. 有参考网站或竞品
  • C. 都没有,从零开始

Q2 — 项目涉及哪些端?

  • A. 前端 + 后端(全栈)
  • B. 仅前端
  • C. 仅后端

Q3 — 用户角色?(可多选)

  • A. 仅单角色(无权限区分)
  • B. 普通用户 + 管理员
  • C. 多角色(3 种及以上),请简要说明

第 2 轮:前端 UI/UX 偏好(Q1 选 C 时必问)

若用户没有原型图/设计稿,向用户呈现以下选项:

Q4 — 整体风格?

  • A. 现代简约(参考 Linear / Notion)
  • B. 商务正式(参考企业后台)
  • C. 科技感 / 仪表盘风格
  • D. 其他(请补充或提供参考网站)

Q5 — 主色调?

  • A. 蓝色系
  • B. 绿色系
  • C. 紫色系
  • D. 暗色系(深色背景)
  • E. 其他(请说明色值或偏好)

Q6 — 布局方式?

  • A. 侧边栏导航(左侧菜单 + 右侧内容)
  • B. 顶部导航栏
  • C. 无导航(单页/落地页)
  • D. 其他

Q7 — 响应式需求?

  • A. 仅桌面端
  • B. 桌面 + 平板
  • C. 全端适配(桌面 + 平板 + 手机)
  • D. 移动端优先

Q8 — 是否需要暗色模式?

  • A. 需要
  • B. 不需要
  • C. 后续再说

第 3 轮:后端架构偏好(项目涉及后端且未明确时必问)

Q9 — API 风格?

  • A. RESTful
  • B. GraphQL
  • C. 无偏好,你来推荐

Q10 — 认证方式?

  • A. JWT(无状态)
  • B. Session(有状态)
  • C. OAuth2 第三方登录
  • D. 暂不需要认证

Q11 — 数据库偏好?

  • A. MySQL
  • B. PostgreSQL
  • C. MongoDB
  • D. SQLite(轻量/嵌入式)
  • E. 无偏好

Q12 — 是否需要 API 文档自动生成(Swagger/OpenAPI)?

  • A. 需要
  • B. 不需要
  • C. 后续再说

第 4 轮:补充确认

根据用户前面的回答,对仍有模糊的业务流程、异常分支、非功能需求进行针对性追问。此轮可使用开放式问题。

辅助资料

  • 完整示例输出:examples/sample-output.md — 展示一份合格需求文档的完整结构与内容深度
  • 编写参考:reference.md — 用户故事 INVEST 原则、验收标准写法、常见追问清单

产出

  • 一份按模板填写的需求文档,供「技术选型」与后续阶段使用。

文档与状态

  • 产出写入 docs/{current_iteration_id}/requirements-{requirements_id}.md
  • 开始前:调用 history-manager skill 的 get-phase requirementscheck-file 确认是否已完成。
  • 完成后:调用 history-manager skill 的 set-phase requirements {requirements_id} 记录并推进状态。

What ships with it: 3 files

9.6 KB alongside SKILL.md

examples/

templates/

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.