From omni
Routes development tasks to express/standard/deep workflow agents via complexity analysis or --workflow param. Preprocesses args, inits env with bash/pwsh scripts, detects/resumes state. Triggers: /routing.
npx claudepluginhub zte-aicloud/co-omnispec --plugin omniThis skill uses the workspace's default tool permissions.
- `express`、`standard`、`deep` 是写入状态或路由逻辑的 **`flow_mode` 取值**,语义上对应 **三类 workflow agent**,**不是** skill 名称,也**不得**当作 `express`/`standard`/`deep` 等 skill 去调用。
Routes HF workflows at runtime by analyzing artifacts to determine current node, profile, execution mode, branches like hotfix/increment, and review dispatch. Use on 'continue/advance', post-review recovery, conflicts, or unclear stages.
Orchestrates 5-phase TDD workflow for complex features: plan/design, failing tests (RED), implementation (GREEN), refactor/review, finalize. Fasttrack mode for pre-approved specs; avoid simple bug fixes.
Routes requests into spec-first workflows before substantial work like editing files, running state-changing commands, debugging, reviewing, planning, setup, updates, or architecture decisions.
Share bugs, ideas, or general feedback.
express、standard、deep 是写入状态或路由逻辑的 flow_mode 取值,语义上对应 三类 workflow agent,不是 skill 名称,也不得当作 express/standard/deep 等 skill 去调用。| flow_mode | 必须由该 agent 执行 |
|---|---|
express | express-workflow |
standard | standard-workflow |
deep | deep-workflow |
routing 本身是 skill:负责参数预处理、状态机与选择/恢复 flow_mode;真正按模式跑通 SDD 步骤的是上表中的 workflow agent,agent 内部再按需调用各 skill(如 specify)。complexity-analyzer 是 agent:仅在未强制 --workflow 时产出推荐 flow_mode 字符串,供本 skill 读取后仍须按上表启动对应 workflow agent,而不是启动名为 express 的 skill。$ARGUMENTS
在任何状态检测之前,先解析 $ARGUMENTS 中的可选参数:
--workflow <express|standard|deep>--workflow=<express|standard|deep>--e2e:启用E2E测试设计(默认关闭)处理规则:
--workflow 参数值,记为 $FORCED_FLOW_MODE--e2e 标志,记为 $ENABLE_E2E(包含时为 true,否则为 false)--workflow 和 --e2e 从 $ARGUMENTS 中移除,剩余文本作为真实功能描述继续传递--workflow 参数值非法(非 express|standard|deep),立即报错并提示用户修正--workflow 参数,记 $FORCED_FLOW_MODE=""workflow 参数: <$FORCED_FLOW_MODE 或 EMPTY>E2E 参数: <$ENABLE_E2E>routing 输入参数: <$ARGUMENTS>参数说明:
--workflow 仅接受 express|standard|deep--e2e 为开关标志,不需要值,启用后 specify 和 design 阶段会执行 E2E 测试设计scripts/bash/check-prerequisites.sh --json --paths-onlyscripts/powershell/check-prerequisites.ps1 --json --paths-onlyFEATURE_DIR, FEATURE_SPEC, IMPL_DESIGN, TASKScheck-prerequisites.sh --paths-only 在 routing 阶段仅用于提供临时路径上下文(如 REPO_ROOT、候选 FEATURE_DIR),不是最终分支决策依据。changes/<branch> 分支目录。changes/,也包括 .infra/ 或其他自定义目录下的分支工作路径。BRANCH_NAME / FEATURE_DIR;此时获取到的分支与目录信息仅可用于只读探测与状态判断。create-branch 执行前,严禁基于该临时 FEATURE_DIR 落盘关键产物(如 spec.md、design.md、tasks.md、状态文件)。BRANCH 命中 master/main:
specify 中通过 create-branch 产生或复用安全特性分支后,才允许写入。检查 FEATURE_DIR/.runs/.omnispec-state.json 是否存在, 按以下三种情况处理:
$FORCED_FLOW_MODE 非空:直接将 flow_mode 设为该值并立即路由到对应 workflow agent,跳过整个复杂度判定块(严禁调用 complexity-analyzer)判定条件: completed_stages 不包含 implement
flow_mode 和 current_stageAskUserQuestion: "继续执行" / "从头开始"
current_stage 的下一阶段开始$FORCED_FLOW_MODE 非空:删除状态文件后仍必须继承本次 --workflow 的取值,直接路由到对应 workflow agent,严禁调用复杂度判定/complexity-analyzer判定条件: completed_stages 包含 implement
此时用户的 $ARGUMENTS 是问题描述/修改诉求, 而非新功能描述. 全自动执行, 无需用户确认:
确定回滚目标阶段, 按优先级:
a. 关键词匹配(从用户 $ARGUMENTS 推断):
| 用户描述中的关键词 | 回滚目标 |
|---|---|
| 需求/规范/spec/功能描述/业务需求/场景/用户故事 | specify |
| 澄清/clarify/模糊/歧义/不明确/补充 | clarify |
| 设计/design/方案/架构/接口/数据模型/契约 | design |
| 任务/tasks/分解/拆分/实现步骤 | tasks |
b. 产物文件检测(辅助佐证, 关键词无法匹配时使用):
| 检测文件 | 检测条件 | 回滚目标 |
|---|---|---|
FEATURE_DIR/.runs/evaluations/evaluation-report.yaml (stage: specify) | score < 95 或 status != pass | specify |
FEATURE_DIR/.runs/evaluations/evaluation-report.yaml (stage: clarify) | score < 95 或 status != pass | clarify |
FEATURE_DIR/.runs/evaluations/design-evaluation-summary.json | score < 95 或 blocking_count > 0 | design |
c. 冲突解决: 若多个阶段都有问题, 回滚到最早的有问题阶段.
写入回滚信息到状态文件:
{
"rollback": {
"target_stage": "<回滚目标阶段>",
"reason": "<判定依据摘要>",
"user_feedback": "<用户 $ARGUMENTS 原文>",
"triggered_at": "<ISO8601>"
}
}
输出日志: [回滚] 检测到上轮 workflow(<flow_mode>)已完成, 回退到 <target_stage> 重新执行
直接路由到状态文件中 flow_mode 对应的 workflow agent(不询问用户).
仅在"情况 A: 首次执行"或"情况 B: 从头开始"时进入(且 $FORCED_FLOW_MODE 为空时)。
硬性约束:
$FORCED_FLOW_MODE 非空,就必须跳过该块;不得用复杂度判定结果覆盖/修改 --workflow 指定的模式。若 $FORCED_FLOW_MODE 非空,则在情况 A 或情况 B(从头开始)均结束本节。
使用 complexity-analyzer agent, 按其指引:
$ARGUMENTS 的三个维度(规模/清晰度/发散意愿)$FORCED_FLOW_MODE(来自 --workflow 参数)flow_mode(断点续跑/回滚场景)补充约束:
--workflow 在情况 A(状态文件不存在)生效--workflow 在情况 B 的“从头开始”(即删除状态文件后)生效$FORCED_FLOW_MODE 非空且满足上述两个场景时,优先级 3(复杂度判定结果)永远不触发--workflow 影响执行约定: 所有 workflow agent 必须使用
run_in_background: false(前台运行),禁止后台执行。
禁止行为:
- 严格禁止在本步骤之前创建任何分支目录、特性目录、工作目录或
.omnispec-state.json文件(不限于changes/,也包括.infra/等路径示例)- 目录和状态文件应由
create-branch(在specify内部调用)创建- 若当前已在特性分支上下文中,
check-prerequisites.sh应返回对应特性分支;若异常返回master/main,应视为分支探测异常并触发重试/修复,而不是继续使用主干分支- 严格禁止跳过
create-branch:无论是新建还是复用分支,均必须执行create-branch并以其输出为准- 严格禁止在 routing 阶段假设“分支已创建”或“分支目录已创建”,不得将临时探测值当作最终分支信息向后续写入流程传播
根据 flow_mode, 使用对应 subagent 执行:
| flow_mode | Agent |
|---|---|
| express | express-workflow |
| standard | standard-workflow |
| deep | deep-workflow |
$ARGUMENTS(已移除 --workflow 和 --e2e 后的剩余文本)和 $ENABLE_E2E 标志传递给 workflow agent.
specify 和 design 时将 $ENABLE_E2E 注入调用上下文。deep-workflow 专属约定: 同一段 $ARGUMENTS 同时视为用户若执行 reverse --target on-demand --requirement 时、--requirement 位置应拼接的内容(需求文件路径或需求描述文本,须满足 reverse-on-demand 约束)。路由层无需再单独传「需求参数」;deep workflow 的 Step 0 与 Step 2 共用此输入。rollback 字段执行回退.FEATURE_DIR/.runs/.omnispec-state.json:
{
"flow_mode": "express|standard|deep",
"current_stage": "specify|clarify|design|tasks|analyze|implement",
"completed_stages": [],
"last_updated": "ISO8601",
"arguments": "$ARGUMENTS 原文",
"rollback": null
}
complexity-analyzer - 复杂度分析 agent,产出推荐 flow_mode(express/standard/deep 字符串);执行仍交给下方 workflow agentexpress-workflow - flow_mode=express 时的 workflow agentstandard-workflow - flow_mode=standard 时的 workflow agentdeep-workflow - flow_mode=deep 时的 workflow agent