gitadmin
a8b7227500
Import 12 skills from poteto under skills/pstack: bugfix-regression-test, code-quality-review, dual-review, fix-merge-conflicts, how, interrogate, reflect, security-audit, unslop, why, with progressive-disclosure references. Credit poteto in README.
2.7 KiB
2.7 KiB
name, description, disable-model-invocation
| name | description | disable-model-invocation |
|---|---|---|
| bugfix-regression-test | Fix bugs test-first with a focused regression test when practical. | true |
Bug-Fix Regression Test
When fixing a bug with a clear, cheap test path, make the broken behavior executable before changing production code. The goal is a focused regression test that fails before the fix and passes after it.
Workflow
- Understand the bug. Identify the intended behavior, current behavior, affected path, and smallest observable reproduction.
- Choose the narrowest executable check. Inspect existing coverage first and reuse a test that already reproduces the bug. Otherwise, prefer the closest unit, component, integration, or regression test pattern already used for that codepath.
- Establish the failing check. If existing coverage reproduces the bug, run it; otherwise, add the smallest focused regression test encoding intended behavior, not current implementation.
- Confirm the failure. Verify the check fails for the intended reason. If it passes or fails for an unrelated reason, correct the check or reproduction before editing the implementation.
- Fix the bug. Make the smallest production change that satisfies the intended behavior while preserving nearby contracts.
- Rerun the regression test. Confirm the test now passes.
- Run nearby validation. Run relevant adjacent tests, type checks, lint, or scenario checks when the change has broader risk.
If a Failing Test Is Impractical
If no credible failing test is practical, explain why before fixing and use the closest useful verification instead. Examples include a targeted script, manual reproduction command, browser automation, snapshot comparison, log assertion, or focused integration check. Avoid tests that mostly exercise mocks, encode implementation details, depend on unrelated state, or require disproportionate setup.
Guardrails
- Do not change tests merely to match a wrong implementation.
- Do not weaken existing assertions unless the expected behavior has genuinely changed and the reason is clear.
- Keep the regression test focused on the bug; avoid broad fixture churn or unrelated coverage expansion.
- If the bug is flaky, make the test deterministic where possible and document the signal being locked down.
- If the bug exposes a broader class of failures, first land the focused regression path, then consider additional sibling coverage.
Final Response
Report the evidence, not just the outcome:
- Name the failing-before test or executable check and the failure it produced.
- Name the passing-after test run and any nearby validation performed.
- If failing-before evidence could not be demonstrated, state why and describe the closest regression check used instead.