V.A.R. Protocol#

Apply V.A.R. whenever the cost of overwriting the wrong thing is higher than the cost of being slightly more disciplined.

中文简介#

V.A.R. Protocol 是一个面向长期项目、重要资产和多阶段交付的协作规范。 它的核心原则是： 版本清晰（Versioning）、备份优先（Archiving）、遇错先回退（Rollback）。 适用于网站改版、代码重构、文档/Deck 迭代、Prompt/Config 升级、多 Agent 协作等场景，目标是在推进迭代速度的同时，避免 destructive overwrite、内容丢失与不可逆回归。

V.A.R. stands for:

• Versioning
• Archiving
• Rollback

What this skill is for#

Use this skill to turn risky editing work into a safer delivery flow. It is designed for code, content, design, and multi-agent execution where recoverability matters as much as speed.

Typical triggers:

• “Refactor this site without breaking the current version.”
• “Rewrite this proposal / deck, but keep a safe fallback.”
• “Migrate these prompts or configs and preserve rollback options.”
• “Have multiple agents work on the same long-lived asset safely.”
• “Package this release with a clear version, changelog, and rollback point.”

Core operating sequence#

Follow this order:

1. Stabilize the baseline — identify the current working version or last known good artifact.
2. Back up before structural change — create a restorable copy before large edits, refactors, migrations, or agent handoffs.
3. Use explicit versions — name outputs with clear semantic versions instead of vague labels like final, latest, or new2.
4. Change incrementally — prefer small, reversible modifications over full replacement.
5. Attach a changelog — state what changed, why, and what the rollback anchor is.
6. Rollback first when broken — if the new version regresses, restore the last stable version before attempting another merge.

When to apply strict mode#

Use the strictest form of V.A.R. when any of the following are true:

• The asset is long-lived or business-critical.
• Multiple agents or contributors are touching the same artifact.
• The task involves refactor, redesign, migration, or restructuring.
• The user may need to compare versions or recover prior work quickly.
• The output is a website, source tree, proposal, deck, prompt system, knowledge base, automation config, or brand asset set.

Minimum operating requirements#

Before making a high-impact change:

• Identify the artifact owner and the current stable version.
• Create a backup or duplicate that can be restored quickly.
• Decide the next semantic version.
• Preserve or document the rollback anchor.

During the change:

• Avoid destructive overwrite when a parallel version is feasible.
• Prefer additive or surgical edits over wholesale replacement.
• Keep filenames and folders readable and comparable.

At delivery:

• State the new version.
• Provide a concise change summary.
• Name the rollback anchor explicitly.
• Call out any known risks or incomplete areas.

Default naming guidance#

Prefer patterns like:

• [project]-[artifact]-v1.0.ext
• [project]-[artifact]-v1.1.ext
• [project]-[artifact]-v1.1.1.ext

Use version levels consistently:

• Major: architecture, structure, or strategy changed.
• Minor: meaningful feature/module expansion without core rewrite.
• Patch: small fixes, copy edits, image swaps, bug fixes.

Delivery contract#

When delivering work under V.A.R., include:

• Version
• Change summary
• Rollback anchor
• Known risks if any remain

Failure handling#

If the new version loses functionality, quality, or content:

1. Stop stacking more changes onto the broken version.
2. Restore or switch back to the last stable artifact.
3. Diagnose the failure from the stable baseline.
4. Re-apply only the needed changes in smaller slices.

Multi-agent rule#

The lead agent owns backup and rollback safety. Do not assume a sub-agent already created a safe restore point unless it is explicitly confirmed.

Read next#

For the full protocol text, delivery checklist, and example delivery block, read references/protocol.md.