specify

name	specify
description	根据自然语言描述创建或更新功能规格说明。生成 docs/specs/<group>/name.md，包含用户故事、验收标准和功能需求。

用户输入

$ARGUMENTS

你必须在继续之前考虑用户输入（如果不为空）。

流程

用户在 /specify 后输入的文本就是功能描述。不要让用户重复，除非他们提供了空命令。

根据功能描述，执行以下步骤：

1. 确定规格文件路径：

   • 根据功能描述选择分组目录（docs/specs/ 下）：
     • core/ — Agent 核心机制（工具、权限、记忆、压缩、prompt）
     • ui/ — 交互与 UI（命令、渲染、输入组件）
     • multi-agent/ — 多 Agent 与并发（子代理、任务、工作流）
     • ecosystem/ — 扩展与生态（技能、插件、MCP）
     • automation/ — 自动化（钩子、循环、目标）
     • enterprise/ — 企业管控（SSO、遥测、托管配置）
     • 边界模糊时默认 core/
   • 根据功能描述生成 2-4 个词的 slug（小写、连字符、保留缩写词），与组内已有文件名不冲突
   • 规格文件路径：docs/specs/<group>/<slug>.md

2. 加载模板 ${WAVE_SKILL_DIR}/templates/spec-template.md，了解必需章节。

3. 编写规格说明：

   • 解析用户描述，提取关键概念：角色、操作、数据、约束
   • 对于不明确的部分，根据上下文和行业标准做出合理推断
   • 仅在关键决策处标记 [待澄清：具体问题]（最多 3 处）
   • 填写「用户场景与测试」章节，包含按优先级排序的用户故事（P1、P2、P3...）
   • 生成可测试的功能需求（FR-001、FR-002...）
   • 如涉及数据，识别关键实体
   • 写入规格文件，替换所有占位符

4. 如果存在 [待澄清] 标记（最多 3 处）：

   • 将每个标记作为问题展示，附带建议答案
   • 等待用户回复后更新规格文件

5. 报告完成，输出规格文件路径。

指南

• 关注用户需要什麼和为什么，而非如何实现
• 不包含实现细节（不涉及技术栈、API、代码结构）
• 每个需求必须可测试、无歧义
• 删除不适用的可选章节（不要留 "N/A"）