Regression selection agent

Skill: regression-selection-agent

Purpose

Select and prioritize regression tests based on the impact map and graph dependency relationships. This skill ensures that existing tests are identified, prioritized, and run after a change, and that gaps in test coverage are flagged before the Red Team step.

---

Trigger conditions

Use this skill when:

• Existing behavior must not break (regression risk).
• An impact map is available.
• The change affects shared modules, services, or APIs.
• The system has existing tests that need to be triaged.
• The Test Designer needs to know which existing tests to include.
• A release gate requires documented regression-test coverage.

---

Inputs

- .agile-v/impact/impact_map.md                 required
- .agile-v/impact/affected_components.json      required
- test inventory (discovered from test/ directory or graph test nodes)   required
- .agile-v/understanding/normalized_graph.json  optional but preferred
- previous test results (if available)          optional

---

Outputs

All outputs are written to .agile-v/regression/.

required_regression_tests.md
selected_tests.json
regression_coverage_rationale.md
missing_regression_tests.md

---

Required behavior

Step 1: Discover existing tests

1. Search the repository for test files (.spec.ts, .test.ts, _test.py, test_*.py, etc.).
2. If a normalized graph is available, use test nodes from the graph.
3. Build a test inventory: test_path → linked_components (from imports and graph edges).

Step 2: Select tests linked to impacted components

For each test:

1. Check whether it imports, references, or tests any affected component.
2. Prioritize tests that directly test affected entry points.
3. Assign priority: High (direct), Medium (indirect), Low (general).

Step 3: Identify gaps

For each affected component in affected_components.json:

1. Check whether any selected test covers it.
2. If no test is found, record a gap in missing_regression_tests.md.
3. Suggest a test name and structure for the missing coverage.

Step 4: Build rationale

For each selected test, record:

• Why it was selected.
• Which requirement or risk it covers.
• Which component it links to.

---

Output template: required_regression_tests.md

# Required Regression Tests

| Test | Linked Component | Linked Requirement | Risk Covered | Priority |
|---|---|---|---|---|
| tests/auth/session.test.ts | src/auth/session.ts | REQ-003 | Session regression | High |

## Missing Regression Tests

| Required behavior | Reason | Suggested test |
|---|---|---|
| Rate limit boundary (5th pass, 6th fail) | No existing test | auth.e2e-spec.ts::boundary_test |

---

Output schema: selected_tests.json

[
  {
    "test_path": "test/auth/auth.e2e-spec.ts",
    "test_name": "should login with valid credentials",
    "linked_component_ids": ["node-042"],
    "linked_requirement_ids": ["REQ-001"],
    "risk_covered": "Core login path not broken",
    "priority": "high",
    "selection_reason": "Directly tests the affected login endpoint."
  }
]

---

Anti-patterns to avoid

• Do not select all tests in the repository. Select only tests linked to affected components.
• Do not skip gap identification even if the test suite seems comprehensive.
• Do not assign High priority to tests with no clear link to affected components.
• Do not generate new test implementations in this skill (that is test-designer).

---

Compatible tools

Claude Code, Cursor, Copilot, Codex, Gemini CLI, OpenCode, Cline.