菜单
Open a new wave directory or close an existing one — flip its feature flags, rename files for archival, and update the AGENTS/README pointers. Invoke at release boundaries, when the user says "open wave3" or "ship the rename-detection feature".
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | gotit-ship-wave |
| description | Open a new wave directory or close an existing one — flip its feature flags, rename files for archival, and update the AGENTS/README pointers. Invoke at release boundaries, when the user says "open wave3" or "ship the rename-detection feature". |
| version | 1 |
Run two operations: opening a new wave and closing an existing one (flipping flags + archiving).
Pick a wave name. Conventional: wave1, wave2, wave2.5, wave3. The name is a directory; 1, 2, 2.5 is the de facto sort key. Decimal waves are fine for in-flight bug fixes that don't merit a full integer bump.
Create the directory: tests/e2e/specs/<wave>/. If the project uses an errors/ subdir convention, create tests/e2e/specs/<wave>/errors/ too.
Optional: drop a .gitkeep so the empty dir lands in git.
Update tests/e2e/features.yaml with a new section header comment for the wave's flags:
enabled:
# ==============================================================
# Wave 3 — <theme>
# ==============================================================
rename-detection: false
co-change-windows: false
Tell the user: "Wave 3 opened at tests/e2e/specs/wave3/. Add specs with gotit-add-spec (default order will start at 10)."
Closing means: every flag for the wave's features is true, every spec passes, and the wave is "frozen" in the sense that subsequent feature work goes to the next wave.
List the wave's specs and their requires: entries:
grep -h "feature:" tests/e2e/specs/wave3/*.yaml
For each flag, confirm with the user that the underlying feature has shipped, then flip in features.yaml:
rename-detection: true # was false
Run the wave to confirm everything passes now:
go test ./tests/e2e/ -run 'TestE2E/wave3' -v
If a spec was always meant to be skipped post-ship (e.g. it tested an interim behavior that the final implementation removed), delete the spec. Don't leave it as a permanent skip.
Update any wave-level docs (e.g. a docs/changelog.md line, a WAVES.md table) to mark the wave as shipped with a date.
true without running the wave to confirm. The flag is a CI gate, not a wish.Register a project-local assertion type (the `x-` prefix family) when the 8 built-ins (exit_code, contains, not_contains, stderr_contains, regex, json_path, count, golden_file) cannot express the check. Invoke only when a built-in genuinely doesn't fit.
Author one YAML spec under tests/e2e/specs/<wave>/ that exercises a daemon/server/long-running process — with readiness polling, clean-shutdown verification, and optional log assertions. Invoke when the user asks to "write an e2e test for the server", "spec the daemon", "test the watch subcommand", "verify graceful shutdown", or any test that needs a process running in the background while other steps run.
Author one YAML spec under tests/e2e/specs/<wave>/ for one CLI feature, with appropriate assertions and an auto-rendered sidecar notes file. Invoke when the user asks to "write an e2e test for X", "add a spec for the Y subcommand", or to verify a CLI feature end-to-end.
One-shot setup of the gotit E2E test suite in a Go CLI project — wires runner_test.go, features.yaml, AGENTS.md, .gitignore, and a passing smoke spec. Invoke when the user asks to "add e2e tests", "set up gotit", or "scaffold end-to-end tests" in a Go project.
Read the most recent JSONL log under tests/e2e/results/, identify the failed step, classify the failure, and propose a fix or open a tracking issue. Invoke when a test fails locally or in CI and the user wants to debug it.
Convert an existing CLI test suite (bats, expect, pytest+subprocess, Makefile-driven shell scripts) into gotit YAML specs. Invoke when the user is migrating an established test suite to gotit.