| name | project-flow-ops |
| description | 通过分流 issue 和 pull request、关联活跃工作，并保持 GitHub 面向公众而 Linear 作为内部执行层来运营 GitHub 和 Linear 之间的执行流。当用户想要待办事项控制、PR 分流或 GitHub 到 Linear 协调时使用。 |
| origin | ECC |
项目流运维
此技能将断开的 GitHub issue、PR 和 Linear 任务转化为一个执行流。
当问题是协调而非编码时使用它。
何时使用
- 分流开放的 PR 或 issue 待办列表
- 决定什么属于 Linear 与什么应该保持仅 GitHub
- 将活跃的 GitHub 工作关联到内部执行通道
- 将 PR 分类为合并、移植/重建、关闭或搁置
- 审查评论、CI 失败或过时 issue 是否阻塞执行
运营模型
- GitHub 是公开和社区的真相
- Linear 是活跃计划工作的内部执行真相
- 不是每个 GitHub issue 都需要 Linear issue
- 仅在工作是以下情况时创建或更新 Linear：
- 活跃的
- 已委派的
- 已计划的
- 跨功能的
- 足够重要以至于需要内部跟踪
核心工作流
1. 先读取公共面
收集：
- GitHub issue 或 PR 状态
- 作者和分支状态
- 审查评论
- CI 状态
- 关联的 issue
2. 分类工作
每个项目最终应该处于以下状态之一：
| 状态 | 含义 |
|---|
| 合并 | 自包含的、符合策略的、就绪的 |
| 移植/重建 | 有用的想法，但应手动在 ECC 内重新落地 |
| 关闭 | 方向错误、过时、不安全或重复的 |
| 搁置 | 可能有用，但当前未计划 |
3. 决定是否需要 Linear
仅在以下情况下创建或更新 Linear：
- 执行是积极计划的
- 涉及多个仓库或工作流
- 工作需要内部所有权或排序
- issue 是更大计划通道的一部分
不要机械地镜像所有内容。
4. 保持两个系统一致
当工作活跃时：
- GitHub issue/PR 应该公开说明正在发生什么
- Linear 应该内部跟踪负责人、优先级和执行通道
当工作发布或被拒绝时：
- 将公开解决方案发布回 GitHub
- 相应地标记 Linear 任务
审查规则
- 永远不要仅从标题、摘要或信任合并；使用完整的 diff
- 来自外部来源的功能在有价值但不自包含时应在 ECC 内重建
- CI 红色意味着分类并修复或阻塞；不要假装它已准备好合并
- 如果真正的阻塞因素是产品方向，直接说出来，而不是隐藏在工具后面
输出格式
返回：
公开状态
- issue / PR 状态
- CI / 审查状态
分类
- 合并 / 移植-重建 / 关闭 / 搁置
- 一段话的理由
LINEAR 操作
- 创建 / 更新 / 不需要 Linear 项目
- 项目 / 通道（如适用）
下一个操作者行动
- 确切的下一步动作
好的用例
- "审计开放的 PR 待办列表并告诉我要合并什么与重建什么"
- "将 GitHub issue 映射到我们的 ECC 1.x 和 ECC 2.0 计划通道"
- "检查这是否需要 Linear issue 还是应该保持仅 GitHub"
