Regression selection agent
Skill Agile-V/agile_v_skills/skills/regression-selection-agent
Select and prioritize regression tests based on the impact map and graph dependency relationships, flagging coverage gaps before the Red Team step.From its SKILL.md
npx -y skills add Agile-V/agile_v_skills --skill regression-selection-agentAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
What its file declares
Copied from the file, not written here
The file declares its own license as CC-BY-SA-4.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
4.1 KB, as published. Nobody here has run it
Instructions
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/phases/01-impact/impact_map.md required
- .agile-v/phases/01-impact/affected_components.json required
- test inventory (discovered from test/ directory or graph test nodes) required
- .agile-v/phases/00-understanding/normalized_graph.json optional but preferred
- previous test results (if available) optional
Outputs
All outputs are written to canonical .agile-v/phases/03-regression/.
required_regression_tests.md
selected_tests.json
regression_coverage_rationale.md
missing_regression_tests.md
Required behavior
Step 1: Discover existing tests
- Search the repository for test files (
.spec.ts,.test.ts,_test.py,test_*.py, etc.). - If a normalized graph is available, use test nodes from the graph.
- Build a test inventory:
test_path → linked_components(from imports and graph edges).
Step 2: Select tests linked to impacted components
For each test:
- Check whether it imports, references, or tests any affected component.
- Prioritize tests that directly test affected entry points.
- Assign priority: High (direct), Medium (indirect), Low (general).
Step 3: Identify gaps
For each affected component in affected_components.json:
- Check whether any selected test covers it.
- If no test is found, record a gap in
missing_regression_tests.md. - 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-0003 | 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-0001"],
"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).
Every requirement link must identify a baselined REQ-XXXX revision and baseline; selected tests use test_case -> verifies -> requirement lineage. Apply inherited agile-v-core halt/decision rules and agile-v-aibom manifest capture for materially AI-influenced output at any risk level.
Compatible tools
Claude Code, Cursor, Copilot, Codex, Gemini CLI, OpenCode, Cline.
What ships with it: 2 files
2.1 KB alongside SKILL.md
- metadata.json1.3 KB
- README.md820 B
Gives 0 of the 12 instructions most context ai engineering skills give
Counted across 1,328 of the 2,349 authors here whose files we hold, read 2026-09-06
- Dispatch a fresh subagent for each taskin 76 of 1328, across 59 files
- Perform spec compliance review before code quality reviewin 44 of 1328, across 34 files
- Dispatch a final code reviewer after all tasksin 38 of 1328, across 26 files
- Answer subagent questions before allowing implementationin 36 of 1328, across 26 files
- Use the least powerful model capable of the taskin 33 of 1328, across 26 files
- Create a TodoWrite list for all tasksin 32 of 1328, across 22 files
- Perform a task review after each implementationin 31 of 1328, across 24 files
- Extract all tasks and context from the planin 29 of 1328, across 20 files
- Provide full task text to subagentsin 28 of 1328, across 20 files
- Use git worktrees for isolated workspacesin 25 of 1328, across 20 files
- Specify the model explicitly when dispatching a subagentin 23 of 1328, across 18 files
- Execute all tasks from the plan without stoppingin 21 of 1328, across 16 files
Said here and by no other author read
- Search repository for existing test files
- Build test inventory linked to components
- Select tests linked to affected components
- Assign priority based on component impact
- Identify gaps in test coverage
- Record rationale for each selected test
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.