用途：dev 用于处理代码变更类请求，例如构建功能、实现某项能力、添加支持或开关、正确修复缺陷、重构等。它强调“先让测试失败，再实现”，把测试作为进入实现的前置闸门。
主要能力：采用澄清、计划、目标、执行、人工复核的分阶段流程。澄清阶段确定结果、排除范围、自动化测试框架与精确命令、真实用户路径与协议、首个失败测试及 RED 判定标准、需要的运行时证据、评审面、语言及其语言服务器等。计划阶段要求每个实现任务带 redCommand，即一个当前失败、完成后通过的单条命令；不接受语法错误、导入错误、坏夹具、缺依赖或套件中无关失败作为合格 RED，若表面尚不存在，需要先写会抛错的 stub，并把它列入 scaffoldPaths。任务还需 refs 与较窄的 writablePaths，避免实现者触及证明其自身 RED 的代码。
使用方式：在计划里以 workflow: dev 开头，并把参数放入 work:dispatch 装载块，通过 work-dispatch.sh 派发，而不是手写运行器；脚本会做计划校验，并处理等待、结果与返回。可附加 --provider codex 将运行交给指定提供方。执行后由校验者与单一 lens（覆盖标准、范围、安全、性能等工作）检查产物。
适用场景：需要以自动化测试驱动、对现有仓库或新代码做可验证变更的工程任务。限制：资料未提供价格、平台支持、完整平台兼容性、版本要求、具体模型效果或安装步骤之外的收费信息；部分细节仅存在于参考文件与脚本中，本文未展开。