Impact Analysis Skill

You analyze how a proposed change will affect an existing codebase using PROJECT.md context.

Arguments

Analysis Process

Step 1: Load Context

Read PROJECT.md and parse:

• <features> - Map of existing features
• <api-registry> - Map of API endpoints
• <schema-registry> - Map of database models

Step 2: Parse Change Description

Extract keywords and concepts from the description:

"Add dark mode toggle to settings modal that persists preference"

Keywords: dark mode, toggle, settings, modal, persist, preference
Components: SettingsModal, settings API, user preferences

Step 3: Match to Existing Context

Search PROJECT.md context for matches:

Feature matching:

<feature id="settings">
  <name>User Settings</name>
  <files>src/api/settings.py, src/components/SettingsModal.tsx</files>
</feature>

→ Match! "settings" appears in description

API matching:

<endpoint method="PUT" path="/api/settings">
  <request>{ settings: object }</request>
</endpoint>

→ Match! Settings API will likely be used

Schema matching:

<model name="User">
  <field name="settings" type="jsonb"/>
</model>

→ Match! User.settings will store preference

Step 4: Identify Affected Files

Based on matches, list files:

Files to Modify:

• Files from matched features
• Files that import matched components

Files to Create:

• New components for new functionality
• New hooks/utilities
• New test files

Use grep to find additional dependencies:

grep -r "import.*SettingsModal" {project_path}/src --include="*.tsx" -l
grep -r "/api/settings" {project_path}/src --include="*.ts" -l

Step 5: Assess Breaking Changes

For each affected area, check for:

API breaking changes:

• Does the change require new required fields?
• Does the change alter response shape?
• Does the change require authentication changes?

Schema breaking changes:

• Does the change require new columns?
• Does the change alter existing column types?
• Does the change require data migration?

Interface breaking changes:

• Does the change alter component props?
• Does the change alter function signatures?
• Does the change remove exports?

Step 6: Estimate Scope

Step 7: Assess Confidence

Step 8: Generate Output

Return structured impact analysis:

<impact-analysis>
  <affected-files>
    <file action="modify">src/components/SettingsModal.tsx</file>
    <file action="modify">src/api/settings.py</file>
    <file action="create">src/hooks/useTheme.ts</file>
    <file action="modify">src/styles/globals.css</file>
  </affected-files>

  <affected-features>
    <feature id="settings">Add theme toggle to Appearance section</feature>
  </affected-features>

  <affected-apis>
    <api path="/api/settings" change="Theme field added to settings object"/>
  </affected-apis>

  <affected-schemas>
    <schema model="User" change="No schema change - uses existing JSONB settings"/>
  </affected-schemas>

  <breaking-changes>none</breaking-changes>

  <new-dependencies>
    <dependency name="@radix-ui/react-switch" version="^1.0.0" purpose="Accessible toggle"/>
  </new-dependencies>

  <scope>small</scope>
  <confidence>high</confidence>

  <notes>
    Theme preference will be stored in existing User.settings JSONB field.
    No database migration required.
  </notes>
</impact-analysis>

Special Cases

Feature Removal (feature-remove)

Focus on:

• Files to delete completely
• Files that reference the removed feature (need cleanup)
• Database orphan data considerations
• API endpoint removal

Refactor

Focus on:

• All files affected by rename/restructure
• Import path updates needed
• Test file updates
• String references (logs, errors, docs)

Unknown Feature

If change doesn't match any existing feature:

• Mark confidence as low
• Note that full investigation may be needed
• Suggest running /crd-investigate --depth deep

Error Handling