agentsclimarketplace

Impact analysis agent

Skill Agile-V/agile_v_skills/skills/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

Install
npx -y skills add Agile-V/agile_v_skills --skill impact-analysis-agent

Assembled 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

  1. Read the change request.
  2. Identify key concepts: changed APIs, functions, modules, behaviors.
  3. Search the normalized graph for nodes whose name, path, or summary match.
  4. 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 tests or covers edges.
  • 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/L4 changes.

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

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.

Keep looking

Skills are one crate of 615,528. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.