用途：在 Cursor 中开发功能时，强制走一遍“构建→审查→测试→修复”的循环，避免仅凭“能编译”就交付。
工作来源：若仓库中存在计划文件（路线图、重构计划或带 - [ ] 复选框的任务列表），则处理第一个未勾选任务，任务顺序有意安排，不得跳过；若计划引用规格文档，只读与当前任务相关的章节。没有计划或请求超出计划范围时，依据用户提示构建，先将其复述为可验证目标并给出 2–4 条成功标准，用一条消息确认范围后再动手。
循环步骤（每个任务或功能执行，任一步未通过不得推进）：
- 构建：严格实现任务规定内容，采用满足需求的最简实现，改动精准，不做推测性扩展，遵循项目既有约定。
- 审查：对改动运行 Cursor 的 /review，修复范围内所有发现（缺陷、安全问题、边界情况、性能、所改文件的风格）。若项目有设计系统规范（设计令牌文件、DESIGN.md、主题配置），需核对 UI 改动，不得硬编码颜色、字体或间距绕过令牌。未触及代码中的既有问题记入报告而非静默修复。重复 /review 直至干净；若发现与任务或规格冲突，以规格为准并标记分歧。
- 端到端测试：运行任务的验证步骤或成功标准，运行完整测试套件（此前通过的必须仍通过），为新逻辑补测试，再以用户视角走真实流程，包括空、加载和错误状态。
- 修复：测试发现的问题回到循环：修复→/review→重测。失败任务不得标记完成，应用损坏时不得开始下一任务。
- 继续：将任务标记为 - [x]，更新计划中的进度/状态行，循环至下一任务，直到请求范围完成。
- 报告：说明构建内容与计划进度、已修复的审查发现与推迟项、验证方式（测试与流程走查）、需用户关注的事项，对不稳定或仅部分验证的内容如实说明。
规则：跳过审查或未测试的工作等于未完成；不要重新争论计划决策，若任务看似有误，提一个具体问题而非猜测；发现无任务覆盖的工作，应提出并建议新任务，不得静默扩大范围。
限制：资料未提供安装命令、收费、价格、平台支持等具体信息。