project-flow-ops

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"