Project Flow Cy

project-flow-cy

把任何项目（代码 / 调研 / 内容 / 方案）当 repo 管的一套 AI 多 Agent 协作流程。

核心是三句话：

- 上下文落进文件，不锁在对话里。
- Agent 之间靠 flow/ 和 docs/ 异步接力。
- 每轮收工写进展，下一棒从文件接上。

这个 skill 负责两件事：

1. 初始化 / 接入项目：先判断单体项目、单仓多子项目或多独立仓库，再铺好对应层级的 flow/、docs/、规则入口、收工自检 hook 和方法论副本。
2. 收工交接：在 flow/进展.md 顶部追加一条交接记录，并在对话中清晰展示同一组事实。

它不处理具体业务内容。业务方案、代码、调研、设计稿仍由对应项目和对应 Agent 完成；project-flow-cy 只负责把协作方式和交接结构立起来。

适用场景

当你需要：

- 给一个新项目搭 Claude Code / Codex 共用的协作骨架
- 把已有项目接入 flow/ + docs/ 文件化流程
- 管理同时包含前端、后端、落地页或多个服务的单仓项目
- 让多个 AI 会话、多个终端或多个模型之间能稳定接力
- 收工时生成一条下一棒能直接复制使用的 handoff
- 把方法论副本随项目保存，避免换会话后丢规则

就用这个 skill。

安装

把仓库 clone 到你的 skill 扫描目录。目录位置取决于客户端配置；常见做法：

如果你用的是统一的技能仓库，也可以把本仓库作为子目录放进去，例如：

安装或更新后，新开会话，确认 skill 列表里出现 project-flow-cy。

怎么用

初始化 / 接入项目

在目标项目目录里说：

或：

执行时会先读 references/初始化SOP.md。存在多个代码目录时，还会读 references/多子项目结构.md，先报告项目边界判断，再列出将创建 / 修改的文件，等你确认后动手。已有项目走非破坏合并：缺什么补什么，不覆盖用户已有内容。

初始化后的典型结构：

单仓多子项目

当前端、后端、落地页共同服务同一个总体项目，并共享仓库、目标和发布节奏时，它们属于一个项目边界。默认结构是：

根级 flow/ 统一管理总体目标、计划、任务、决策、问题和交接；根级 docs/ 统一管理产品、架构、跨模块契约和需要集中查找的模块说明。子项目目录主要保存源码、测试和构建配置，不重复创建 flow/ 或完整 docs/。

已有的子项目 README、工具生成文档或必须紧贴代码维护的说明不会被搬走，只会在根级 docs/README.md 建索引。若某个子项目有独立 Git 仓库、版本、发布或团队边界，才把它当成独立项目，建立自己的完整协作骨架。

开工时先说明需求理解

接入后,Agent 开始新任务、接手任务或目标明显变化时,会先读必要上下文,再用自己的话简短说明你希望达到什么结果、要解决什么问题,必要时补充这次的范围。例如：
我理解,你希望 Agent 先说明自己理解的目标和待解决的问题,让你能及时发现理解偏差,完成后也能核对结果是否回应了需求。我会把这一步放进开工约定,并让结尾回应原始目标。

普通补充、进度询问和连续小改动不会反复重述。需求清楚就按已有授权继续执行,不用每次等你确认;推测出的目的会明确标为推断,关键歧义才会提问。结尾通过原有交接字段回应需求,不重复整段开场。

收工交接

当你完成一棒，需要交给下一个 Agent / 会话：

或：

skill 会在 flow/进展.md 顶部追加一条记录，字段包括：

- 做了什么：本轮完成的具体改动。
- 为什么：本轮工作回应的用户目标与原始问题。
- 怎么理解：影响接手的假设或边界。
- 产出：真实文件路径或可点击链接。
- 问题与解决：执行中的障碍、处理结果及必要验证；无问题时简写“无新增问题”。
- 下一步：接手方第一个具体动作，或说明本项已完成。

回复默认像上面这样直接显示单层 Markdown…