菜单
Guide, workflow guide, 流程导航、我该用哪个 skill、下一步做什么。Use when: 需要扫描当前项目已有文档、实现 Candidate 和准出状态，判断 testany-eng 流程所处阶段，并推荐下一步最合适的 skill；也可路由到 Code Review 或 Testany 自动化落地分支。
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/TestAny-io/testany-agent-skills --skill guide命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
| name | guide |
| description | Guide, workflow guide, 流程导航、我该用哪个 skill、下一步做什么。Use when: 需要扫描当前项目已有文档、实现 Candidate 和准出状态，判断 testany-eng 流程所处阶段，并推荐下一步最合适的 skill；也可路由到 Code Review 或 Testany 自动化落地分支。 |
语言规则：默认跟随用户输入语言；用户显式指定时以用户指定为准；不要因为本
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
LLD 准出后还存在一条与测试文档准备并行的实现门禁：
Implementation Candidate -> Code Review -> exact-SHA CI / PR / merge
对应 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/code-reviewer（仅当 exact Implementation Candidate 已存在）/test-spec-writer/test-reviewer/runbook-writerTestany Automation Handoff，并声明 status: ready 或 status: partialTest Review 之后，作为与 Runbook 并行的 downstream 落地分支/case-writing/case/pipeline/trigger/execution/code-reviewerPRD 准出 之后、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 判定仓库是否属于前端原型适用场景
□ 1.6 检测是否存在 exact Implementation Candidate / Code Review 证据
□ Phase 2：归一化状态
□ 2.1 为每类 artifact 选出当前有效候选
□ 2.2 归一化为 missing/draft/in_review/approved/unknown
□ 2.3 归一化 automation handoff readiness
□ 2.4 标记歧义与低置信度点
□ 2.5 归一化 Implementation Candidate 的 review 状态
□ Phase 3：计算流程位置
□ 3.1 找到最早未满足的主流程门
□ 3.2 判断是否展示 Prototype 分支
□ 3.3 判断是否展示 Testany Automation Landing 分支
□ 3.4 判断是否提示 Guardrails 分支
□ 3.5 判断是否展示 Code Review 实现门禁
□ 3.6 生成 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 / 文件更新时间更晚者Code Review 特例（优先于上述 artifact 类型/状态偏好）：
prior_terminal_chain 重建顺序，只选择链上最新的 immediate terminal；先按当前宿主的 Skill 资源解析规则定位已安装 code-reviewer 的绝对目录（Claude plugin 中 ${CLAUDE_PLUGIN_ROOT}/skills/code-reviewer 只是一个平台特定解析方式，Codex 等宿主不得假设该环境变量存在），记录所解析脚本的绝对路径与 SHA-256，再用同一 scripts/terminal_artifact_envelope.py 依次执行 verify 和 extract 读取原始 terminal bytes。不能从 PASS 摘要推断字段；不得因为旧 artifact 是 certificate 或 verdict 为 APPROVED 就压过更新的 CHANGES_REQUIRED / SCOPE_DECISION_REQUIRED / EVIDENCE_BLOCKEDunknown 并报告歧义，不得猜测旧 approval 仍有效artifact-detection.md 逐仓验证：每个实际 mutable repository 都用该行记录的 script digest 与完整 argv 重算相同 snapshot，immutable 行只核对 exact SHA/tree。任一 mutable 行缺失、无法重算或不匹配，或任一 immutable 行漂移，都会使整个 comment stale，不能视为 approved识别以下强证据：
准出证书审查报告通过 / 不通过注意：
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_plannedunknown只有满足以下至少一项，才展示 /code-reviewer：
状态按 artifact-detection.md 的 IMPLEMENTATION_CANDIDATE 规则归一化。仅有 feature branch 或普通 HEAD 时保持 unknown，不得凭空推荐。
workflow-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/code-reviewerinitial_full_coverage_complete: YES、required source/local validation 完成、scope_decision_blocked_ranges: []、evidence_or_assignment_gaps: []；全部 prior P0/P1 必须有稳定 ID并可逐项结转（可保持 OPEN，由本次 delta 判定 closure），而影响 delta eligibility 的 prior SD/EB 必须已有 Owner decision/恢复证据并按 policy 关闭，才推荐 /code-reviewer 的 delta review/code-reviewer 由 canonical policy决定 exceptional/new-initial/process-blocked mode输出必须包含以下 4 个部分。
使用精简表格，至少列出：
每条推荐必须包含：
命令输出要求：
推荐格式：
/xxx：这是当前最早的主阻塞点/yyy：这是可选分支 / 并列合理路径/zzz：这是治理型补充建议只列真正影响推荐准确性的歧义，例如：
/user-journey示例 1
这个项目现在下一步应该用哪个 testany-eng skill？
示例 2
我仓库里已经有 PRD 和 API Contract，但不知道现在该先做 HLD 还是 Test Strategy。
示例 3
接手了一个老项目，帮我扫一下现在文档链路断在哪一步。
示例 4
我有 PRD 和 Journey，这个仓库是前端项目，先帮我判断要不要走 prototype 分支。
示例 5
开发已经给出 base/Candidate SHA 和 review request，帮我判断下一步是不是 Code Review。
| 文档 | 内容 |
|---|---|
references/workflow-map.yaml | 主流程、可选分支、横切分支与推荐顺序 |
references/artifact-detection.md | 文档识别、状态归一化、证据等级与置信度规则 |
references/guide-examples.md | 典型导航场景的输入/输出样例 |
WORKTREE@sha256 仅获 Mutable Worktree Review Comment → 先 commit/freeze，再加入 MUTABLE_TO_IMMUTABLE_REBIND，由 /code-reviewer 按全部共存 causes 和全局 precedence选择 full-review mode（没有更高优先 cause时为 initial full）；不能直接路由 CI/PR/merge