UltraQA 是一个自主 QA 循环工作流技能，定位为持续运行直到质量目标达成的「测试、验证、修复、重复」循环。其循环结构为：qa-tester → architect 验证 → 修复 → 重复。
用途与定位 UltraQA 只负责重复的质量门禁循环。它应在目标行为已经明确、剩下要判断的是测试、构建、lint、typecheck 或其他显式 QA 条件是否通过时使用。与 /goal、Ralph、Team、Ultragoal 的关系上：若 Claude Code 的 /goal 处于激活状态，UltraQA 可以为该目标产出可见的命令证据，但不得把 /goal 评估器描述为独立运行命令或读取文件；若 Ralph 或 Team 激活，UltraQA 是隶属于该权限下的验证/修复子循环，而非竞争的会话循环；若没有安全的活动循环，则把 QA 期望与证据记录到 artifact-only 的 Ultragoal 笔记中，而不是声称自动执行。冲突策略使用确定性的 refuse、adopt_existing 和 artifact_only，而非非确定性的警告处理。
主要能力与目标解析 支持通过参数解析目标：--tests 检查全部测试套件通过；--build 检查构建退出码为 0；--lint 检查无 lint 错误；--typecheck 检查无 TypeScript 错误；--custom "pattern" 检查输出中是否出现自定义成功模式；--interactive 使用 qa-tester 进行交互式 CLI/服务测试。若未提供结构化目标，则将参数解释为自定义目标。
循环工作流 每轮循环最多执行 5 次。步骤包括：运行 QA——按目标类型执行对应验证（测试命令、构建命令、lint 命令、类型检查命令或自定义命令），交互式场景则通过 Task 调用 qa-tester 子代理指定 Goal、Service 与测试用例；检查结果——目标是否通过，通过则成功退出，否则继续；架构诊断——调用 architect 子代理（opus 模型）分析失败输出，给出根因与具体修复建议；修复问题——调用 executor 子代理（sonnet 模型）按建议精确修复受影响文件；随后重复回到第一步。
退出条件 目标达成时以成功消息退出并显示经过的循环次数；达到第 5 轮时带诊断信息停止；同一失败连续出现 3 次时提前停止并暴露根因；遇到环境错误（tmux、端口、依赖问题）时以错误退出。
可观测性与状态跟踪 每轮输出进度，例如当前轮次编号、运行操作、失败详情、诊断与修复动作、最终完成信息，使用户始终了解当前循环与状态。状态记录在 .omc/ultraqa-state.json 中，包含 active、goal_type、goal_pattern、cycle、max_cycles、failures、started_at、session_id 等字段。
取消与状态清理 用户可通过取消命令清除状态文件。重要规则是完成时删除状态文件而非仅设置 active: false；当目标达成、达到最大循环次数或提前退出时，执行 rm -f .omc/state/ultraqa-state.json，以保证后续会话状态干净，不应留下 active: false 的陈旧状态文件。
并行会话注意事项 多仓库工作区锚点：在父目录放置 .omc-workspace 标记，使跨子仓库的多个会话共享同一个 .omc/。解析顺序为 OMC_STATE_DIR > .omc-workspace > git > cwd，详见 docs/REFERENCE.md。会话 id 来源：CLI 环境下 OMC_SESSION_ID 环境变量优先；hook 环境下 hook payload 的 data.session_id 优先。Plan id（适用时）：UltraQA 状态为会话级，与 ralph 的互斥仅适用于同一会话。并行判定：支持（状态为会话级）。
其他重要规则 尽可能并行——在准备潜在修复的同时运行诊断；跟踪失败——记录每次失败以检测模式；模式提前退出——同一失败 3 次即停止并暴露；输出清晰——用户应始终知道当前循环与状态；清理——完成或取消时清除状态文件。