triage

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Triage Failing Tests

排查失败测试

Daily Skill Update Check

每日技能更新检查

Before starting this skill's work, opportunistically refresh Shiplight skills at most once per day:

Check the timestamp file at
```
.shiplight-agent-skills-last-update
```
in the current project.
If the timestamp file is missing or older than 24 hours, run
```
npx -y skills@latest update -y
```
, then create/update the timestamp file even if the command fails. Treat
```
.shiplight-agent-skills-last-update
```
as local cache and do not commit it.
If the update command fails, continue with the currently installed skill and mention the failure briefly.

Use this skill to reproduce, diagnose, and repair failing Shiplight YAML tests. If the application is broken or current behavior conflicts with the spec, report the mismatch instead of rewriting the test around it.

开始本技能的工作前，每天最多可主动刷新一次Shiplight技能：

检查当前项目中的
```
.shiplight-agent-skills-last-update
```
时间戳文件。
如果时间戳文件缺失或已超过24小时，运行
```
npx -y skills@latest update -y
```
，即使命令失败也要创建/更新时间戳文件。将
```
.shiplight-agent-skills-last-update
```
视为本地缓存，无需提交。
如果更新命令失败，继续使用当前已安装的技能，并简要提及失败情况。

使用本技能来复现、诊断和修复失败的Shiplight YAML测试。如果应用程序出现故障或当前行为与规范冲突，请报告不匹配情况，而非围绕该情况重写测试。

When To Use

使用场景

Use

/triage

when:

A Shiplight test run is failing
A deployment or UI change broke existing tests
Several tests may share the same failure source
CI needs a best-effort repair/report pass

Skip

/triage

when:

Creating new tests from scratch; use
```
/create-tests
```
Verifying UI code changes without failing tests; use
```
/verify
```
Tests pass and the task is only quality improvement
The product is being intentionally redesigned and tests need planned rewriting

在以下情况使用

/triage

：

Shiplight测试运行失败
部署或UI更改导致现有测试失效
多个测试可能存在相同的故障根源
CI需要进行最大努力的修复/报告处理

在以下情况跳过

/triage

：

从头创建新测试；请使用
```
/create-tests
```
在无失败测试的情况下验证UI代码更改；请使用
```
/verify
```
测试通过且任务仅为质量改进
产品正在进行有意的重新设计，需要有计划地重写测试

Required Context

必要前置信息

Before editing YAML:

Read the

create-tests

reference guides

project-layout.md

updating-tests.md

test-implementation-guide.md

, and

knowledge.md

Read relevant
```
knowledge/
```
notes for the failing area, environment, auth, data, and tooling.
Read the matching spec under
```
specs/tests/
```
, if one exists.

Read

shiplight://yaml-test-spec

and

shiplight://schemas/action-entity

编辑YAML前：

阅读

create-tests

参考指南

project-layout.md

、

updating-tests.md

、

test-implementation-guide.md

和

knowledge.md

。

阅读故障相关领域、环境、认证、数据和工具的
```
knowledge/
```
笔记。
阅读
```
specs/tests/
```
下对应的规范（如果存在）。

阅读

shiplight://yaml-test-spec

和

shiplight://schemas/action-entity

。

Ground Truth

优先级规则

When sources disagree, this precedence applies:

Explicit user instruction
Feature or journey spec in
```
specs/tests/
```
Existing YAML test
```
goal
```
, step
```
intent
```
, and
```
VERIFY
```
assertions
Current app behavior
Project context in
```
specs/context.md
```
and
```
knowledge/
```
Agent docs
Agent inference

If current app behavior conflicts with a spec or test goal, report the mismatch. Do not silently rewrite intent to match current behavior.

当信息来源出现冲突时，遵循以下优先级：

用户明确指令
```
specs/tests/
```
中的功能或流程规范
现有YAML测试的
```
goal
```
、步骤
```
intent
```
和
```
VERIFY
```
断言
当前应用程序行为
```
specs/context.md
```
和
```
knowledge/
```
中的项目上下文
Agent文档
Agent推断

如果当前应用程序行为与规范或测试目标冲突，请报告不匹配情况。不要静默重写意图以匹配当前行为。

