技能介绍

要解决什么问题

很多「带脚手架的开发技能」会把 .vibe/、scripts/ 或整套模板直接写进你的业务仓库，既污染目录，又容易和现有代码、Git 历史纠缠在一起。业务同学只想按阶段留下可审计的交付物（背景、计划、任务、测试、归档、进度索引），而不是在项目里再维护一套技能私有实现。

潮汐 VibeCoding CLI 面向「在用户项目里跑分阶段工作流、但不拷贝技能包私有资产」这一约束：用户目录里只出现约定的工作流输出与 codes/ 代码区，详细规程在技能包的 references/ 里按需加载。

工作方式与核心能力

工作流按目录分阶段落地，典型结构包括：

01_init/：用户画像、项目背景、需求输入模板、命令速查、上下文请求文件
02_plan/～06_catalog/：计划与澄清、任务拆解、测试记录、归档与验收、进度日志与索引
codes/：脚手架克隆或你已有的项目代码

命令是阶段作用域的：plan 只评估需求并在 02_plan/ 生成计划，不会顺带建任务、改代码或提交；init 只做类型选择与脚手架复制、Git 初始化与首次提交（若可用），不会自动装依赖、跑测试或起服务。组合命令如 plan-task、finish、flow 才有文档化的跨阶段语义。

初始化支持项目类型（如 web官网、3D平台、海洋平台、已有项目），配置来自 assets/projects/ 中的 repository_url；选「已有项目」时保留 codes/ 且不拉 starter。codex / workbuddy 是手动刷新上下文的命令，普通 init 不会自动生成 AGENTS.md 或 WorkBuddy 记忆。产物命名要求 ASCII、小写、kebab-case，中文只写在 Markdown 正文里。

适用边界与注意点

这是指令驱动的技能：执行拷贝、生成制品、Git 操作应直接遵循 SKILL.md 与 references，而不是依赖项目内的可执行自动化层。模板单一来源是技能包内的 assets/templates/，不要把 *-template.md 散落到用户各阶段目录。

需求不清时应先产出澄清制品并提问，而不是替用户拍板实现细节；业务侧优先用 01_init/requirement-input-template.md 描述工作。run / build / test 仅在用户明确要求后执行；一条需求走完时，在 Git 可用的情况下应有测试记录、归档、目录日志与按需求范围的提交，且不要覆盖或误提交无关改动。

截图预览

使用场景

选定 web官网或已有项目后执行 init，只在仓库生成 01_init～06_catalog 与 codes/，不把技能私有目录拷进项目。
业务用 01_init/requirement-input-template.md 或独立需求 Markdown 交稿，再单独跑 plan，仅在 02_plan/ 产出计划而不自动建任务或改代码。
需求表述不清时先生成澄清制品并集中追问，避免在 plan 阶段替用户拍板模块、接口与文件结构。
单条需求收尾时补齐 04_test、05_archive、06_catalog，并对当前需求相关路径做 Git 提交，不夹带无关改动。

适合人员

用 Markdown 描述业务目标、希望 agent 别在需求阶段追问路由/API 细节的产品或业务分析同学
要在同一 Git 仓库里留存计划、任务、测试与归档链路、方便审计单次需求闭环的技术负责人
按 assets/projects 配置从 repository_url 克隆 starter 到 codes/、对接 web官网/3D/海洋平台模板的全栈工程师
维护多条并行需求、要求 init 不自动装依赖跑服务、且 commit 严格按阶段与需求范围 staging 的开发者

潮汐 VibeCoding CLI