ripple_skill

Overview

This skill performs pre-change impact analysis to map consequences before any code is written. It evaluates both vertical impact (dependencies and affected files) and horizontal consistency (patterns, naming, conventions) to produce an evidence-backed risk score and a clear go/conditional-go/no-go recommendation. The output is an actionable report that highlights affected files, breaking-change risks, pattern violations, and suggested mitigations.

How this skill works

Given a single proposed change, the skill first identifies scope and traces dependencies to at least two transitive levels, producing a dependency map. It then runs pattern compliance checks across naming, file structure, API and type patterns to detect horizontal deviations. Finally it computes a weighted risk score (scope, breaking potential, pattern deviation, test coverage, reversibility), ranks issues by severity, and issues concrete recommendations and test coverage needs.

When to use it

• Before implementing a change that may affect multiple modules or services
• When assessing whether a proposed API or interface modification is safe
• To verify that a planned change follows existing naming and architectural patterns
• When deciding go/no-go for a high-impact refactor or feature
• Prior to creating a large PR to estimate scope and test needs

Best practices

• Provide a precise change description and a list of immediate files/modules touched
• Include dependency manifests or architecture notes so vertical tracing is accurate
• Run the analysis early—before design or coding—to avoid wasted work
• Treat high-risk findings as blockers and require mitigations or tests before merge
• Use the dependency visualization (ASCII/Mermaid) when sharing with stakeholders

Example use cases

• A feature request modifies a shared library export—identify all consumers and breaking risk
• A refactor proposal that renames a core type—check naming consistency and transitive impacts
• API version bump—estimate scope, affected tests, and reversibility steps
• Proposal to move code between packages—map direct and transitive dependents and suggest PR split
• Pre-PR assessment to decide required test additions and whether to defer change