// Use when making small or localized changes that could still affect user-visible behavior, API contracts, database queries, test runtime, CI, generated artifacts, or cross-layer data flow.
Use when Go test wall time is too high, CI test duration regresses, a package needs trace-driven test performance analysis, or tests should be made safely parallel with t.Parallel, package splitting, subprocess isolation, semaphores, or Go built-in tracing.
Use when working on middleman local development sessions that need backend and frontend on ephemeral/free ports, isolated generated config, copied SQLite state, or dev-ephemeral status JSON/PIDs.
Use when creating, editing, fixing, or reviewing tests; when adding mocks, assertions, smoke tests, unit tests, integration tests, e2e tests, or changing tests after failures.
Simplifies code for clarity. Use when refactoring code for clarity without changing behavior. Use when code works but is harder to read, maintain, or extend than it should be. Use when reviewing code that has accumulated unnecessary complexity.
Use when a screenshot or short video needs to be captured with Playwright and saved to local disk, with optional upload through `gh image` (upload requires explicit user approval and must target a PR or issue).
CLI tools for Svelte 5 documentation lookup and code analysis. MUST be used whenever creating, editing or analyzing any Svelte component (.svelte) or Svelte module (.svelte.ts/.svelte.js). If possible, this skill should be executed within the svelte-file-editor agent for optimal results.
| name | small-change-verification |
| description | Use when making small or localized changes that could still affect user-visible behavior, API contracts, database queries, test runtime, CI, generated artifacts, or cross-layer data flow. |
Small changes fail when their real blast radius is misread. Before editing, name the kind of change and the most likely place a regression would be noticed.
Use for modest follow-up work such as:
Small means scoped, not exempt from repository requirements. Do not use this for large feature design; use a planning or docs-grilling workflow first.
Pick the smallest matching class:
| Class | Typical files | Main regression question |
|---|---|---|
ui-only | Svelte components, stores, CSS | What visible workflow or persisted UI state could break? |
api-contract | Huma routes, API types, generated clients | What client contract or generated artifact changes? |
db-query | queries, migrations, filters | What persisted or sorted result would the user notice? |
test-runtime | Playwright, CI, scripts, Makefile | Does local execution match the failing or intended runtime? |
provider-visible | platform clients, capabilities, routes | Which provider, host, or capability boundary is affected? |
Write one sentence before editing:
This is a <class> change; the likely regression surface is <observable behavior>.
If multiple classes apply, use the strictest relevant checks.
| Class | Minimum verification |
|---|---|
ui-only | Relevant component/store test; affected Playwright or full-stack e2e when the change alters a visible workflow. |
api-contract | make api-generate, review checked-in OpenAPI/client diffs, and run the narrow Go/API test that consumes the contract. |
db-query | Query/unit test with literal expected rows, plus server/API test when HTTP output changes. |
test-runtime | Re-run the exact affected command in the same runtime shape: container, browser, env var, or CI script path. |
provider-visible | Provider/package test plus server/API or UI capability test at the boundary users see. |
If one class points at another, run both checks. Example: a DB-backed search fix is usually db-query and API-visible.
The classification sentence is written, applicable checks have run, skipped checks are justified, generated diffs are reviewed when present, and failures are investigated before completion.
context/testing.mdcontext/ui-interaction-contracts.mdcontext/platform-sync-invariants.mdcontext/provider-architecture.md