DevFoundry/.devfoundry/skills/regression-check.md

Skill: Regression Check

Purpose: Validate that a change has not broken existing functionality, especially in legacy stacks lacking automated test coverage.

Steps

1. Re-read the spec's Acceptance Criteria and Verification Plan.
2. Confirm TDD was actually followed, not just that tests exist: for each implementation task in the spec's Implementation Plan, its paired test/manual-verification task should appear before it and there should be no implementation task without one. Check the red/green timestamp note recorded against each pair (per specs/templates/spec-template.md and specs/templates/tasks-template.md) — the test task's completion time must precede the implementation task's. If a test was clearly written after its implementation, or no timestamp note was recorded, flag it as a process gap for the retrospective.
3. When a real test harness exists for the affected stack (e.g. an aspunit suite under tests/ for a RouteKit ASP Classic app, or an automated suite for a modern stack), actually run it using the command(s) recorded in .devfoundry/references/environments.md and read its real output — do not mark a checklist item verified from checklist prose alone. Paste or summarize the actual pass/fail output in the spec's Verification & Regression Plan.
4. When no test harness exists for the affected stack (legacy code with no tests/ app, or a stack environments.md explicitly records as having none), manually trace affected queries, forms, and reports per the spec's written manual-verification steps, and record exactly what was traced and observed — a documented manual trace is the accepted substitute only in this case, never a silent skip.
5. Check any known dependent features listed in .devfoundry/references/data-dictionary.md.
6. Record verification results in the spec's Verification & Regression Plan checklist, including which of step 3 or step 4 applied and why.