File Change Planner
Produces a precise, auditable manifest of every file that must be created, modified, or deleted to implement a given change — including dependency chains, blast-radius analysis, and ordering constraints.
Guiding Principle
"A change you cannot enumerate is a change you cannot control."
Procedure
Step 1 — Scope the Change Request
- Parse the feature/fix/refactor description into atomic units of work.
- Identify the primary domain boundaries affected (modules, packages, layers).
- Classify the change type: additive, modificative, destructive, or mixed.
- Determine the target branch and baseline commit for diffing.
- Flag any ambiguities that require stakeholder clarification before proceeding.
Step 2 — Discover Affected Files
- Use
Grep and Glob to locate all files matching the affected symbols, imports, and configurations.
- Walk the dependency graph outward: direct dependents, transitive dependents, test files, config files.
- Identify collateral files: CI configs, documentation, migration scripts, environment files.
- Map each file to its owning team or module for review assignment.
- Tag files as CREATE / MODIFY / DELETE with confidence level.
Step 3 — Analyze Impact & Risk
- For each MODIFY file, describe the specific lines/sections that change and why.
- For each DELETE file, confirm no remaining consumers exist (dead code verification).
- For each CREATE file, specify the template or pattern it follows.
- Score blast radius: LOW (1-3 files), MEDIUM (4-10), HIGH (11+), CRITICAL (cross-service).
- Identify ordering constraints (e.g., migration before schema change before app code).
Step 4 — Produce the Change Manifest
- Output a structured table: File Path | Action | Reason | Risk | Order | Owner.
- Generate a Mermaid dependency graph showing change propagation.
- List prerequisite changes (other PRs, config deployments, data migrations).
- Append rollback notes for each file action.
- Tag every entry with evidence:
[CODIGO] for confirmed via code, [INFERENCIA] for deduced.
Quality Criteria
- Every file action is traceable to a requirement or dependency.
- Blast-radius score is explicitly stated and justified.
- Ordering constraints prevent broken intermediate states.
- Zero orphan references after DELETE actions are applied.
Anti-Patterns
- Listing files without explaining why each changes (lazy manifests).
- Ignoring test and config files in the change plan.
- Assuming a flat change order when dependencies exist.
- Mixing aspirational refactors into a scoped change plan.