impact-analysis
npx machina-cli add skill seokan-jeong/team-shinchan/impact-analysis --openclawImpact Analysis Skill
Analyze the cascade impact of modifying a component using the project ontology's dependency graph.
Usage
/team-shinchan:impact-analysis <target> [options]
Parameters
<target>— Entity name, ID, or file path to analyze--depth <N>— Traversal depth (default: 2, max: 5)--direction outgoing|incoming|both— Direction of analysis (default: both)
Process
1. Locate Target Entity
- Check if
.shinchan-docs/ontology/ontology.jsonexists - If not: "No ontology found. Run
/team-shinchan:ontology scanfirst." - Search for target by:
- Exact entity ID match
- Entity name substring match
- File path match (for Component entities)
- If multiple matches, list them and ask user to clarify
2. Cascade Analysis
Run node ${CLAUDE_PLUGIN_ROOT}/src/ontology-engine.js related <entityId> with the specified depth.
Analyze the result:
- Direct dependencies (depth 1): Components that directly depend on target
- Indirect dependencies (depth 2+): Cascade through transitive relations
- Test coverage: TESTED_BY relations for affected components
- Pattern compliance: FOLLOWS_PATTERN relations that may be affected
3. Risk Assessment
Calculate risk level based on:
- HIGH: 10+ affected entities OR target has 5+ incoming DEPENDS_ON
- MEDIUM: 5-9 affected entities OR target has 3-4 incoming DEPENDS_ON
- LOW: 1-4 affected entities OR target has 0-2 incoming DEPENDS_ON
4. Output Format
Display:
Impact Analysis: {target name}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Risk Level: {HIGH|MEDIUM|LOW}
Direct Dependencies ({N}):
- {component name} ({file_path}) — {relation type}
...
Indirect Dependencies ({N}):
- {component name} ({file_path}) — via {intermediate}
...
Test Coverage:
- {test suite name} ({file_path}) — covers {component}
...
Affected Modules:
- {module name} ({N} components affected)
...
Recommendations:
- {recommendation based on risk level}
Graceful Degradation
If ontology doesn't exist or target not found, suggest running scan first.
Source
git clone https://github.com/seokan-jeong/team-shinchan/blob/main/skills/impact-analysis/SKILL.mdView on GitHub Overview
This skill analyzes the cascade impact of modifying a component using the project ontology dependency graph. It locates the target, traverses dependencies to reveal direct and indirect effects, checks test coverage and pattern compliance, and then computes a risk level to produce a structured impact report.
How This Skill Works
1) Locate the target entity by inspecting .shinchan-docs/ontology/ontology.json; if missing, prompt to run /team-shinchan:ontology scan. 2) Run the cascade analysis using node ${CLAUDE_PLUGIN_ROOT}/src/ontology-engine.js related <entityId> with the chosen depth and direction. 3) Inspect results for direct dependencies (depth 1), indirect dependencies (depth 2+), test coverage (TESTED_BY), and pattern compliance (FOLLOWS_PATTERN). 4) Compute a risk level (HIGH|MEDIUM|LOW) based on the number of affected entities and incoming DEPENDS_ON relations, then output a formatted Impact Analysis report.
When to Use It
- Planning a component change and needing the full ripple effect across the ontology graph
- Pre-release risk assessment to decide if additional tests or rollback plans are needed
- Debugging failures caused by chained dependencies or missed test coverage
- Evaluating how a refactor may affect test suites and pattern conformance
- Auditing dependency patterns before introducing a new or updated component
Quick Start
- Step 1: Ensure ontology exists (or run /team-shinchan:ontology scan)
- Step 2: Run /team-shinchan:impact-analysis <target> [--depth N] [--direction outgoing|incoming|both]
- Step 3: Review the Impact Analysis output and proceed with risk-based actions
Best Practices
- Ensure the ontology exists (or run /team-shinchan:ontology scan) before analysis
- Precisely identify the target by entity ID, exact name, or file path
- Choose a sensible depth (default 2, max 5) and direction (outgoing, incoming, or both)
- Cross-check results with existing tests to verify coverage (TESTED_BY) and pattern adherence (FOLLOWS_PATTERN)
- Review the risk level and recommended actions before making changes
Example Use Cases
- Updating a core data model component triggers multiple downstream services and UI modules; impact analysis reveals 12 affected components and 5 incoming DEPENDS_ON
- Refactoring a shared utility used by both frontend and backend; analysis shows several indirect dependencies and gap in test coverage
- Modifying an authentication module cascades to authorization flows and utilities, highlighting required tests and pattern changes
- Changing a UI component that participates in a project-wide pattern; analysis surfaces components that may violate FOLLOWS_PATTERN
- Replacing a third-party library with an internal implementation; impact analysis maps affected modules and their test suites
