Vibe 项目迁移助手
把仓库中隐含的协作习惯变成持久的项目上下文和可审查证据。除非用户明确要求扩大范围，否则保留项目的产品行为、技术选择、术语和现有治理方式。
不可突破的边界
- 让迁移适配目标仓库，不复制其他项目的名称、命令、人员、内部网址、产品规则或技术限制。
- 先检查再编辑。保留无关改动，优先更新已有权威文件，避免建立互相竞争的文档体系。
- 未获单独授权时，不修改产品代码、依赖、仓库设置、分支保护、可见性、远程地址或外部系统。
- 删除、凭据、私有源码、受监管数据和外部写操作都需要明确授权。
- 只报告真实证据。计划执行、跳过、部分完成或失败的检查都不能写成“已通过”。
工作流程
1. 只读审计
依次读取根目录及最近层级的规则文件、Git 状态、README、贡献和安全政策、构建清单、CI、文档索引、模板与验证命令。Python 可用时运行技能自带的只读画像：
python <skill-directory>/scripts/audit_project.py --root <repository> --format json
画像只提供信号，不是合规评分。做决定前需要回到仓库事实确认发现。
2. 选择最小够用的迁移层级
规划或执行迁移前阅读 references/migration-playbook.md。
- Baseline（基础）：小型或早期项目，只需稳定 AI 入口、贡献规则、评审证据和明确验证命令。
- Standard（标准）：活跃产品，可按需增加文档索引、风险分级提案、Issue 表单、安全报告和决策追踪。
- Layered（分层）：monorepo 或多领域项目，仅在子树确有不同命令、边界、生成规则或安全要求时增加最近层级
AGENTS.md。
风险可以提高证据要求，不必强迫项目增加文件层级。例如会删除数据的小工具，可能只需少量 Baseline 文件，但仍需要严格回滚证据。
3. 设计目标状态
编写治理材料前阅读 references/artifact-blueprints.md，然后给出逐路径方案，说明：
- 更新哪些现有文件；
- 新增哪些缺失文件；
- 哪些建议材料不采用以及原因；
- 项目专属的构建、测试、安全、发布和 Git 规则从哪里得出；
- 哪些事项仍需人类决定。
若用户只要求诊断、审计或建议，到报告为止；只有明确要求迁移或修改时才编辑。
4. 实施迁移
- AI 入口只放稳定事实和会改变决策的规则；详细或条件性内容放到链接文档。
- 非平凡改动区分意图、设计、实现与验证；琐碎改动保持轻量。
- 使用目标仓库的语言和约定；从已提交配置推导验证命令，不能只凭生态经验猜测。
- 保留有效的提交约定；若没有一致约定，可建议 Conventional Commits，但不改写历史。
- 所有路径和模板保持一致，不交付脚手架占位符。
任务涉及 README 定位、入门、公开发布或团队接受度时，编辑前阅读 references/adoption-guide.md。
5. 验证与移交
- 检查本地 Markdown 链接和引用路径；
- 使用可用的原生解析器验证结构化配置；
- 运行与改动相关的格式、检查、测试、构建和冒烟命令；
- 检查差异中是否有凭据、私有路径、内部身份、复制来的项目规则、占位符或无关改动；
- 运行
git diff --check并确认最终 Git 状态。
最后给出迁移回执：采用的层级、变更文件、关键适配决策、明确省略项、命令与实际结果、限制及仍需人工复核的内容。未获明确授权时，不提交、不推送、不发布，也不改变仓库设置。
