Next Action Suggester 综合评估
核心用法
next 是一个任务后自动流转技能，设计为通过 Stop hook 自动触发（基于完成关键词正则匹配），也可手动调用 /next [topic]。其核心流程遵循严格的"0-0.7-1-2-3"六步协议：
1. Stall Detection (Step 0)：强制检测任务是否陷入停滞，若检测到则自动调用 /fix
2. Ask Gates (Step 0.3-0.7)：四道硬闸门——跳过纯管理类任务、强制决策询问、以 TaskList 为首要信息源、确认用户当前工作状态
3. 任务类型识别 (Step 1)：分类刚完成的工作
4. AskUserQuestion 建议 (Step 2)：核心输出环节，必须前置读取 suggestion-patterns.md，强制枚举7大候选源（TaskList/直接后续/GitHub PR&issue/CI状态/fix_plan/会话清理/自由文本），必须填满4个选项槽位
5. 执行所选行动 (Step 3)：多选时先 TaskCreate 注册再顺序执行
显著优点
- 自动化触发设计：通过
Stophook 和decision:"block"JSON 信号实现无感介入，降低用户认知负担 - 防停滞机制：内置
stall-detect子模块，主动识别"卡住"场景并自动修复 - 信息源优先级强制化：以
TaskList实时调用为最高权威，禁止依赖易过期的摘要记忆 - 选项多样性约束：7源枚举 + 4槽位填满规则，有效对抗"选项不足"的常见抱怨
- 上下文感知模板：
suggestion-patterns.md提供20+场景模板（代码变更/配置/PR评审/技能创建等），每个模板含专用闸门
潜在缺点与局限性
- 硬依赖链脆弱：Step 2 要求"必须先读 suggestion-patterns.md"，若文件缺失或路径错误则触发 skill bypass 判定，流程中断风险高
- 过度规范化成本：四道 ask gates + 7源枚举 + 4选项填满，在简单场景下可能产生冗余开销
- GitHub CLI 耦合：PR/issue/CI 探测依赖
gh命令，非 GitHub 环境或权限不足时相关候选源失效 - 多选执行的序列化假设：Step 3 "顺序执行"未定义失败时的回滚策略
- 正则触发局限性：locale patterns 的维护负担未明确，多语言支持可能不完整
适合人群
- 复杂项目管理者：需要维护多任务并行、依赖关系清晰的研发流程
- AI 辅助工作流重度用户：依赖
Stophook 自动化、追求"完成后自动推进"体验 - 团队协作场景：涉及 PR 评审矩阵、CI 状态关注、fix plan 跟踪的开发者
- 技能/Agent 开发者：需遵循严格结构化协议构建可复用自动化流程
常规风险
| 风险场景 | 说明 |
|---------|------|
| **文件缺失导致 bypass** | suggestion-patterns.md 或 ask-gates.md 未找到时，技能拒绝执行而非降级运行 |
| **TaskList 调用失败** | 若工具不可用，Step 0.5 阻塞导致无法生成建议 |
| **权限不足** | `gh` 命令无权限时，GitHub 相关选项源静默失效 |
| **选项同质化** | 即使填满4槽，若来源单一（如全来自 TaskList）仍可能缺乏多样性 |
| **自动触发误判** | 完成关键词正则可能误匹配非真正完成场景 |
安全评估说明
本报告基于技能文档结构分析，未执行运行时安全扫描。技能涉及的外部调用（gh CLI、TaskList、AskUserQuestion）均属于标准工具链，无已知恶意行为模式。