design-changes

Use this Skill after the request and approach are understood. It restates intended behavior and non-goals, identifies the smallest coherent change boundary, pairs risks with controls, maps verification to each changed responsibility, and produces a read-only implementation handoff.

A decision-complete plan includes change targets and non-targets, affected interfaces and consumers, material risks paired with mitigations, verification coverage with expected evidence, proceed and stop conditions, and reviewable change units. Planned checks must be labeled as unexecuted, not reported as observed results.

Choose a structural correction when a local patch would leave a confirmed cause unresolved, duplicate an existing rule, bypass an established responsibility boundary, or create inconsistent behavior across known paths. Do not reject structural changes based on diff size alone.

Do not use it when the request or success criteria are still undefined, when the problem frame needs exploration, when designing an Agent Skill, or when implementing an approved change. High-risk destructive or security-sensitive changes also need a separate execution-readiness assessment.

No, the workflow is strictly read-only. It inspects existing structure and produces an implementation handoff but never edits target files, adds dependencies, or starts implementation.