Prototype iteration protocol
Vibe coding 迭代已有原型/demo 时的协作协议。适用于本地可编辑、可重复运行或预览的 demo （网页、原生 App、脚本等），不限操作系统（macOS / Windows / 鸿蒙等）。 Use when: 用户要在已有 demo 上修改——如「改一下 X」「改一下 X 和 Y」「调整某交互」「把某处改成…」； 或说「只改」「别动其他的」「存一版」「做一版新的」「回到某版」；或 demo 越改越乱、改一处坏别处。 不用于：从零新建项目、与当前 demo 无关的问答。 Triggers: 改一下、改下、调整、改成、修改、再改、迭代、存一版、做一版新的、回到某版、 只改、别动、 change, tweak, adjust, modify, iterate, save version, new version, rollbackFrom its SKILL.md
npx -y skills add lhw0414/prototype-iteration-protocolAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
8.0 KB, ~2.6k tokens by cl100k_base, as published. Nobody here has run it
Prototype Iteration Protocol
铁律（默认生效，不用用户重复）
- 用户点名的都算本轮任务，没点名的不动。 不要要求用户列出「禁止修改」清单。
- 禁止偷偷联动。 若你认为必须改用户没点名的部分才能完成任务，先停手，用大白话说明原因和影响，等用户同意后再动。
- 禁止擅自加需求。 只做用户本轮明确说到的改动；不要顺便优化、重构、统一风格，不要自己加第 N+1 项。
Demo 形态（改前自动判断，不要问用户用哪种）
| 形态 | 识别 | 本 Skill 怎么用 |
|---|---|---|
| 本地代码工程 | 有多个源码文件、或常见工程结构 | 铁律 + 存档 + 汇报，完整流程 |
| 单文件 demo | 主要就一个可运行文件（如单个 html） | 铁律 + 复制该文件存档 + 汇报 |
| 设计稿 / 不能运行 | Figma、Sketch 等，无本地可执行入口 | 铁律 + 汇报；存档用另存副本 / 复制文件，不要求 Git |
| 纯云端工具 | 无本地工程目录，只在网页里编辑 | 铁律 + 汇报；说明版本靠平台历史，Agent 只管对话内边界 |
运行与预览
不假设具体系统、IDE 或设备。改完后用该项目已有的方式验证（浏览器打开、本地 dev 命令、IDE 运行到模拟器或真机等）。优先读项目 README 或脚本说明；Skill 不指定必须用哪一种。
开工前
- 用户说得够清楚 → 先存档，再改，不问 checklist。
- 用户一条消息里提多点（如「1. … 2. …」）→ 都属于本轮，一并完成；仍然不动用户没提到的部分。
- 只有实在无法判断改哪里时，才问 1 个问题（不要连问多个）。
- 存档成功后用人话告知：「已存档为 v0.xx（方式：Git / 复制到 xxx）」，再动手改。
够清楚的例子：
- 「只改某个控件的取值范围」→ 存档 → 直接改。
- 「1. 改某处上限；2. 保存时加确认提示」→ 存档 → 两点都做，其他不动。
改的过程中
- 改动范围尽量小（少文件、少行）。
- 不要为了「改好用户点名的某项」去动用户没点名的部分；真有关联，回到铁律第 2 条先问。
- 优先最小 diff；不要默认 refactor。
改完后（必须这样汇报）
用下面格式，简短：
【改了什么】
（一两句大白话；若用户本轮提了多点，逐条简要列出）
其他没改。
【备查】
（可选：涉及文件 + 改动摘要，一行即可）
汇报示例：单点
用户：「只改某处交互的上限」
【改了什么】
（用用户能听懂的话描述可见行为变化。）
其他没改。
【备查】
某视图文件 — 相关参数上限调整
汇报示例：用户一次提两点
用户：「1. 改某处上限；2. 保存时加确认提示」
【改了什么】
1. （第 1 点的人话描述）
2. （第 2 点的人话描述）
其他没改。
【备查】
（涉及文件与改动摘要，一行）
若用户同意联动改了未点名的部分
【改了什么】
1. （A 的人话描述）
2. （B 的人话描述，注明是用户同意后加的）
其他没改。
【备查】
（涉及文件与改动摘要，一行）
版本管理（自动留档，方便对比和回退）
每次动手改 demo 之前必须先存档。改前、改后都要让人能回退。
存档方式（按顺序尝试，不要要求用户会 Git）
方式 A — 项目是 Git 仓库：
- 改之前：commit（若有未提交改动）+ 打 tag，如
v0.09 - 改之后：commit + 打 tag，如
v0.10 - 回退：
git checkout <tag>
方式 B — 无 Git 的多文件项目：
- 改之前：复制整个项目目录为
项目名-v0.09（与用户口头版本号一致） - 改之后：当前工作区即新版本；需要留档时再复制
项目名-v0.10 - 回退：用备份目录覆盖，或切换到备份目录
方式 C — 单文件 demo：
- 改之前：复制该文件为
文件名-v0.09.ext - 改之后：同理
文件名-v0.10.ext - 回退：用备份文件覆盖
方式 D — 设计稿：
- 改之前：另存副本，文件名带版本号
- 回退：打开对应副本
存档失败（无权限、路径不可写、Git 报错等）：
- 停止修改
- 告诉用户请先手动备份（复制文件夹、另存文件或提交 Git）
- 用户确认备份完成后再继续
不要假设操作系统；路径使用项目相对路径，不写死平台特有目录。
常规：只改用户点名的内容
- 存档 → 告知「已存档为 v0.09」
- 完成本轮改动 → 存档为
v0.10 - 告诉用户：上一版、这一版叫什么；用本地习惯的方式重新运行/预览；要回退说「回到 v0.09」
需要联动未点名部分，且用户同意
（用户只点了 A，但必须动 B；与用户一次提 A+B 两点不同。用户可说「不用留两版对比」，则只留 checkpoint + 最终版。）
须留 三个可切换版本：
| 版本 | 内容 |
|---|---|
v0.09 | 改之前的满意版 |
v0.10-a-only | 只做了用户点名的 A |
v0.10-a+b | A + 用户同意联动的 B |
- 有 Git：三个 tag；先 a-only，再在之上加 B 得 a+b
- 无 Git：三个文件夹或文件副本，命名带同样版本号
汇报：
【版本】
- v0.09：改之前
- v0.10-a-only：（A 的人话描述）
- v0.10-a+b：（B 的人话描述）
【怎么对比】
说「切到 a-only」或「切到 a+b」，再重新运行/预览 demo。
用户说「回到某版」
- Git → checkout 对应 tag
- 无 Git → 恢复对应备份目录或文件
- 设计稿 → 打开对应副本
- 用人话确认已回退，并提醒重新运行/预览
命名与首轮
- 格式：
v0.10、v0.10-a-only、v0.10-a+b；有 Git 时 tag 与 commit message 写人话 - 用户没提版本号时，自行递增末位（v0.09 → v0.10）
- 第一次迭代、尚无版本：当前状态记为
v0.01，再往后递增 - 用户说「先存」「做一版新的」→ 必须执行存档，不要只记在聊天里
存档失败时
- 不继续改任何文件
- 说明失败原因（一句大白话）
- 给出最简手动备份步骤（复制文件夹 / 另存文件 / git commit）
- 等用户确认后再继续
不要做的事
- 不要列一长串「未改动项」——只说「其他没改」即可。
- 不要改完才坦白动了多处；动了就要在【改了什么】里写清楚（人话优先）。
- 不要把技术术语、文件名、变量名当主输出；细节只放【备查】。
- 不要在存档失败时强行改 demo。
- 不要假设同事一定用 Git、一定用某一种 IDE 或操作系统。
用户觉得 Agent 越界时
用户可说「按迭代协议重来」：先回退到最近存档，再按用户点名的范围重做。
What ships with it: 2 files
1.2 KB alongside SKILL.md