impact-analysis

You are analyzing the impact of changing: $target (a symbol, module, or API plus the intended change). If the target or the intended change is unclear, ask the user with the AskUserQuestion tool before starting.

The core rule of this skill: map usages with the index tools, not with grep.

1. Ensure the index is ready

1. Call mcp__code-indexing-mcp__project_status for the target project. If the project is unknown, call mcp__code-indexing-mcp__list_projects and, if needed, mcp__code-indexing-mcp__init_project.
2. If the index is missing or stale relative to the files the change touches, call mcp__code-indexing-mcp__index_project first. Tell the user if indexing will take a moment.

2. Resolve the target

• mcp__code-indexing-mcp__find_symbol with an exact match on the target name to locate every definition. If several unrelated symbols match, ask the user which one is meant — do not guess.
• mcp__code-indexing-mcp__get_chunk — read the definition itself so the analysis is grounded in what the symbol actually does and exposes.

3. Map direct usages and refactor impact

• mcp__code-indexing-mcp__find_references and mcp__code-indexing-mcp__analyze_refactor only understand C#, Go, Java, JavaScript, Python, Rust, TSX, and TypeScript declarations; selecting a declaration in any other language returns UNSUPPORTED_LANGUAGE rather than an empty (and misleadingly clean) result. If the target lives in another language, say so and fall back to search_code/grep for that part of the analysis.
• mcp__code-indexing-mcp__find_references — pass the selected declaration's chunk_id, or its project/path/qualified-symbol tuple, to retrieve structural uses. Treat exact as binding evidence, likely as a required review, and unresolved plus limitations as blind spots; do not promote them to exact yourself.
• mcp__code-indexing-mcp__analyze_refactor — for a rename or signature proposal, use its discriminated operation input before planning edits. must_change is deterministic, likely_change and review need human inspection, and evidence can show aliases that bind the target but need no spelling edit (or, for a signature change, compatible call sites).
• mcp__code-indexing-mcp__emit_refactor_patch — after reviewing an analyze_refactor result, call it with the same selector and rename operation to turn the deterministic must_change subset into a byte-exact unified diff the user can apply with git apply. It never edits source files: likely_change/review findings and stale or unverifiable files come back in unapplied and conflicted instead of the patch, so keep them on the review checklist. Signature changes return UNSUPPORTED_OPERATION.
• Read completeness.state before you characterise the blast radius. Only complete means every indexed file was analyzed; complete_with_dynamic_limitations means everything was analyzed but some findings rest on conservative, non-structural evidence; incomplete means whole files were not analyzed at all. The named limitations (other languages, parse failures, stale files) name the gap in either non-complete case. Report that gap to the user instead of presenting the finding list as exhaustive.
• If you apply the edits, use each finding's edit_start_byte/edit_end_byte, which cover just the identifier. The wider start_byte/end_byte span the whole reference, so replacing that range turns auth.authorize(u) into permit(u) and drops the alias from import authorize as check. Null edit offsets mean edit that site by hand.
• For each distinct file in the results, mcp__code-indexing-mcp__file_outline to place the usage in context, and mcp__code-indexing-mcp__get_chunk where the exact call matters (signature changes, argument reordering).