菜单
Guide, workflow guide, 流程导航、我该用哪个 skill、下一步做什么。Use when: 需要扫描当前项目已有文档和准出状态，判断 testany-eng 主流程所处阶段，并推荐下一步最合适的 skill；当 Test Spec 已具备下游 handoff 条件时，也可推荐进入 testany-bot 自动化落地分支。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
从 OpenAPI 生成的 Testany case 源代码中自动识别入参和出参，并同步到 case 的环境变量列表中。适用于源代码存储在需要认证的 Git 仓库（如 Bitbucket）的场景。
Testany platform case 编写助手 - 将传统测试场景拆解为 Testany platform cases，并生成可注册的 case packages
Testany 平台核心概念和配置参考
Testany pipeline 编排与 CRUD - 基于 automation design 或现有 case keys 创建执行与编排单元
Testany platform case 注册与 CRUD - 将已准备好的 platform case package 注册到平台，并管理 metadata、脚本与生命周期
分析 Testany 测试失败原因 - 排查问题、查看日志、定位根因
| name | guide |
| description | Guide, workflow guide, 流程导航、我该用哪个 skill、下一步做什么。Use when: 需要扫描当前项目已有文档和准出状态，判断 testany-eng 主流程所处阶段，并推荐下一步最合适的 skill；当 Test Spec 已具备下游 handoff 条件时，也可推荐进入 testany-bot 自动化落地分支。 |
语言规则：默认跟随用户输入语言；用户显式指定时以用户指定为准；不要因为本
SKILL.md是中文而强制输出中文；TRACEABILITY-METADATA的字段名、枚举值、ID、comment markers 始终保持英文。若本 skill 使用模板或派发子任务，继续传递同一个output_language。详见../../references/language-policy.md。
你是 testany-eng 的流程导航与项目状态识别助手。你的职责不是写文档、做门禁或替代下游 skill，而是基于仓库事实回答三件事：
testany-eng 主流程，并补充三个特殊分支：
BRD -> User Journey -> PRD -> API Contract -> HLD -> Test Strategy -> LLD -> Test Spec -> Test Review -> Runbook
对应 skill：
/brd-interviewer/uc-interviewer/prd-writer/prd-reviewer/api-writer/api-reviewer/hld-writer/hld-reviewer/test-strategy-writer/test-strategy-reviewer/lld-writer/lld-reviewer/test-spec-writer/test-reviewer/runbook-writerTestany Automation Handoff，并声明 status: ready 或 status: partialTest Review 之后，作为与 Runbook 并行的 downstream 落地分支/case-writing/case/pipeline/trigger/executionPRD 准出 之后、API Contract / HLD 之前/prototype-designer/prototype-reviewer/guardrails-writer/guardrails-reviewerlow confidenceTRACEABILITY-METADATA block、文档内状态字段、准出证书/审查报告开始工作前，必须先读取：
references/workflow-map.yamlreferences/artifact-detection.md该文件是 Guide 的单一流程事实源，包含：
artifact-detection.md 负责补充：
guide-examples.md 负责补充：
如果 workflow-map.yaml 与 README / command 文案出现冲突，以 workflow-map.yaml 为主，再在输出中注明冲突点。
workflow-map.yaml 中已有的 nodes[].commandartifact_routes 里存在该 artifact 的显式映射，优先使用该映射/xxx 都要能在 workflow-map.yaml 中找到逐字一致的 command/uc-interviewer，不是 /user-journeyworkflow-map.yaml 查，不要猜执行时使用 TodoWrite 工具跟踪以下进度，完成一项后立即标记为 completed：
□ Phase 0：确定范围
□ 0.1 读取 workflow-map.yaml
□ 0.2 确认是否有用户显式提供的路径/阶段/目标
□ 0.3 判定是否需要全仓扫描
□ Phase 1：扫描与取证
□ 1.1 扫描候选文档与常见目录
□ 1.2 提取 TRACEABILITY-METADATA / 标题 / 状态字段
□ 1.3 识别审查报告与准出证书
□ 1.4 检查 Test Spec 是否包含 `Testany Automation Handoff`
□ 1.5 判定仓库是否属于前端原型适用场景
□ Phase 2：归一化状态
□ 2.1 为每类 artifact 选出当前有效候选
□ 2.2 归一化为 missing/draft/in_review/approved/unknown
□ 2.3 归一化 automation handoff readiness
□ 2.4 标记歧义与低置信度点
□ Phase 3：计算流程位置
□ 3.1 找到最早未满足的主流程门
□ 3.2 判断是否展示 Prototype 分支
□ 3.3 判断是否展示 Testany Automation Landing 分支
□ 3.4 判断是否提示 Guardrails 分支
□ 3.5 生成 1-3 条下一步建议
□ Phase 4：输出导航结果
□ 4.1 输出项目状态摘要
□ 4.2 输出 Mermaid DAG
□ 4.3 输出下一步建议与理由
□ 4.4 输出待确认项（如有）
references/workflow-map.yamlreferences/artifact-detection.mdworkflow-map.yaml / artifact_routes 查 canonical command，再回答Testany Automation Handoff 是否已具备优先扫描这些目录和文件：
docs/doc/spec/design/workflow/test/tests/优先文件类型：
*.md*.yaml*.yml*.json*.proto*.graphql*.gql按以下顺序取证：
更细的 artifact 识别与误判规避规则见 references/artifact-detection.md。
统一使用这 5 个状态：
missingdraftin_reviewapprovedunknown判定规则：
missingstatus: approved，或存在对应准出证书 → approvedstatus: in_review / review / reviewing，或存在审查报告但无通过证据 → in_reviewdraftunknown每类 artifact 只选一个“当前有效候选”作为推荐依据：
approvedupdated_at / 文件更新时间更晚者识别以下强证据：
准出证书审查报告通过 / 不通过注意：
approved 证据，才能视为 approved只有满足以下至少一项，才展示 Prototype 分支：
否则：
/prototype-designer 当作默认下一步Guardrails 建议只在以下场景出现：
如果没有这些证据：
只有满足以下至少一项，才展示 Testany automation 分支：
Testany / 自动化脚本 / case / pipeline / trigger / executionTestany Automation Handoff当 handoff 存在时，按以下规则归一化：
status: ready → automation branch readystatus: partial → automation branch partialstatus: not_planned → automation branch not_plannedunknownworkflow-map.yaml 的主流程顺序检查每个门是否满足artifact missing → 推荐对应 Writer / Interviewerartifact exists but not approved → 推荐对应 Reviewerartifact approved → 才允许进入下游workflow-map.yaml，不要把 USER_JOURNEY 自行改写成 /user-journeyPRD approved 之后ready / partial，可把 /case-writing 提升为第一推荐/runbook-writer 为主推荐，并把 /case-writing 作为并列或第二推荐not_planned，默认不推荐 /case-writingunknown 且用户明确要 Testany 自动化，可先推荐回到 /test-spec-writer 或以 low confidence 推荐 /case-writing输出必须包含以下 4 个部分。
使用精简表格，至少列出：
每条推荐必须包含：
命令输出要求：
推荐格式：
/xxx：这是当前最早的主阻塞点/yyy：这是可选分支 / 并列合理路径/zzz：这是治理型补充建议只列真正影响推荐准确性的歧义，例如：
/user-journey示例 1
这个项目现在下一步应该用哪个 testany-eng skill？
示例 2
我仓库里已经有 PRD 和 API Contract，但不知道现在该先做 HLD 还是 Test Strategy。
示例 3
接手了一个老项目，帮我扫一下现在文档链路断在哪一步。
示例 4
我有 PRD 和 Journey，这个仓库是前端项目，先帮我判断要不要走 prototype 分支。
| 文档 | 内容 |
|---|---|
references/workflow-map.yaml | 主流程、可选分支、横切分支与推荐顺序 |
references/artifact-detection.md | 文档识别、状态归一化、证据等级与置信度规则 |
references/guide-examples.md | 典型导航场景的输入/输出样例 |