数据分析
- 作者仓库星标 0
- 作者更新于 实时读取
- 作者仓库 full-stack-skill
- 领域
- 通用
- 兼容 Agent
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- 信任分
- 88 / 100 · 社区维护
- 作者 / 版本 / 许可
- @RainLib · 未声明 license
- Token 消耗评级
- 低消耗
- 接入复杂程度
- 即装即用
- 是否需要外部 API Key
- 不需要
- 兼容的系统
- 未声明(默认跨平台)
- 底层运行要求
- 无特殊要求
- 文件与系统权限
-
- 只读
- 允许写入 / 修改
- 网络行为
- 仅限本地
- 安装命令数
- 26 条
档案由构建时根据 SKILL.md 与安装命令自动衍生,可能与作者实际意图存在差异。
需要注意: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: requirements-analysis
description: 从产品原型或用户描述中梳理功能点与细节要求,产出结构化需求文档。全栈工作流第 1 阶段。 本阶段在主对话中执行,需与用户多轮对话,不得臆造需求。 以下每组为一轮提问。每轮向用户呈现结构化选项…
category: 通用
runtime: 无特殊运行时
---
# requirements-analysis 输出预览
## PART A: 任务判断
- 适用问题:通用任务拆解、检查和交付。
- 输入要求:目标材料、限制条件、期望输出和验收方式。
- 证据边界:围绕“何时使用 / 与用户交流(必须) / 交互原则”读取原文规则,不把推断写成作者承诺。
## PART B: 执行结果
- **01** 任务判断:确认你的需求是否属于通用任务拆解、检查和交付,并标出输入、限制和预期结果。
- **02** 执行计划:优先按“何时使用 / 与用户交流(必须) / 交互原则”拆成步骤,说明每一步会读取什么、修改什么、产出什么。
- **03** 交付结果:给出可复制的命令、文件改动、检查清单或内容草稿,并说明如何继续迭代。
- **04** 风险边界:结合 读取文件、写入/修改文件、主要在本地完成、通常不需要额外 API Key 给出执行前确认项。
## Running Rules
- 读取文件、写入/修改文件;主要在本地完成;通常不需要额外 API Key。
- 先小样例验证,再放大到真实任务。
- 交付时同时给结果、检查口径和下一步迭代建议。 先确认触发方式
原文没有稳定的斜杠命令要求。安装验证后通常全局生效,直接在对话里点名这个 Skill 并描述任务即可。
给清楚输入和边界
告诉 Agent 目标文件或材料、期望结果、不可改范围、是否允许联网或执行命令。本 Skill 的权限画像是:读取文件、写入/修改文件。
小样例验证后再放大
先用一个小任务确认它会围绕“何时使用 / 与用户交流(必须) / 交互原则”工作;涉及文件或命令时,先看 diff、日志、预览或测试结果。
复核后再交付
检查最终产物是否包含明确结果、必要证据和下一步动作;如果输出泛泛而谈,就补充输入、边界和验收标准后重跑。
---
name: requirements-analysis
description: 从产品原型或用户描述中梳理功能点与细节要求,产出结构化需求文档。全栈工作流第 1 阶段。 本阶段在主对话中执行,需与用户多轮对话,不得臆造需求。 以下每组为一轮提问。每轮向用户呈现结构化选项…
category: 通用
source: RainLib/full-stack-skill
---
# requirements-analysis
## 什么时候使用
- 从产品原型或用户描述中梳理功能点与细节要求,产出结构化需求文档 适合处理通用任务拆解、检查、交付和复盘,核心价值是把输入、判断、执行、验证和交付边界固定下来,避免 Agent 泛泛回答。 把任务拆成可执行、可检查、可继续迭代的步骤;通常…
- 面向通用任务拆解、检查和交付,优先处理能明确输入、步骤和验收标准的工作。
## 需要提供什么
- 目标材料、目录范围、期望结果和不可改动内容。
- 是否允许联网、执行命令、读写文件或调用外部服务。
## 执行规则
- 围绕「何时使用 / 与用户交流(必须) / 交互原则」组织步骤,不把推断写成作者事实。
- 读取文件、写入/修改文件;主要在本地完成;通常不需要额外 API Key。
- 先跑小样例,确认结果可检查后再扩大任务范围。
## 输出要求
- 给出最终产物、关键证据、验证方式和下一步动作。
- 信息不足时标记 unknown,不编造命令、平台或依赖。 证据边界与执行链路
作者原文负责流程事实;仓库文件负责来源和命令;流狐只补充适用场景、限制和质量判断。
skill "requirements-analysis" {
输入层 -> 用户目标 + 目标文件 + 禁止范围 + 验收标准
上下文层 -> 何时使用 / 与用户交流(必须) / 交互原则
规则层 -> SKILL.md 触发条件 / 执行顺序 / 输出格式
运行层 -> 无特殊运行时 | 读取文件、写入/修改文件 | 主要在本地完成
安全层 -> 通常不需要额外 API Key + 小任务验证 + diff / 日志复核
输出层 -> 可复制结果 + 检查清单 + 下一步迭代
} 需求分析
何时使用
- 用户描述了产品想法、提供了原型文档或需求草稿,需要整理成可执行需求时。
- 全栈工作流第 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}记录并推进状态。
先判断是否适合
作者设计意图
作者的方法与取舍
边界和复核