核心工作流
工作流适用场景
灵犀工作流适用于任务量超过 3 人/天、且中等及以上复杂度的任务。这类任务需要预先做充分的架构设计与方案调研；task + vet 能帮助架构师（或负责方案的角色）做好架构与整体方案设计。若任务较简单，可直接使用 IDE 的 Agent 模式，无需启动灵犀工作流。
工作流顶层设计
设计目标
在保持多入口与流程解耦的前提下，将需求从「可判定目标」推进到「可执行实现」再到「可验证交付」：
- 用
task锁定目标、范围、验收标准与架构级决策 - 用
vet审查 task 文档质量，帮助完成高质量的需求与验收设计（可选，可多次执行） - 用
plan细化实施路径并拆解任务，降低build失败率 - 用
build执行实现与测试闭环，并承接有/无 plan 两种输入（简单任务可直达实现） - 用
review做按需求编号（F）的独立验收审计，形成证据闭环
生命周期（按需推进，不强制串行）
推荐推进顺序：
/task <描述>：创建001.task.<标题>.md/vet（可选）：审查 task 质量/plan（可选）：生成001.plan.<标题>.md与001.testcase.<标题>.md/build（可选）：实现与测试/review：交付审查与验收结论
工作流特性：
- 所有环节可跳过，按需执行
- 入口解耦，通过
/task、/plan等显式触发对应 Skill（仅支持手动或显式调用）
多任务特性（Multi-task）
工作流天然支持多任务并行推进，taskId 是唯一任务上下文锚点：
- 文档按
taskId命名与隔离：001.task.*、001.plan.*、001.testcase.*、001.review.* - 可通过显式指定
taskId在任意任务间切换，不要求单任务串行完成 - 未指定
taskId时可回退到最新任务编号用于便捷操作 - 多任务场景建议显式携带
taskId，避免上下文歧义与串线
命令职责与用法
工作流由 Skills 驱动；/task、/plan 等为显式触发方式（仅支持手动或显式调用，不根据语义自动加载）。以下按步骤说明各 Skill 的职责与用法。
/task — 锁定目标与边界
/task <需求描述>职责：
- 产出任务目标、边界、验收标准、架构级方案、验证方式与证据形式
- 不承载实施级细节，实施细化下沉到
/plan
灵犀会做什么：
- 自动生成任务编号（001, 002...）和标题
- 完成需求提纯并明确验收标准
- 创建结构化任务文档：
.cursor/.lingxi/tasks/001.task.<标题>.md
产出：
001.task.<标题>.md
/vet — 审查 task 质量（可选）
/vet [taskId]职责：
- 对 task 文档做质量审查，提升可行性与可判定性
灵犀会做什么：
- 从完整性、一致性、边界条件等维度给出审查结论与建议
- 支持多次执行，用于迭代优化
产出：
- 无文件产出（结果在对话中返回）
/plan — 细化实施方案（可选）
/plan [taskId]产出：
001.plan.<标题>.md001.testcase.<标题>.md
职责：
- 对 task 做实施级方案细化（改动点、依赖、顺序、风险）
- 按需进行需求澄清，并完成任务拆解
灵犀会做什么：
- 将 task 拆解为可执行任务与验证路径
- 组织实施顺序、依赖关系与主要风险
- 在可单测单元中，可采用
Txa(测试) -> Txb(实现)的先测后实现方式
/build — 执行实现（可选）
/build [taskId]职责：
- 承接有/无 plan 两种输入，推进实现与测试闭环
- 对
unit/integration执行先测后实现闭环
灵犀会做什么：
- 根据输入路径选择执行模式并推进实现
产出：
- 代码实现与对应测试变更
/review — 独立验收审计
/review [taskId]职责：
- 按需求项（Feature，记作 F）执行独立验收审计
- 给出可追溯的交付结论
灵犀会做什么：
- 对每个需求项（F）独立给出 Pass/Fail
- 为每条结论附证据引用
- 证据不足或不可验证的需求项（F）判定为 Fail
产出：
- 验收结论与证据引用（可形成
001.review.<标题>.md）
流程示例
简单任务（skip-plan）
/task 修复登录页面的表单验证 bug
/build
/review复杂任务（建议完整链路）
/task 重构用户权限系统，支持 RBAC 模型
/vet
/plan
/build
/review多任务并行
/vet 002
/plan 001
/build 001
/review 002