Change Impact Analysis
Map the ticket to the smallest evidence-backed set of affected areas.
Analysis
- Require an existing ticket; do not replace it with a prompt, diff, or plan.
- Read repository guidance, the ticket, and only relevant architecture context.
- Locate concrete entry points, then trace relevant callers, callees, shared
types, persisted data, configuration, generated code, and tests.
- Classify each impact as:
- direct: required for the requested behavior;
- indirect: connected to a direct impact;
- conditional: depends on an explicit design choice.
- Cite paths and symbols. Mark findings confirmed, inferred, or
unknown, and explain non-obvious dependency paths.
- Include compatibility, migrations, authorization, validation, caching,
asynchronous work, observability, deployment, or generated artifacts only
when relevant.
- Record assumptions, ticket conflicts, risks, and unresolved decisions. Do not
invent product behavior or prescribe unnecessary abstractions.
Output
Use the repository schema when available. Otherwise return:
impact:
summary: Expected blast radius and main risk
assumptions: []
ticketIssues: []
files:
- path: src/example.ts
scope: direct
confidence: confirmed
reason: Why it is affected
expectedChange: What changes
modules: []
interfaces: []
data: []
dependencies: []
verification: []
operations: []
risks: []
decisions: []
unknowns: []
Use the same scope, confidence, reason, and expectedChange fields
for other affected elements. Keep the mapping proportional and avoid unsupported
file inventories.
Return the mapping without writing for read-only requests. When asked to update
the ticket, replace only its top-level impact mapping, preserve all other
fields, and validate the YAML. Never create a separate impact file or modify
production code.
1---2name: change-impact-analysis3description: Analyze an existing YAML engineering ticket against its codebase and return an evidence-backed impact mapping. Use before planning or coding to identify affected code, interfaces, data, tests, risks, and open decisions. Do not create tickets, plans, or production changes.4---56# Change Impact Analysis78Map the ticket to the smallest evidence-backed set of affected areas.910## Analysis11121. Require an existing ticket; do not replace it with a prompt, diff, or plan.132. Read repository guidance, the ticket, and only relevant architecture context.143. Locate concrete entry points, then trace relevant callers, callees, shared15 types, persisted data, configuration, generated code, and tests.164. Classify each impact as:17 - **direct**: required for the requested behavior;18 - **indirect**: connected to a direct impact;19 - **conditional**: depends on an explicit design choice.205. Cite paths and symbols. Mark findings **confirmed**, **inferred**, or21 **unknown**, and explain non-obvious dependency paths.226. Include compatibility, migrations, authorization, validation, caching,23 asynchronous work, observability, deployment, or generated artifacts only24 when relevant.257. Record assumptions, ticket conflicts, risks, and unresolved decisions. Do not26 invent product behavior or prescribe unnecessary abstractions.2728## Output2930Use the repository schema when available. Otherwise return:3132```yaml33impact:34 summary: Expected blast radius and main risk35 assumptions: []36 ticketIssues: []37 files:38 - path: src/example.ts39 scope: direct40 confidence: confirmed41 reason: Why it is affected42 expectedChange: What changes43 modules: []44 interfaces: []45 data: []46 dependencies: []47 verification: []48 operations: []49 risks: []50 decisions: []51 unknowns: []52```5354Use the same `scope`, `confidence`, `reason`, and `expectedChange` fields55for other affected elements. Keep the mapping proportional and avoid unsupported56file inventories.5758Return the mapping without writing for read-only requests. When asked to update59the ticket, replace only its top-level `impact` mapping, preserve all other60fields, and validate the YAML. Never create a separate impact file or modify61production code.
Lnscc