Rewrite Beside the Original

When I really want the best version of something, I rewrite it. I do not edit the existing version in place. I make a new version beside the old one and rewrite it there.

That sounds like a small file-management preference, but it changes the psychology of revision. If the original is still there, I can suspend disbelief about the structural limits it has already imposed. I do not have to keep protecting the old arrangement while trying to invent a better one. I can let the new version become strange, ambitious, or even temporarily worse, because the thing I started with has not been destroyed.

Keep the source; free the structure

The simplest version is a split screen. When I rewrite articles, I have the old article on the left and the new article on the right. The old one remains available as a source of details, turns of phrase, examples, and arguments, but it no longer dictates the shape of the rewrite.

             keep visible                    rewrite freely
        ┌────────────────────┐           ┌────────────────────┐
        │      ORIGINAL      │           │    NEW VERSION     │
        │                    │           │                    │
        │ source, details,   │ compare   │ free structure and  │
        │ phrases, examples, │ ◀──────▶  │ a new shape         │
        │ and arguments      │           │                    │
        └────────────────────┘           └────────────────────┘

When several skills become one

I use the same pattern when recomposing several agent skills into one skill with supporting references. I create the new unified skill and its references first, while all of the older skills remain in the working directory. That gives me a complete set of source material to compare against while I decide what belongs in the new shape.

old skill A ─┐
old skill B ─┼──▶ unified skill + references ───▶ audit ───▶ delete old skills
old skill C ─┘

Once the new skill exists, I can ask an agent to audit the older skills still sitting beside it: has every important instruction been accounted for, either in the unified skill or in one of its references? Only after that check do I delete the older skills. The old files are not competing implementations at that point. They are a checklist for completeness.

Why the old version stays until the end

There are two kinds of safety here. The first is practical: the original remains available for comparison, so omissions are easier to catch. The second is creative: because the original is safe, I do not have to make every local edit defensible while I am still discovering the new structure. A whole rewrite lets me stop negotiating with the old form.

 preserve       duplicate        rewrite        compare        replace
    │               │                │              │              │
    ▼               ▼                ▼              ▼              ▼
  original  ───▶  new copy  ───▶  free work  ───▶  check  ───▶  delete old
                                                                rename new

The sequence is simple: preserve the original, duplicate it into a new working version, rewrite without protecting the old structure, compare the finished version against its source, and only then remove the old copy and restore the intended name. The deletion comes last, after the replacement has proved that it can stand on its own.