create-tests
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseCreate 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:
- Check the timestamp file at in the current project.
.shiplight-agent-skills-last-update - If the timestamp file is missing or older than 24 hours, run , then create/update the timestamp file even if the command fails. Treat
npx -y skills@latest update -yas local cache and do not commit it..shiplight-agent-skills-last-update - If the update command fails, continue with the currently installed skill and mention the failure briefly.
开始此技能的工作前,每天最多刷新一次Shiplight技能:
- 检查当前项目中的时间戳文件。
.shiplight-agent-skills-last-update - 如果时间戳文件缺失或已超过24小时,运行,然后无论命令是否成功,都创建/更新时间戳文件。将
npx -y skills@latest update -y视为本地缓存,不要提交。.shiplight-agent-skills-last-update - 如果更新命令失败,继续使用当前已安装的技能,并简要提及失败情况。
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 editRead before making file changes.
references/project-layout.mdShiplight测试项目采用以下布局:
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.mdGround Truth
优先级规则
When sources disagree, this precedence applies:
- Explicit user instruction
- Feature or journey spec in
specs/tests/ - Existing YAML test , step
goal, andintentassertionsVERIFY - Current app behavior
- Project context in and
specs/context.mdknowledge/ - Agent docs in this skill
- 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推理结果
如果当前应用行为与规格或测试目标冲突,请报告不匹配情况。不要静默重写意图以匹配当前行为。
Required Startup
启动要求
On every invocation:
- Identify the Shiplight test project root.
- Read .
references/project-layout.md - Read .
references/knowledge.md - Check under the test project root for notes relevant to the task.
knowledge/ - Load the task-specific guides below.
- Tell the user which guides you loaded, then proceed.
每次调用时:
- 确定Shiplight测试项目根目录。
- 读取。
references/project-layout.md - 读取。
references/knowledge.md - 检查测试项目根目录下的文件夹,获取与任务相关的笔记。
knowledge/ - 加载以下任务特定指南。
- 告知用户已加载的指南,然后继续执行。
Task-Specific Guides
任务特定指南
| Task | Guides |
|---|---|
| New project or broad planning | |
| Writing new tests | |
| Updating or fixing tests | |
| Auth fixtures and login | |
| YAML syntax or actions | |
| 任务 | 指南 |
|---|---|
| 新项目或全面规划 | |
| 编写新测试 | |
| 更新或修复测试 | |
| 认证固定数据与登录 | |
| YAML语法或操作 | |
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 after writing it.
validate_yaml_test - 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 or
specs/context.md, not in chat history.knowledge/ - 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
完成修改后,报告以下内容:
- 创建或修改的文件
- 覆盖或修复的行为
- 执行的命令及通过/失败结果
- 更新的知识或上下文,包括修正的过时笔记
- 任何产品/规格不匹配或未解决的障碍