Impact analysis agent
Identify the likely impact of a proposed change before implementation by mapping it to graph nodes, affected files, functions, APIs, and tests.From its SKILL.md
npx -y skills add Agile-V/agile_v_skills --skill impact-analysis-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.4 KB, as published. Nobody here has run it
Instructions
Purpose
Identify the likely impact of a proposed change before implementation. This skill maps the change request to graph nodes, identifies affected files, functions, APIs, and tests, and produces a reviewable impact map that gates the Build Agent's context.
Trigger conditions
Use this skill when:
- A change request targets an existing system.
- The change could affect multiple files or modules.
- Regression risk exists (the change touches shared code).
- The user asks "what will this impact?" or "what could break?"
- The Red Team needs a pre-change risk map.
- Gate 0 (
system-understanding-agent) has passed.
Inputs
- change_request.md required
- .agile-v/phases/00-understanding/system_overview.md required
- .agile-v/phases/00-understanding/normalized_graph.json optional but strongly preferred
- .understand-anything/diff-overlay.json optional
- existing requirements (if any) optional
Outputs
All outputs are written to canonical .agile-v/phases/01-impact/.
impact_map.md
affected_components.json
regression_test_candidates.md
change_risk_assessment.md
impact_confidence.md
Required behavior
Step 1: Map change request to graph nodes
- Read the change request.
- Identify key concepts: changed APIs, functions, modules, behaviors.
- Search the normalized graph for nodes whose
name,path, orsummarymatch. - Classify each matched node as directly or indirectly affected.
Step 2: Identify direct impact
Direct impact = nodes that must be modified, added, or removed to satisfy the change request.
For each directly affected node, record:
- Component ID
- File path
- Symbol name
- Reason for impact
- Confidence: High / Medium / Low
Step 3: Identify indirect impact
Indirect impact = nodes that import, call, extend, test, or document a directly affected node.
Walk the graph one or two hops from each directly affected node. Flag indirect nodes with lower confidence unless the relationship is explicit.
Step 4: Identify regression test candidates
For each affected node:
- Find test nodes connected by
testsorcoversedges. - Find test files that import or reference the affected file path.
- Mark each test with priority: High (directly tests affected behavior), Medium, Low.
Step 5: Generate risk assessment
For each risk identified:
- Assign Risk ID, description, severity (High/Medium/Low).
- Propose a mitigation.
- Specify a verification approach.
Step 6: Record confidence and assumptions
- State overall confidence: High/Medium/Low.
- List assumptions made during impact analysis.
- Flag low-confidence nodes explicitly.
Output template: impact_map.md
See integrations/understand-anything/examples/impact_analysis_example.md.
Output schema: affected_components.json
[
{
"component_id": "<node id>",
"path": "<file path>",
"symbol": "<function or class name, or null>",
"impact_type": "modify|add|remove|review|test-only|doc-only",
"reason": "<why this component is affected>",
"confidence": "high|medium|low"
}
]
Anti-patterns to avoid
- Do not include the entire graph in the impact map. Focus on the change.
- Do not generate implementation code.
- Do not mark files as affected just because they are large or important.
- Do not assign High confidence to indirect dependencies without a clear relationship.
- Do not skip the risk assessment step for
L3/L4changes.
Inherited obligations: apply agile-v-core halt, decision-log, and applicable typed-lineage rules; if AI materially influences these outputs at any risk level, create/update .agile-v/aibom/<task_id>/AI_RUN_MANIFEST.yaml per agile-v-aibom.
Gate 1 evidence contribution
The impact map informs Human Gate 1 but does not redefine it. Gate 1 reviews the persisted requirement revision plus independent findings; this supporting evidence must be reviewed where applicable:
- Impact map reviewed and accepted.
- Interface contract reviewed.
- Regression-test plan accepted.
Compatible tools
Claude Code, Cursor, Copilot, Codex, Gemini CLI, OpenCode, Cline.
What ships with it: 2 files
2.3 KB alongside SKILL.md
- metadata.json1.3 KB
- README.md1.0 KB
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
- Map changed files to graph nodes
- Read the change request
- Classify nodes as directly or indirectly affected
- Record component ID and file path for affected nodes
- Walk graph two hops from directly affected nodes
- Identify regression test candidates for affected nodes
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.