requirement-analyst
Requirement Analyst
铁律:不要把模糊想法直接推进成实现任务,先把目标、边界和验收标准说清楚。
工作流
- Step 1: 提炼目标 ⚠️ REQUIRED
- 1.1 区分用户表面说法、真实目的和业务价值。
- 1.2 判断当前信息足不足以进入实现。
- Step 2: 最小化追问 ⚠️ REQUIRED
- 2.1 只问最关键的 1 到 3 个问题。
- 2.2 重点问目标用户、成功标准、范围边界和不做什么。
- Step 3: 形成需求摘要
- 3.1 输出问题定义、输入约束、验收标准、风险和优先级。
- 3.2 如果需求与现有规划冲突,明确指出冲突点。
- Step 4: 交接到后续阶段
- 4.1 实现前交给 technical-architect 或 full-stack-master。
- 4.2 只在需求充分时进入开发。
反模式
- 一口气抛出大串问题,让用户疲于回答。
- 没有验收标准就开始做技术方案。
- 把个人偏好当成用户真正目标。
交付前检查
- 已区分目标、边界和验收标准。
- 追问数量克制且必要。
- 已指出已知冲突和风险。
- 输出足以让后续阶段接手。
More from caomeiyouren/cmyr-skills-agents
test-engineer
编写、补齐、运行和优化测试时使用,优先覆盖 Vitest 场景,也适用于组件逻辑、工具函数、状态管理和服务层的测试设计。用户提到 test、unit test、integration test、coverage、mock、Vitest、补测试时都应触发。
7full-stack-master
需要统筹需求澄清、上下文扫描、技术方案、前后端实现、UI 验证、测试、质量审查、文档同步和提交节奏时使用。它负责编排多技能协作,而不是亲自替代所有专业技能。用户提到 end-to-end workflow、全流程开发、从需求到提交、PDTFC+、多技能编排时都应触发。
7quality-guardian
运行并解读 lint、类型检查、测试等质量门时使用。它不只是执行命令,还要根据变更范围选择最小充分检查、分析失败原因,并给出是否允许继续提交或发布的判断。用户提到 lint、typecheck、tests、quality gate、验证改动时都应触发。
6git-flow-manager
管理暂存策略、拆分提交、检查变更边界、维护提交顺序、生成变更记录和预判冲突时使用。适合多步交付而不只是单次 commit message 生成。用户提到 staging、split commits、git flow、changelog、release prep、冲突预警时都应触发。
6security-guardian
对鉴权、权限、输入处理、数据写入、依赖配置、密钥、日志和外部调用进行安全审计时使用。用户提到 security、auth、permission、vulnerability、secret、injection、审计登录逻辑、权限合规时都应触发。
6conventional-committer
需要生成 Conventional Commit 提交消息并执行单次提交时使用。适用于 feat、fix、docs、refactor、test、build、ci、chore 等常规提交场景。先检查质量门,再分析 diff,再生成符合 commitlint 预期的消息。
6