ce-impactlisted

Analyze the codebase impact of a proposed change described in plain text (e.g. an Azure DevOps work item pasted in) — affected components, blast radius, an approximate sizing hint, similar prior work, and the open questions a thin description leaves — as file:line-cited FINDINGS, never a verdict. Refuses loudly when the description is too thin to ground. Read-only on code; ephemeral; one-way (renders a paste-ready summary the human posts back themselves — no tracker API, no write-back). Triggers: estimate/assess the impact or blast radius of a proposed change or work item before building it. For a question about existing code use /ce-ask; to decompose a whole project use /ce-plan; to investigate a failure use /ce-debug.
relusion/vg-sdlc-claude-plugins · ★ 0 · Code & Development · score 75

Install: claude install-skill relusion/vg-sdlc-claude-plugins

# Impact **Invocation input:** Change to analyze: $ARGUMENTS Given a **proposed change described in plain text** — typically the title + description of an issue tracker work item (Azure DevOps, Jira, GitHub) pasted in — report what that change would **touch in this codebase**: affected components, the blast radius, an approximate sizing hint, similar prior work, and the questions the description leaves unanswerable. Output is **grounded, cited findings** that a human reads during refinement — never a go/no-go verdict. This tool is **read-only**, **plan-free**, and **repo-agnostic**. It is **not** part of the plan/spec/implement pipeline and consumes none of those artifacts. It is the *forward-looking* sibling of `/ce-ask` (which answers questions about code as it is) and reuses `/ce-ask`'s scoping discipline plus `/ce-plan`'s reachability / blast-radius vocabulary — it does not re-derive that reasoning. **The tool is tracker-agnostic by design.** It takes plain text and knows nothing about Azure DevOps or any API. The most common source is an ADO work item, but the skill never reads from or writes to a tracker — see *Cross-cutting rule — One-Way*. ## Runtime Inputs - **Change description (required):** the text of the proposed change. Usually a pasted work item (title + description, and acceptance criteria if present), but any natural-language change request works. Examples: - *"Add CSV export to the orders report"* - *"Bug: login is slow when a user has many se