根据用户需求为当前功能生成自定义检查清单。
关键概念：检查清单是需求编写的单元测试——它们验证给定领域中需求的质量、清晰度和完整性。
不是用于验证/测试：
用于需求质量验证：
隐喻：如果你的规格是用英文编写的代码，检查清单就是它的单元测试套件。你在测试需求是否编写良好、完整、无歧义且准备好实现——不是测试实现是否工作。
$ARGUMENTS
你必须在继续之前考虑用户输入（如果不为空）。
设置：从仓库根目录运行 并解析 JSON 获取 FEATURE_DIR 和 AVAILABLE_DOCS 列表。
node ${WAVE_PLUGIN_ROOT}/scripts/check-prerequisites.mjs --json明确意图（动态）：派生最多三个初始上下文澄清问题（无预制目录）。它们必须：
$ARGUMENTS 中已经明确则单独跳过生成算法：
问题格式规则：
无法交互时的默认值：
输出问题（标记 Q1/Q2/Q3）。回答后：如果 >=2 个场景类（替代/异常/恢复/非功能领域）仍不清楚，你可以再问最多两个有针对性的后续问题（Q4/Q5），每个有一行理由（例如，"未解决的恢复路径风险"）。不超过总共五个问题。如果用户明确拒绝更多则跳过升级。
理解用户请求：结合 $ARGUMENTS + 澄清答案：
加载功能上下文：从 FEATURE_DIR 读取：
上下文加载策略：
生成检查清单 - 创建"需求的单元测试"：
FEATURE_DIR/checklists/ 目录ux.md、api.md、security.md）[domain].md/checklist 运行创建一个新文件（从不覆盖现有检查清单）核心原则 - 测试需求，而非实现： 每个检查清单项目必须评估需求本身的：
类别结构 - 按需求质量维度分组项目：
如何编写检查清单项目 - "英文的单元测试"：
❌ 错误（测试实现）：
✅ 正确（测试需求质量）：
项目结构： 每个项目应遵循此模式：
[规格 §X.Y][缺口] 标记按质量维度的示例：
完整性：
清晰度：
结构参考：按照 ${WAVE_PLUGIN_ROOT}/templates/checklist-template.md 中的规范模板生成检查清单，用于标题、元信息章节、类别标题和 ID 格式。如果模板不可用，使用：H1 标题、目的/创建元信息行、包含 - [ ] CHK### <需求项目> 行的 ## 类别章节，ID 从 CHK001 开始全局递增。
报告：输出创建的检查清单完整路径、项目计数，并提醒用户每次运行创建一个新文件。总结：
重要：每次 /checklist 命令调用使用简短描述性名称创建检查清单文件，除非文件已存在。这允许：
ux.md、test.md、security.md）checklists/ 文件夹中易于识别和导航为避免混乱，使用描述性类型并在完成后清理过时的检查清单。
用户体验需求质量： ux.md
示例项目（测试需求，非实现）：
API 需求质量： api.md
示例项目：
性能需求质量： performance.md
示例项目：
安全需求质量： security.md
示例项目：
❌ 错误 - 这些测试实现，而非需求：
- [ ] CHK001 - 验证登录页显示 3 个剧集卡片 [规格 §FR-001]
- [ ] CHK002 - 测试桌面端悬停状态是否正常工作 [规格 §FR-003]
- [ ] CHK003 - 确认 logo 点击导航到首页 [规格 §FR-010]
- [ ] CHK004 - 检查相关剧集部分显示 3-5 个项目 [规格 §FR-005]
✅ 正确 - 这些测试需求质量：
- [ ] CHK001 - 是否明确指定了精选剧集的数量和布局？ [完整性, 规格 §FR-001]
- [ ] CHK002 - 所有交互元素的悬停状态需求是否一致定义？ [一致性, 规格 §FR-003]
- [ ] CHK003 - 所有可点击品牌元素的导航需求是否清晰？ [清晰度, 规格 §FR-010]
- [ ] CHK004 - 相关剧集的选择标准是否已文档化？ [缺口, 规格 §FR-005]
- [ ] CHK005 - 是否为异步剧集数据定义了加载状态需求？ [缺口]
- [ ] CHK006 - "视觉层次"需求是否可以客观衡量？ [可衡量性, 规格 §FR-001]
一致性：
覆盖度：
可衡量性：
场景分类与覆盖（需求质量焦点）：
可追溯性要求：
[规格 §X.Y]，或使用标记：[缺口]、[歧义]、[冲突]、[假设]发现并解决问题（需求质量问题）： 询问关于需求本身的问题：
内容整合：
🚫 绝对禁止 - 这些使其成为实现测试而非需求测试：
✅ 必需模式 - 这些测试需求质量：