vibe-codinglisted

# Outcome 把已确认、可复制的产品需求包转化为架构清晰、实现完整、测试充分、可独立回滚且证据可复核的软件项目；或在用户明确选择时，以现有项目为基线完成续建、架构升级或技术栈迁移。 ## Routing 根据用户的自然语言意图选择以下一条路线，不根据“目录里恰好存在旧代码”擅自决定： 1. 新项目，只按需求实现：只使用已确认需求包设计新项目，不读取旧项目实现。 2. 新项目，参考旧项目的指定部分：需求包仍是产品行为权威输入；只读 Agent 仅检查用户授权的旧项目内容，提取行为、输入、输出和证据，不复制旧架构或整段代码。 3. 现有项目，按需求续建：以当前项目事实和已确认需求包共同确定差距，在现有工程上实现。 4. 现有项目，架构或技术栈迁移：以旧项目完整基线、用户确认的迁移目标和公开契约为依据制定迁移方案。 用户已经明确“新建”“续建”“参考哪些内容”“升级架构”或“迁移技术栈”时直接路由。只有描述确实可对应多条路线且会改变结果时，才询问一个路线问题并给出推荐。 - 路线 1–3 必须使用通过严格校验的完整需求包，或范围、外部依赖和验收条件都已明确且已确认的正式阶段包；`.build-goals/build-prd/` 过程检查点不能实施。 - 需求包缺失、未确认、哈希漂移或行为样例不完整时，转交 `build-prd`；不能用旧代码或零散描述替代。 - 普通代码修改、单点 Bug、单个文档或没有完整项目交付目标的任务不进入本 Skill。 ## Steps 开始后先完整读取 `rules/workflow-state-and-permissions.md`。该文件是所有写入、Git 操作和确认门禁的唯一权限表；其他 workflow 不得扩大其授权。 1. 建立只读基线、选择路线并比较需求快照 - 完整读取 `workflows/§01-baseline-and-routing.md`。 - 保护当前 HEAD、未提交修改、已有 worktrees 和用户新增文件，不执行破坏性清理或历史改写。 - 目标不是 Git 仓库时暂停并询问是否初始化 Git；未得到同意不得初始化，也不得继续进入依赖 Git/worktree/commit 的实施阶段。 - 路线 1–3 先严格校验来源需求包；来源不在目标项目时，使用 `scripts/import_requirements.py` 只读比较差异。第一次架构确认前不得使用 `--write`。 - 已有快照不会自动更新。发现来源版本变化时先报告受影响功能域、功能和文件；替换仍需明确确认。 2. 调研并确认架构方案 - 路线 1–3 完整读取 `workflows/§02-requirements-architecture.md`；路线 4 读取 `workflows/§03-migration-audit.md`。 - 路线 2 只读 Agent 只能访问用户授权范围，并只返回行为、输入、输出、公开契约和证据摘要；无 Agent 能力时由主 Agent 串行执行同样限制并明确降级。 - 调研当前官方规范、稳定工具链、活跃开源项目、安全和测试策略，提出至少两个可行方案、权衡与推荐。 - 先在对话中提交全局架构方案。用户第一次确认前，目标项目保持只读：不导入需求快照、不写架构文档、不修改代码、不执行 Git 写操作。 3. 固定需求快照、写入架构文档并确认整体实施路线 - 完整读取 `workflows/§04-pla