메뉴
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에서 현재 제공할 수 있는 파일을 다운로드하세요.
Code review, implementation review, 源码评审、实现复审。Use when: implementation Candidate 已形成，需要基于已批准需求/设计和精确 Git 边界做首次完整 Code Review 或整改 delta 复审。Do not use for API/HLD/LLD/Test/Runbook review or deployment approval.
Prototype review, 原型评审, 交互原型审查。Use when: prototype-designer 完成后、进入 API Contract/HLD 之前需要审查原型的上游对齐、交互完整性、工程隔离和下游可用性。
Write Runbook, 撰写运维手册。Use when: LLD 完成后需要编写部署、回滚、监控、故障处理等运维文档。
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