Produce validation evidence with ak:test

Use ak:test to turn a change or quality question into fresh validation evidence. The Skill can run unit, integration, end-to-end, build, coverage, and browser-based UI checks, then report the commands, results, failures, and gaps without hiding inconvenient output.

Choose ak:test when validation is the outcome

Use ak:test when

• You need focused or broad test evidence after implementation or a bug repair.
• A project needs type, lint, build, or coverage validation before handoff.
• A website needs visual, responsive, accessibility, form, or console checks.
• You need a structured QA report rather than a new implementation.

Choose another workflow when

• A failing test needs root-cause diagnosis and a repair. Use ak:debug, then ak:fix.
• You want production-risk and maintainability findings from a diff. Use ak:code-review.
• You want implementation plus its default testing and review stages. Use ak:cook.
• You need to design the delivery plan rather than execute validation. Use ak:plan.

Prepare the test surface

Before you start:

• Complete Onboarding, and confirm Engineer Kit is installed for the runtime and scope you are using.
• Open the project and provide the change, requirement, failing area, or test scope that should determine the commands.
• Keep the project's test runner, dependencies, fixtures, environment variables, and build tooling available.
• For UI testing, provide the URL and start the required application yourself or explicitly authorize the workflow that starts it.
• For protected UI routes, choose project-native test authentication or approve use of the real Chrome profile and complete any required manual login.

Select code or UI testing

If you provide a scope, the Skill proceeds with relevant code validation. With no arguments, it asks whether to run code tests or UI tests. Use ui <url> to select the browser workflow directly.

/ak:test "Validate the session expiry change: run typecheck, the focused session tests, affected integration tests, and coverage for the changed module."

/ak:test ui http://localhost:3000/settings

/ak:test "Validate the session expiry change: run typecheck, the focused session tests, affected integration tests, and coverage for the changed module."

/ak:test ui http://localhost:3000/settings

$ak:test "Validate the session expiry change: run typecheck, the focused session tests, affected integration tests, and coverage for the changed module."

$ak:test ui http://localhost:3000/settings

Project-defined commands and thresholds take priority. When the project does not define coverage policy, the Skill's reference guidance treats 80% line and 70% branch coverage as general targets, with critical paths receiving special attention.

Understand what happens during a run

1. The Skill determines scope. It connects recent changes or requirements to the smallest useful validation surface and identifies critical paths and error scenarios.
2. The Skill runs pre-flight checks. Type, syntax, lint, or language-specific analysis runs before behavioral tests so compilation failures are visible early.
3. The Skill executes the selected suites. It starts focused, expands to integration or end-to-end coverage when the blast radius requires it, and preserves skipped, flaky, slow, and failed tests.
4. The Skill measures coverage when relevant. It reports line, branch, and function coverage, then identifies uncovered files, error handlers, and edge-case branches instead of relying on one percentage.
5. The Skill verifies the build. It runs the project-appropriate production build when build compatibility belongs to the requested scope.
6. The Skill exercises the UI when selected. It chooses an isolated browser, a profile-aware Chrome path, or project-native browser tests; captures screenshots; and checks interactions, responsiveness, accessibility, and console output.
7. The Skill produces the report. It organizes results, failures, coverage, build status, critical issues, recommendations, and unresolved questions in the configured report location.

Keep test effects controlled

• Test commands may create coverage files, screenshots, build output, temporary data, or browser state. State the allowed artifact locations and cleanup requirements.
• Run suites against a safe test environment. UI flows and end-to-end tests can submit forms or mutate data if the application behaves that way.
• Real Chrome profile testing can access the user's authenticated session. Use it only when that state is required and bind to the exact profile-aware tab.
• External URLs, hosted browsers, performance services, or production-like environments can incur provider or operational cost and need separate authority.
• ak:test reports defects; it does not start implementing fixes. Use ak:debug and ak:fix for that transition.

Verify the report

A complete test result should give you:

• The exact scope and every command executed.
• Totals for passed, failed, and skipped tests, plus duration.
• Complete failed-test names, essential error output, and relevant stack traces.
• Coverage values and concrete gaps when coverage was requested.
• Build status, warnings, and dependency issues when build verification applied.
• UI pages and flows tested, screenshot paths, console findings, viewports, and any skipped browser checks.
• Critical issues and prioritized recommendations.
• Environment, authentication, or evidence limitations listed explicitly.

Treat the run as passing only when the requested checks report zero failures, the build exits successfully when included, and project thresholds are met. A partial or skipped check proves only the surface actually executed.

Troubleshoot or continue

Hand failures to ak:debug and ak:fix, or continue with ak:code-review after the requested validation passes.

Know the current limits

• The Skill is limited to the test runners, browsers, credentials, URLs, and environments available in the current session.
• Coverage percentages do not prove behavior outside the assertions or runtime conditions exercised.
• Visual screenshots do not replace interaction, accessibility, console, or repeatable project-native tests.
• Cursor slash invocation is user-verified evidence, not proof of full runtime parity.
• Stable and beta package the same ak:test operations and report workflow.