Requirements analysis

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

full-stack development lifecycle

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.

What its author says it does

Copied from the file, not written here

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

SKILL.md

4.6 KB, as published. Nobody here has run it

需求分析

何时使用

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

与用户交流（必须）

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

交互原则

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

执行要点

原型/文档识别：若用户提供了产品原型截图、PRD 文档或草稿，先提取其中的功能描述与页面流程。
功能点梳理：按「功能模块 → 功能点」提取列表，不遗漏、不臆造。每个功能点含简要描述与输入输出。
用户故事：核心功能点转写为用户故事格式（As a ... I want ... So that ...）。
验收标准：每个功能点附 1～3 条验收标准（Given/When/Then 或要点式）。
细节追问：对模糊点（角色、边界、数据来源、异常情况）用 1～3 轮简短提问补全，等待用户回复后再写入。
输出格式：使用 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 requirements 和 check-file 确认是否已完成。
完成后：调用 history-manager skill 的 set-phase requirements {requirements_id} 记录并推进状态。