名称: ctx-next 描述: “建议接下来要做什么。在开始会话、完成任务或不确定优先处理什么时使用。” 允许的工具: Bash(ctx:*), Read
分析当前任务和最近的会话活动，然后建议1-3个具体的后续行动及其理由。
何时使用
- 在加载上下文后开始会话时（“我应该做什么？”）
- 完成任务后（“接下来做什么？”）
- 当用户询问优先级或方向时
- 当存在多个任务且不清楚选择哪一个时
何时不使用
- 当用户已经说明他们想要做什么时
- 当任务正在进行中时（不要用建议打断流程）
- 当不存在
.context/目录时（没有内容可分析）
使用示例
/ctx-next
/ctx-next (刚刚完成身份验证重构)
流程
静默执行以下所有步骤——不要叙述步骤：
- 阅读 TASKS.md 以获取包含状态、优先级和阶段在内的完整任务列表。
- 检查最近的会话 以了解刚刚处理的内容，避免建议已完成的工作：
ctx recall list --limit 3 - 阅读最新的会话文件（如果有），以了解已完成的工作以及记录的任何后续事项。
- 使用以下优先级逻辑分析和排序任务。
- 按照下面的输出格式呈现1-3条建议。
优先级逻辑
使用以下标准（按顺序）对候选任务进行排序：
- 显式优先级：
#priority:high>#priority:medium>#priority:low> 未标记 - 未阻塞：未标记
#blocked或未列在“已阻塞”部分下的任务 - 优先处理进行中的任务：在开始新任务之前应恢复
#in-progress任务（完成 > 开始） - 连续性：倾向于与最近会话工作相关的任务（继续一个主题比切换上下文成本更低）
- 阶段顺序：早期阶段优先于后期阶段（阶段0先于阶段1，等等），除非优先级覆盖
- 快速见效：如果两个任务优先级相同，倾向于看起来更小/更快的任务（建立动力）
跳过以下任务：
[x]已完成的任务[-]已跳过的任务- 明确标记为
#blocked且没有解决路径的任务 - 最近一次会话的主要焦点任务（用户可能想要多样性，或者会话结束是因为任务已完成）
输出格式
按以下格式呈现您的建议：
建议下一步
1. [任务标题或摘要] #priority:X
[1-2句理由：为什么是这个任务，为什么是现在]
2. [任务标题或摘要] #priority:X
[1-2句理由]
3. [任务标题或摘要] （可选——仅在确实有用时提供）
[1-2句理由]
基于 N 个待处理任务，跨越 M 个阶段。上次会话：[主题] ([日期]).
建议规则：
- 仅限1-3项——超过3项就失去了建议的目的
- 要具体——例如“修复
block-non-path-ctx钩子”，而不是“处理钩子” - 包含优先级标签，以便用户了解权重
- 理由必须引用上下文——为什么是这个任务，而不仅仅是它是什么。与最近的工作、优先级或依赖关系联系起来
- 如果存在进行中的任务，它几乎总是应该作为建议 #1（不要放弃未完成的工作）
示例
好的输出
建议下一步
1. 修复
block-non-path-ctx钩子#priority:high昨天会话中遗留的未完成任务。该钩子过于激进——它阻止了不调用 ctx 的
git -C path命令。快速修复，能清除一个阻塞项。2. 添加
Context.File(name)方法#priority:high消除了5个包中10多个线性扫描的样板代码实例。高影响力，低工作量——是很好的整合目标。
3. 主题系统 (T1.1)
#priority:medium日志站点最具影响力的剩余功能。元数据已从之前的丰富化工作中准备就绪。
基于3个阶段中的24个待处理任务。上次会话：文档漂移清理 (2026-02-11).
差的输出
"你有很多任务。这里有一些选项：
- 处理一些钩子相关的东西
- 也许可以处理测试
- 还有一些文档要写"
（过于模糊，没有优先级，没有理由，没有与上下文联系。）
质量检查清单
在呈现建议之前，请验证：
- [ ] 已阅读 TASKS.md（不是凭记忆猜测）
- [ ] 已检查最近的会话，避免重复建议已完成的工作
- [ ] 每条建议都有具体的任务引用
- [ ] 每条建议都有基于上下文的理由
- [ ] 进行中的任务优先于新开始的任务
- [ ] 建议不超过3条
- [ ] 页脚显示任务计数和上次会话引用