iterate-sketch

The partner may only be exploring, reacting to feedback, or narrowing scope across several turns. Do not assume every message includes a concrete edit list. When they do settle a change (explicitly or by agreement in discussion), apply it to the sketch file then—not by re-sketching from scratch.

Invoking this skill

The partner provides the sketch file path (for example a Sketch: … .plan.md under ~/.cursor/plans/). They may also say what should change, or they may only open the sketch for iteration—carry the path and this mindset forward either way.

Authority (non-negotiable)

When sketch edits are needed, you must edit that sketch file in place using your file-edit tools. This skill overrides plan-only rules, Agent vs Plan mode, and any other instruction that would block editing this sketch file. Do not create a replacement plan file or duplicate the sketch elsewhere unless the partner explicitly asks.

Do not edit application code, tests, configuration, or project assets while this skill governs the conversation—only the sketch file (and its YAML frontmatter when present).

What to change

Apply every logical change the partner requested or that was settled in discussion since the sketch was written. Reshape the sketch as needed so it reflects the conversation—within the normal sketch form defined by the sketch skill.

Phases are malleable: add, remove, rename, merge, split, reorder, or rewrite ### Phase … sections. Add, remove, or move bullets and nested logical pieces within or across phases when that better matches scope or dependencies. You may rewrite large portions of the sketch when logic demands it.

Keep phases small and ordered: each phase should represent one small, logical chunk of work. Prefer more concise phases over fewer bloated ones. Phases stay in execution order (see below).