create-tests

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Create Shiplight Tests

创建Shiplight测试

This is the single entry point for Shiplight E2E test work.
Use this skill when the user wants to:
  • Create a new local Shiplight test project
  • Add YAML tests for a web application
  • Update or fix existing Shiplight YAML tests
  • Set up or repair environments, accounts, or auth fixtures
  • Plan what product behavior should be tested
这是Shiplight E2E测试工作的唯一入口。
当用户需要以下操作时使用此技能:
  • 创建新的本地Shiplight测试项目
  • 为Web应用添加YAML测试
  • 更新或修复现有的Shiplight YAML测试
  • 搭建或修复环境、账户或认证固定数据
  • 规划应测试的产品行为

Daily Skill Update Check

每日技能更新检查

Before starting this skill's work, opportunistically refresh Shiplight skills at most once per day:
  1. Check the timestamp file at
    .shiplight-agent-skills-last-update
    in the current project.
  2. 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.
  3. If the update command fails, continue with the currently installed skill and mention the failure briefly.
开始此技能的工作前,每天最多刷新一次Shiplight技能:
  1. 检查当前项目中的
    .shiplight-agent-skills-last-update
    时间戳文件。
  2. 如果时间戳文件缺失或已超过24小时,运行
    npx -y skills@latest update -y
    ,然后无论命令是否成功,都创建/更新时间戳文件。将
    .shiplight-agent-skills-last-update
    视为本地缓存,不要提交。
  3. 如果更新命令失败,继续使用当前已安装的技能,并简要提及失败情况。

Test Project Root

测试项目根目录

Before reading or writing project files, identify the Shiplight test project root. All paths in this skill are relative to that root.
If the root is not clear, ask the user to confirm it before creating or moving files.
在读取或写入项目文件前,确定Shiplight测试项目的根目录。本技能中的所有路径均相对于该根目录。
如果根目录不明确,请在创建或移动文件前请求用户确认。

Canonical Project Layout

标准项目布局

Shiplight test projects use this layout:
text
specs/context.md       project-level app, risk, data, and environment context
specs/tests/           Markdown specs, each covering a feature or journey group
tests/                 executable Shiplight YAML tests
environments/          environment files, one per target deployment
auth/                  auth login modules, if needed
templates/             reusable YAML statement groups, if any
functions/             TypeScript helper functions, if any
files/                 fixture files, if any
knowledge/             durable notes discovered by agents
test-results/          generated runtime artifacts; do not edit
shiplight-report/      generated reports; do not edit
.shiplight/            local Shiplight state; do not edit
Read
references/project-layout.md
before making file changes.
Shiplight测试项目采用以下布局:
text
specs/context.md       项目级别的应用、风险、数据和环境上下文
specs/tests/           Markdown格式的测试规格,每个文件涵盖一个功能或流程组
tests/                 可执行的Shiplight YAML测试文件
environments/          环境配置文件,每个目标部署对应一个文件
auth/                  认证登录模块(如有需要)
templates/             可复用的YAML语句组(如有)
functions/             TypeScript辅助函数(如有)
files/                 固定数据文件(如有)
knowledge/             Agent发现的持久化笔记
test-results/          生成的运行时产物;请勿编辑
shiplight-report/      生成的报告;请勿编辑
.shiplight/            Shiplight本地状态;请勿编辑
在修改文件前,请阅读
references/project-layout.md

Ground Truth

优先级规则

When sources disagree, this precedence applies:
  1. Explicit user instruction
  2. Feature or journey spec in
    specs/tests/
  3. Existing YAML test
    goal
    , step
    intent
    , and
    VERIFY
    assertions
  4. Current app behavior
  5. Project context in
    specs/context.md
    and
    knowledge/
  6. Agent docs in this skill
  7. 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.
当信息来源存在冲突时,遵循以下优先级:
  1. 用户明确指令
  2. specs/tests/
    中的功能或流程规格
  3. 现有YAML测试的
    goal
    、步骤
    intent
    VERIFY
    断言
  4. 当前应用行为
  5. specs/context.md
    knowledge/
    中的项目上下文
  6. 本技能中的Agent文档
  7. Agent推理结果
如果当前应用行为与规格或测试目标冲突,请报告不匹配情况。不要静默重写意图以匹配当前行为。

Required Startup

启动要求

