Iron rule: Do not only provide "which files to change"; also explain why to change them, the order, and the risk boundaries.
Workflow
- Step 1: Build a model of the current state ⚠️ REQUIRED
- 1.1 First call context-analyzer to confirm the existing modules, dependencies, and constraints.
- 1.2 Identify whether there is already a reusable implementation, to avoid reinventing the wheel.
- Step 2: Design the change plan ⚠️ REQUIRED
- 2.1 Break the requirements into module responsibilities, data flow, and interface boundaries.
- 2.2 Output the files to be added, modified, and deleted, along with the reasons.
- Step 3: Risk anticipation
- 3.1 Mark authentication, security, migration, compatibility, and rollback risks.
- 3.2 Identify which steps can be parallelized and which must be serial.
- Step 4: Hand off for implementation
- 4.1 Provide a minimal executable plan, not an abstract big picture.
- 4.2 Explain which professional skill is suitable for continuing the execution.
Anti-patterns
- Outputting abstract architecture vocabulary without giving file-level locations.
- Not explaining why a module should be newly created or an existing module should be refactored.
- Not anticipating compatibility and migration costs.
Project-specific prompts
- The plan must clearly specify the correspondence among composables, the service layer, API routes, data models, and test files.
- When designing interfaces, explain both the REST or invocation contract and the input validation and error semantics.
- When entity relationships or database reads/writes are involved, migration, permissions, and test impact must be considered at the same time.
Pre-delivery checklist
- The plan includes file mapping, responsibility breakdown, and execution order.
- Key risks and constraints have been explained.
- Reuse points and the basis for avoiding duplicate implementation have been pointed out.
- The plan is sufficient to hand off to an implementation skill for continued execution.