用途：当收到前沿 AI 编写的多步骤实现计划（通常含 3 个以上步骤及具体文件路径与代码模式），而由非前沿编码模型在 OpenCode 中执行时，用此技能约束执行纪律。不适用于单文件改动、1-2 步的简单计划、同一会话中自己写的计划，或用户优先追求速度的场景。
主要能力与工作流： 1）预检：用 git status --short 查看仓库是否干净，检查 package.json、AGENTS.md、README.md，识别可用验证命令并运行最便宜的基线检查（如 lint 或 typecheck）；若基线已失败，需明确记录命令、退出状态与错误摘要，不与本次改动混为一谈。检测到无关未提交改动、lockfile 被改或处于 rebase/冲突状态时应警告或停下询问。 2）解析与校验：通读整个计划并抽取有序步骤，逐项核对引用的文件是否存在、库是否在 package.json 中、仓库是否已有等价工具、验证命令是否可用、步骤依赖与破坏风险等级；对不成立的步骤在保留原意的前提下进行适配。 3）跟踪：优先使用 todowrite 创建进度清单，不可用时在回复中手动维护 markdown 清单。 4）实现：一次只实现一步，先读目标文件，遵循仓库现有约定，做最小连贯改动，不实现后续步骤，不做无关清理，未经批准不安装依赖。 5）分层验证：按改动类型选择最窄的有效验证（新文件用 lint/typecheck，逻辑改动用目标单测，API 改动用集成测试，配置改动用构建，数据库改动需用户批准）。禁止靠弱化断言、删测试、隐藏错误来让验证通过。 6）检查 diff：用 git diff --stat 和 git diff 确认只有预期文件变化、无无关格式化、无 lockfile 变动、未引入密钥或调试日志。 7）收尾：全部步骤完成后运行 lint + typecheck + build + tests，并报告已完成步骤、改动文件、验证结果、所做适配与遗留问题。
提交与推送：默认启用自动提交与推送。实现前识别当前分支，若在 main、master、production、release 等主线分支上，需根据计划新建工作分支；不向受保护主线直接推送。仅在逻辑单元完成、验证通过、diff 已检查且提交目的单一时才提交，使用 Conventional Commits 格式（如 feat(auth): add session validation helper）。已存在的用户未提交改动不得自动纳入代理提交。
限制与禁止：未经用户明确同意不得执行 rm -rf、git reset --hard、git clean -fd、git push --force；不得运行 npm/pnpm/yarn/bun install、npm audit fix；不得运行 prisma migrate、prisma db push、supabase db push、docker compose down -v；不得更改 .env、全局工具配置或运行部署命令；不得对全仓库做批量格式化或无审查的跨文件替换。重复失败时不要继续盲改，应重读完整报错、检查 diff、提出新假设，否则按“阻塞报告”格式说明验证命令、失败文件、根因假设、已尝试策略与下一步建议。