Stability Comes from a Reusable Brief

Do not re-explain the same kind of job every time. Write the five things as a skeleton and swap only the source material.

The same weekly update, the same kind of change, the same sort of cleanup — if you describe it from scratch every time, you get three different versions of “close enough.” Instability is usually not the model twitching. You handed over a different job each time.

After reading, you should be able to answer:

• What gets pinned in the skeleton, and what gets swapped as source material?
• Why does a longer prompt fail to stabilize the work?
• When a product calls the method a skill or a project file, which layer should you keep?

Pin the handoff, swap the material

The skeleton pins the four parts of the five things that should not move: action and result, format, bounds, acceptance. The object changes every time: this week's notes, this branch, this batch of files. Grok Bot treats “show it once, replay it” as a product ability. Codex writes standing agreements into project instructions so every run can read them. Different words, same judgment: the next run has to be able to read the handoff.xai-bot codex-agents-md

Length does not stop drift

Pasting every reminder from last time looks safer and is more brittle: the point is diluted, stale sentences stay, and acceptance is still unwritten. Project rules fail the same way — an encyclopedia crowds out the task. The project contract already says a map is not a dump of every sentence. Same rule on a product: keep the skeleton short, name the bad pattern and the safe path, and let this run's object fill the rest.

Keep the layer that can run again

A product may store the method as a skill, a routine, or a project file. What you want is the layer that can run again: swap the object, and the five things, the stops, and the check are still there. Transcripts can be drafts. They are not the asset. Write red lines into the skeleton next.