用途：作为新工作的入口，先做轻量扫描，再判断最佳行动路径或工作拆分方式，最终给出可执行的下一步，而不是只做描述。
主要能力：扫描 .kiro/specs/*/spec.json 的名称、阶段与审批状态；检查 .kiro/steering/ 下是否存在 product.md、tech.md、structure.md、roadmap.md；若存在 roadmap.md 则读取以恢复项目上下文；列出项目根目录结构。据此区分五条路径：A 已有 spec 覆盖、B 无需 spec、C 新单范围功能、D 多范围拆分、E 混合拆分。对 C/D/E 会加载 steering 与相关 spec，并派生子代理探索代码库，保持主上下文约 500 行以内。随后依次提出澄清问题，聚焦边界而非功能细节，再给出 2-3 个带取舍的方案并推荐其一，必要时派生子代理做技术调研与可行性校验。
使用方式：按步骤执行。C/D/E 路径需在建议下一条命令前把 brief.md 写入 .kiro/specs/<feature-name>/；D 路径还需写 .kiro/steering/roadmap.md，并为每个功能写 brief.md；E 路径在 roadmap 中额外记录已有 spec 更新与直接实现候选，仅为新 spec 写 brief.md。写完后读回验证。最后建议下一步命令：A 用 $kiro-spec-requirements {feature}；B 建议直接实现；C 默认 $kiro-spec-init <feature-name>，可选 $kiro-spec-quick；D 默认 $kiro-spec-batch，可选先 $kiro-spec-init；E 按新 spec 数量选择。
适用场景：Kiro 项目在开始新需求、判断是否需要新建或更新 spec、以及需要把大需求拆成多个 spec 时。
限制：不自动运行下游 spec 生成；文件必须落盘，否则会话结束后分析丢失；roadmap.md 已存在时按重入流程处理，只写下一个 spec 的 brief.md 并保留已完成项；若拆分只含已有 spec 更新与直接实现候选，不应使用 E 路径。具体收费、平台与效果资料暂未提供。