Minimal Validation

Minimal Validation

Purpose

After a code change, find and run the cheapest validation loop that gives credible evidence the change is correct.

This skill is not for "run everything". It is for:

• narrow tests
• focused lint or type checks
• targeted smoke checks
• tiny local repros
• behavior-preserving refactor verification

Use when

Use this skill when:

• code has just been changed
• the user asks to "check", "verify", "validate", "make sure it works", "run minimal tests", or similar
• a fix, refactor, or feature slice needs lightweight proof
• the user did not specify a validation plan, but some verification is clearly needed

Typical trigger phrases:

• "проверь"
• "провалидаируй"
• "сделай минимальную проверку"
• "запусти только нужные тесты"
• "smoke check this"
• "validate the change"
• "make sure this refactor still works"
• "run the smallest relevant checks"

Do not use when

Do not use this skill for:

• full CI or full regression suites
• benchmark or performance validation
• load or stress testing
• security testing
• release readiness checks
• architecture review
• debugging without code changes
• test authoring as the main goal

If the user explicitly asks for full validation, broad CI, performance checks, or release checks, do that directly instead.

Inputs

Expected inputs:

• the changed files or diff
• the kind of change:
  • bug fix
  • refactor
  • feature slice
  • config or schema change
  • test-only change
• repository conventions and available tooling

Optional inputs:

• repro steps
• failing test or CI output
• nearby tests
• build or run commands
• changed public interfaces

Outputs

Always produce:

1. the chosen minimal validation plan
2. the commands run
3. the result of each check
4. any remaining validation gap or residual risk

Core rule

Choose the smallest check that still meaningfully exercises the changed behavior.

Bias toward:

• one focused unit test over a whole suite
• one package or file-level type check over the entire workspace
• one targeted smoke run over a full application boot sequence
• one narrow repro over a broad integration pass

Constraints

• Read the nearest AGENTS.md before selecting commands.
• Prefer existing tests, scripts, and validation commands over inventing new ones.
• Keep the validation loop cheap by default.
• If narrow validation passes, describe what remains unvalidated instead of overstating confidence.
• Only add new tests when the case is obviously small and strongly justified by the change.

Procedure

1. Inspect what changed. Read the diff and identify:

   • changed files
   • changed behavior
   • whether the change is logic, interface, UI, config, data, or refactor only

2. Inspect local validation affordances. Look for:

   • test framework and nearest tests
   • lint or formatting commands
   • type-check commands
   • package- or module-level verification commands
   • smoke run scripts
   • existing repo conventions from AGENTS.md, README, package files, or scripts

3. Classify the change.

   Common categories:

   • pure logic change
   • behavior-preserving refactor
   • API or interface change
   • UI or frontend change
   • config or schema change
   • CLI or script change
   • data pipeline step change
   • test-only change

4. Pick the narrowest relevant validation.

   For each category, prefer:

   • Pure logic change: focused unit test(s) for the touched function or module

   • Behavior-preserving refactor: the smallest test, build, or smoke check that proves behavior stayed the same

   • API or interface change: targeted test around the touched interface plus type or static checks if relevant

   • UI or frontend change: smallest build, test, preview, or smoke path that exercises the changed screen or component

   • Config or schema change: schema parse, config load, or the narrowest startup path that reads it

   • CLI or script change: targeted command invocation with a minimal fixture or dry-run path

   • Data pipeline step: tiny sample input run, schema check, and output shape assertions

5. Prefer existing tests first. If an existing focused test already covers the touched behavior, run it. If not, run the next-cheapest meaningful check. Only add new tests if they are obviously small and strongly justified.

6. Keep scope tight. Do not escalate to:

   • full suite
   • full workspace type-check
   • full end-to-end run
   • expensive training or data processing unless the narrow checks are insufficient or the user explicitly asks

7. Run checks and interpret results. For each check:

   • report the exact command
   • summarize pass or fail
   • connect the result back to the changed behavior

8. Report residual risk honestly. If the minimal checks pass but there is still an unvalidated surface, say so explicitly.

Decision rules

Minimality rule

Validation should be as cheap as possible, but not cheaper than the changed behavior allows.

Existing-path rule

Prefer existing tests, scripts, and validation commands over inventing new ones.

Refactor rule

For behavior-preserving refactors, prove non-change with the smallest useful check after each meaningful extraction or change.

Escalation rule

Escalate validation scope only if:

• the minimal check fails
• the minimal check does not exercise the changed behavior
• the change affects a wider contract than initially assumed

Honesty rule

A passing narrow check is evidence, not proof of total correctness. Always name the remaining blind spots.

References

Use the supporting references when needed:

• references/validation-matrix.md for change-type to check selection
• references/common-check-patterns.md for common narrow validation shapes
• references/residual-risk-template.md for consistent residual-risk reporting

Definition of done

• The changed behavior has a concrete, minimal validation target.
• The narrowest meaningful checks were chosen and, when possible, executed.
• Commands and outcomes are reported explicitly.
• Coverage is tied back to the actual change.
• Residual risk is stated honestly.

Final response format

Return a compact summary in this structure:

• Validation target: ...
• Chosen checks:
  • <command> — why this is the smallest relevant check
  • <command> — why this is needed
• Results:
  • pass / fail / blocked
• Coverage:
  • what behavior was actually exercised
• Residual risk:
  • what remains unchecked

Positive examples

Use this skill for:

• "проверь изменение"
• "сделай минимальную валидацию"
• "запусти только нужные тесты"
• "проверь, что рефактор ничего не сломал"
• "run the smallest relevant checks"
• "smoke test this change"

Negative examples

Do not use this skill for:

• "прогони весь CI"
• "сделай benchmark"
• "нагрузи сервис"
• "сделай security review"
• "напиши тестовую стратегию на релиз"