用途：接收已通过验证的测试行为（QA 已通过的 Story、已关闭 Bug 或完成的探索会话），在 TMS（Jira、Xray 或等价工具）中正式登记，形成完整追溯、正确优先级与明确的自动化结论。TMS 是文档与回归保护工具，不作探索；探索归 /sprint-testing。
流程：固定三阶段 Analyze → Prioritize（ROI）→ Document，不得跳过优先级判定。每个 TC 得出三种结论之一：Candidate（进入 test-automation）、Manual、Deferred；多数场景应 Deferred，不自动化。
模式：document（默认）走常规 TMS 文档化；repair-traceability 仅由 fix-traceability 别名或明确修复追溯请求触发，只加载 references/repair-traceability.md，保持 audit → 展示计划 → 明确用户批准 → 应用 → 验证 的封闭顺序。
关键约束：禁止在本工作流调用 /sdd-*；如要重构 KATA、fixtures、cli/、scripts/ 或 api/schemas/，须先退出并调用 /framework-development。依赖 agentic-qa-core，写 TC 前必读 test-design-doctrine.md，建立父子关系前必读 defect-management-doctrine.md，且本技能不提交 Bug。
TMS 模态：先判定 jira-xray（有 Xray）还是 jira-native（无 Xray），再进入 Phase 1；判定依据 AGENTS.md 中 {{TMS_CLI}}、.context/master-test-plan.md 或问题类型清单，全部失败才询问用户，确定后写入会话计划并保持粘性。
会话与编排：执行 Phase -1 恢复检查（.session/test-documentation/<scope>/）与 Phase 0 模态门；Phase 1、2 由编排器内联；Phase 3 批量创建 TC 超过 10 条时并行，子代理上限 10，其余内联。子代理失败即停止并上报部分成功，不自动修复或回滚。
就绪门：需 Issue-tracker、TMS 模态与工具均满足并验证；源仓库只读、无需活动环境、测试账号、DB、API 凭据或浏览器探测，因为文档化不接触运行系统也不写测试代码。缺失凭据为硬性停止。
限制：只记录已验证行为；TC 须为“前置条件+动作+可验证结果”，命名遵循规范；AC→TC 是下限而非目标，需覆盖边界、负向、状态与异常；参数化按同行为合并；跨切面特性需显式移交并指明接收套件或登记缺口；Bug 驱动规则要求值得回归的 Bug 必须落到 Test，复用已有失败 Test 或新建，不合格 Bug 按 Deferred 处理、不新建 Test。缺失信息暂未提供。