# Small Change Verification

> 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.

- Skill: `kenn-io/small-change-verification` (Agent Skill)
- Install (CLI): `npx skillmds@latest add kenn-io/small-change-verification`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kenn-io/small-change-verification/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: kenn-io (https://skillmd.com/u/kenn-io)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/kenn-io/small-change-verification

---


# Small Change Verification

## Core Idea

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.

## When to Use

Use for modest follow-up work such as:

- fixing a focused UI behavior;
- adjusting a DB query, filter, sort, or search condition;
- changing Huma routes, response types, generated clients, or API errors;
- touching Playwright, CI, test scripts, or runtime config;
- updating provider-visible behavior without adding a whole provider.

Small means scoped, not exempt from repository requirements. Do not use this for large feature design; use a planning or docs-grilling workflow first.

## Classify 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:

```text
This is a <class> change; the likely regression surface is <observable behavior>.
```

If multiple classes apply, use the strictest relevant checks.

## Minimum 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.

## Done When

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 Map

- API, DB, provider, and e2e boundaries: `context/testing.md`
- UI state, route identity, persistence, and interaction behavior: `context/ui-interaction-contracts.md`
- Provider identity, host scoping, and capability rules: `context/platform-sync-invariants.md`
- Provider package layout and route helpers: `context/provider-architecture.md`

## Common Mistakes

- Calling a change "just config" when it changes CI runtime or browser behavior.
- Testing only the narrow helper when the user sees the behavior through HTTP or UI.
- Updating generated files without reviewing whether the public contract should have changed.
- Adding a Playwright assertion for visibility but skipping the component/store state that caused it.