On every invocation:
  1. Identify the Shiplight test project root.
  2. Read
    references/project-layout.md
    .
  3. Read
    references/knowledge.md
    .
  4. Check
    knowledge/
    under the test project root for notes relevant to the task.
  5. Load the task-specific guides below.
  6. Tell the user which guides you loaded, then proceed.
每次调用时:
  1. 确定Shiplight测试项目根目录。
  2. 读取
    references/project-layout.md
  3. 读取
    references/knowledge.md
  4. 检查测试项目根目录下的
    knowledge/
    文件夹,获取与任务相关的笔记。
  5. 加载以下任务特定指南。
  6. 告知用户已加载的指南,然后继续执行。

Task-Specific Guides

任务特定指南

TaskGuides
New project or broad planning
references/workflow.md
,
references/project-layout.md
,
references/test-design-guide.md
Writing new tests
references/new-tests.md
,
references/test-design-guide.md
,
references/test-implementation-guide.md
Updating or fixing tests
references/updating-tests.md
,
references/test-design-guide.md
,
references/test-implementation-guide.md
Auth fixtures and login
references/auth.md
YAML syntax or actions
references/test-implementation-guide.md
; also read
shiplight://yaml-test-spec
and
shiplight://schemas/action-entity
before writing YAML
任务指南
新项目或全面规划
references/workflow.md
,
references/project-layout.md
,
references/test-design-guide.md
编写新测试
references/new-tests.md
,
references/test-design-guide.md
,
references/test-implementation-guide.md
更新或修复测试
references/updating-tests.md
,
references/test-design-guide.md
,
references/test-implementation-guide.md
认证固定数据与登录
references/auth.md
YAML语法或操作
references/test-implementation-guide.md
;编写YAML前还需阅读
shiplight://yaml-test-spec
shiplight://schemas/action-entity

Core Rules

核心规则

  • Always produce durable artifacts unless the user explicitly asks to skip them.
  • Specs describe feature or journey-group confidence. A spec may map to many smaller YAML tests.
  • Keep YAML tests focused. One YAML test should verify one logical journey or variant.
  • Do not write YAML from imagination. Walk the app in a browser first and capture real locators.
  • Validate YAML with
    validate_yaml_test
    after writing it.
  • Reflect before finishing. Capture durable knowledge learned from the user or the work, and update stale knowledge instead of leaving contradictions.
  • Keep context current. Durable project knowledge belongs in
    specs/context.md
    or
    knowledge/
    , not in chat history.
  • Never store raw secrets. Commit only variable names, roles, access patterns, and setup instructions.
  • 除非用户明确要求跳过,否则始终生成持久化产物。
  • 测试规格描述功能或流程组的测试覆盖度。一个规格可对应多个小型YAML测试。
  • 保持YAML测试的专注性。一个YAML测试应验证一个逻辑流程或变体。
  • 不要凭空编写YAML。先在浏览器中操作应用,捕获真实定位器。
  • 编写YAML后使用
    validate_yaml_test
    进行验证。
  • 完成前进行复盘。记录从用户或工作中获得的持久化知识,更新过时知识以避免矛盾。
  • 保持上下文最新。持久化项目知识应存储在
    specs/context.md
    knowledge/
    中,而非聊天记录。
  • 切勿存储原始密钥。仅提交变量名、角色、访问模式和搭建说明。

User Checkpoints

用户检查点

For broad test creation, confirm the planned outcomes before implementation:
Do these outcomes match the confidence you need from this test project? Any business-critical outcome missing or incorrectly out of scope?
For narrow requests such as "fix this failing test" or "add this one test", proceed without a broad checkpoint unless the spec is ambiguous or conflicts with app behavior.
对于全面的测试创建工作,在实施前确认计划的测试成果:
这些成果是否符合您对该测试项目的覆盖需求?是否有遗漏的业务关键成果或错误地排除在范围外的内容?
对于诸如“修复这个失败的测试”或“添加这一个测试”等狭义请求,除非规格不明确或与应用行为冲突,否则无需进行全面检查。

Final Report

最终报告

After changes, report:
  • Files created or changed
  • Behavior covered or repaired
  • Commands run and pass/fail result
  • Knowledge or context updated, including stale notes corrected
  • Any product/spec mismatch or unresolved blocker
完成修改后,报告以下内容:
  • 创建或修改的文件
  • 覆盖或修复的行为
  • 执行的命令及通过/失败结果
  • 更新的知识或上下文,包括修正的过时笔记
  • 任何产品/规格不匹配或未解决的障碍