---

name: project-flow-ops description: 跨 GitHub 和 Linear 操作执行流程，通过分类问题和拉取请求、关联活跃工作，保持 GitHub 面向公众而 Linear 作为内部执行层。当用户需要待办事项控制、PR 分类或 GitHub 到 Linear 的协调时使用。 origin: ECC

项目流程运维

此技能将分散的 GitHub 问题、PR 和 Linear 任务整合为一个执行流程。

当问题是协调而非编码时使用它。

何时使用

• 分类开放的 PR 或问题积压
• 决定哪些属于 Linear，哪些应仅保留在 GitHub
• 将活跃的 GitHub 工作关联到内部执行通道
• 将 PR 分类为合并、移植/重建、关闭或暂存
• 审计评审评论、CI 失败或过期问题是否阻塞执行

运营模型

• GitHub 是公共和社区的事实来源
• Linear 是活跃计划工作的内部执行事实来源
• 并非每个 GitHub 问题都需要 Linear 问题
• 仅在以下情况创建或更新 Linear：
  • 活跃中
  • 已委派
  • 已排期
  • 跨职能
  • 重要到需要内部跟踪

核心工作流

1. 首先读取公共表面

收集：

• GitHub 问题或 PR 状态
• 作者和分支状态
• 评审评论
• CI 状态
• 关联的问题

2. 分类工作

每个项目应归入以下状态之一：

| 状态 | 含义 | |-------|---------| | 合并 | 自包含、符合策略、就绪 | | 移植/重建 | 有用的想法，但应在 ECC 内部手动重新落地 | | 关闭 | 方向错误、过期、不安全或重复 | | 暂存 | 可能有用，但当前未排期 |

3. 决定是否需要 Linear

仅在以下情况创建或更新 Linear：

• 执行已积极规划
• 涉及多个仓库或工作流
• 工作需要内部所有权或排序
• 问题是更大程序通道的一部分

不要机械地镜像所有内容。

4. 保持两个系统一致

当工作活跃时：

• GitHub 问题/PR 应公开说明正在发生什么
• Linear 应在内部跟踪所有者、优先级和执行通道

当工作交付或被拒绝时：

• 将公开决议发布回 GitHub
• 相应标记 Linear 任务

评审规则

• 永远不要仅凭标题、摘要或信任来合并；使用完整的差异
• 外部来源的功能在有价值但不自包含时应在 ECC 内部重建
• CI 红色意味着分类并修复或阻塞；不要假装它已准备好合并
• 如果真正的阻塞是产品方向，直接说明而不是隐藏在工具背后

输出格式

返回：

PUBLIC STATUS
- issue / PR state
- CI / review state

CLASSIFICATION
- merge / port-rebuild / close / park
- one-paragraph rationale

LINEAR ACTION
- create / update / no Linear item needed
- project / lane if applicable

NEXT OPERATOR ACTION
- exact next move

良好的使用案例

• "审计开放的 PR 积压，告诉我哪些该合并，哪些该重建"
• "将 GitHub 问题映射到我们的 ECC 1.x 和 ECC 2.0 程序通道"
• "检查这是否需要 Linear 问题，还是应该仅保留在 GitHub"