菜单
Run the gotit E2E suite (full or filtered) via `go test -run`, with feature-flag and verbosity overrides, and summarize the result. Invoke when the user asks to "run the e2e tests", "run wave2 only", or to verify a single spec after editing.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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.
| name | gotit-run-suite |
| description | Run the gotit E2E suite (full or filtered) via `go test -run`, with feature-flag and verbosity overrides, and summarize the result. Invoke when the user asks to "run the e2e tests", "run wave2 only", or to verify a single spec after editing. |
| version | 1 |
Run the suite or a slice of it. Three execution modes are supported.
gotit (TUI)If the gotit binary is installed (go install github.com/shivamstaq/gotit/cmd/gotit@latest), prefer the TUI for local development:
cd <project-root>
gotit
Use r to run one spec, a to run all (or all matching the active filter), R to reset state, s to stop a runaway. Live step output streams into the right pane. See the gotit-tui skill for the full keybinding table.
gotit runFor CI or scripts where the TUI isn't appropriate:
gotit run # all specs
gotit run wave1 # one wave
gotit run wave3/risk # one spec
gotit run wave3 -- -count=1 -race -v # forward extra flags to `go test`
gotit run shells to go test under the hood with the right -run filter.
go testThe original CI surface still works exactly as before:
| Goal | Command |
|---|---|
| Full suite | go test ./tests/e2e/ -v |
| One wave | go test ./tests/e2e/ -run 'TestE2E/wave2' -v |
| One spec | go test ./tests/e2e/ -run 'TestE2E/wave2/journey-foo' -v |
| Specs matching a pattern | go test ./tests/e2e/ -run 'TestE2E/.*/journey-.*' -v |
| Force-enable feature flags | <PREFIX>_E2E_FEATURES=flag1,flag2 go test ./tests/e2e/ -v |
| Force-enable everything | <PREFIX>_E2E_FEATURES=all go test ./tests/e2e/ -v |
| Tighten parallelism | go test ./tests/e2e/ -parallel 2 -v |
| With race detector | go test ./tests/e2e/ -race -v |
The subtest naming is always TestE2E/<wave>/<name>. There is no tag-based filtering built in; if you need it, write a one-off helper that reads YAML and prints names matching, then feed those names into -run.
Confirm the project has a suite. If tests/e2e/runner_test.go doesn't exist, point the user at gotit-bootstrap first.
Pick the right scope. Default to the smallest scope that answers the user's question:
Run with -v. The verbose output (one line per step) is what gotit-diagnose-failure consumes if anything fails.
Summarize. Report:
If everything passed, mention the JSONL log path so the user has it for future debugging.
-parallel 1, there's a real isolation bug — investigate, don't paper over.-count=1 defeats Go's test cache. The suite is fully I/O-bound (it execs binaries), so caching doesn't usually help; if a spec is "passing" but the CLI's been edited, the fresh binary build in TestMain ensures the test actually exercises the new code.-failfast for the full suite; the parallel subtest model means you'll lose useful information about other failures.Specs that use daemons: or background: true add real-time overhead: readiness polling (default ~5s upper bound), stop.grace delay (default 5s) at teardown, and any start_timeout budget. A wave with five daemon specs running in parallel can take 15-30s. Either:
-timeout 120s (or higher) explicitly when running daemon-heavy waves.start_timeout / stop.grace in specs that don't need them — but only when those tighter bounds reflect real requirements; don't tune for speed at the cost of masking shutdown bugs.If a daemon spec hangs, it's almost always the daemon under test failing to shut down. The test harness will SIGKILL after stop.grace and surface the failure; the wait is bounded.