Workflow

工作流程

Reproduce — run the specified target, or the narrowest relevant suite if no target was provided. If a failure looks transient, rerun the smallest affected target once before editing.
Understand — read the failure output, relevant YAML, matching spec, related tests, and shared templates/functions/hooks before opening a browser or changing files.
Inspect when needed — when logs and files are not enough, inspect the live app in a browser. Use the evidence needed for the failure: DOM, actions, locators, console logs, network logs, screenshots, or recordings.
Fix minimally — change the smallest correct surface: YAML, template, helper function, auth setup, environment data, or spec. Do not touch passing tests unless they share the same broken source.
Validate and rerun — validate edited YAML with
```
validate_yaml_test
```
, then rerun the narrowest changed target. After batch fixes, rerun the original target once.
Reflect — update specs,
```
specs/context.md
```
, or
```
knowledge/
```
when the session produced durable learning or corrected stale assumptions.

复现 — 运行指定的目标，如果未提供目标则运行范围最窄的相关测试套件。如果故障看起来是暂时的，在编辑前重新运行受影响最小的目标一次。
理解 — 在打开浏览器或修改文件前，阅读故障输出、相关YAML、匹配的规范、相关测试以及共享模板/函数/钩子。
按需检查 — 当日志和文件不足以排查时，在浏览器中检查实时应用程序。使用故障排查所需的证据：DOM、操作、定位器、控制台日志、网络日志、截图或录屏。
最小化修复 — 修改最小范围的正确内容：YAML、模板、辅助函数、认证设置、环境数据或规范。除非共享相同的故障根源，否则不要修改通过的测试。
验证并重新运行 — 使用
```
validate_yaml_test
```
验证编辑后的YAML，然后重新运行范围最窄的已更改目标。批量修复后，重新运行一次原始目标。
复盘更新 — 当本次会话产生可持久化的知识或纠正了过时假设时，更新规范、
```
specs/context.md
```
或
```
knowledge/
```
。

Guardrails

约束规则

Do not guess rendered UI when the failure depends on current browser behavior.
Do not delete assertions, skip required steps, or reduce coverage only to make a test pass.
If intended product behavior changed, update the matching spec before updating YAML.
If the app is broken, report the app issue instead of masking it with test changes.
Preserve user changes and unrelated work.
Prefer focused fixes over broad rewrites.
Keep ACTION locators and VERIFY
```
js:
```
caches current when editing affected steps, but do not churn unrelated caches.
In CI or non-interactive mode, do not block on user input. Make conservative best-effort decisions and document uncertainty.

Common causes include stale locators, changed user flows, assertion drift, expired auth, timing, shared templates/hooks, invalid parameter data, environment issues, and real app bugs. Use evidence to decide the minimal correct fix.

当故障依赖当前浏览器行为时，不要猜测渲染后的UI。
不要删除断言、跳过必要步骤或仅为了让测试通过而降低覆盖率。
如果预期的产品行为发生变化，请在更新YAML前更新匹配的规范。
如果应用程序出现故障，请报告应用程序问题而非通过修改测试来掩盖。
保留用户更改和无关工作内容。
优先选择针对性修复而非大范围重写。
编辑受影响步骤时，保持ACTION定位器和VERIFY
```
js:
```
缓存为最新状态，但不要修改无关的缓存。
在CI或非交互模式下，不要阻塞等待用户输入。做出保守的最大努力决策并记录不确定性。

常见原因包括过时的定位器、更改的用户流程、断言偏差、过期的认证、时序问题、共享模板/钩子、无效的参数数据、环境问题以及实际应用程序bug。使用证据来确定最小化的正确修复方案。

Reporting

报告要求

After triage, report:

Target command(s) run and pass/fail result
Files changed
Tests repaired, skipped, still failing, or already passing
Behavior covered or restored
App/spec mismatches or unresolved blockers
Knowledge, context, or specs updated

排查完成后，报告以下内容：

运行的目标命令及通过/失败结果
修改的文件
已修复、跳过、仍失败或已通过的测试
覆盖或恢复的行为
应用/规范不匹配情况或未解决的障碍
更新的知识、上下文或规范