requirements-analysis
- Repo stars 0
- Author updated Live
- Author repo full-stack-skill
- Domain
- Other
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @RainLib · no license declared
- Token usage
- Lean
- Setup complexity
- Plug-and-play
- External API key
- Not required
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Write / modify
- Network behavior
- Local-only
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: requirements-analysis
description: 本阶段在主对话中执行,需与用户多轮对话,不得臆造需求。 以下每组为一轮提问。每轮向用户呈现结构化选项,用户选择后再进入下一轮。 向用户确认以下内容(可合并为一组选项): 若用户没有原型图/设计…
category: other
runtime: no special runtime
---
# requirements-analysis output preview
## PART A: Task fit
- Use case: 本阶段在主对话中执行,需与用户多轮对话,不得臆造需求。 以下每组为一轮提问。每轮向用户呈现结构化选项,用户选择后再进入下一轮。 向用户确认以下内容(可合并为一组选项): 若用户没有原型图/设计稿,向用户呈现以下选项: 根据用户前面的回答,对仍有模糊的业务流程、异常分支、非功能需求进行针对性追问。此轮可使用开放式问题。 runs entirely locally. Works with Claude Code, Cursor, Cline and 23 more..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “何时使用 / 与用户交流(必须) / 交互原则” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “本阶段在主对话中执行,需与用户多轮对话,不得臆造需求。 以下每组为一轮提问。每轮向用户呈现结构化选项,用户选择后再进入下一轮。 向用户确认以下内容(可合并为一组选项): 若用户没有原型图/设计稿,向用户呈现以下选项: 根据用户前面的回答,对仍有模糊的业务流程、异常分支、非功能需求进行针对性追问。此轮可使用开放式问题。 runs entirely locally. Works with Claude Code, Cursor, Cline and 23 more.”.
- **02** When the source has headings, the agent prioritizes “何时使用 / 与用户交流(必须) / 交互原则” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. The source does not require a stable slash command. After installation, invoke the skill by name and describe the task.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files.
Start with a small task and check whether the result follows “何时使用 / 与用户交流(必须) / 交互原则”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: requirements-analysis
description: 本阶段在主对话中执行,需与用户多轮对话,不得臆造需求。 以下每组为一轮提问。每轮向用户呈现结构化选项,用户选择后再进入下一轮。 向用户确认以下内容(可合并为一组选项): 若用户没有原型图/设计…
category: other
source: RainLib/full-stack-skill
---
# requirements-analysis
## When to use
- 本阶段在主对话中执行,需与用户多轮对话,不得臆造需求。 以下每组为一轮提问。每轮向用户呈现结构化选项,用户选择后再进入下一轮。 向用户确认以下内容(可合并为一组选项): 若用户没有原型图/设计稿,向用户呈现以下选项: 根据用户前面的回答…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “何时使用 / 与用户交流(必须) / 交互原则” and keep inference separate from source facts.
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "requirements-analysis" {
input -> user goal + target files + boundaries + acceptance criteria
context -> 何时使用 / 与用户交流(必须) / 交互原则
rules -> SKILL.md triggers / order / output contract
runtime -> no special runtime | read files, write/modify files | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
} 需求分析
何时使用
- 用户描述了产品想法、提供了原型文档或需求草稿,需要整理成可执行需求时。
- 全栈工作流第 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-managerskill 的get-phase requirements和check-file确认是否已完成。 - 完成后:调用
history-managerskill 的set-phase requirements {requirements_id}记录并推进状态。
Decide Fit First
Design Intent
How To Use It
Boundaries And Review