项目流程运维 是做什么的？
此技能将分散的 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 中标记任务
审查规则
- 切勿仅凭标题、摘要或个人信任直接合并；必须查看完整差异
- 源自外部的功能，如果价值高但不独立完整，应在 ECC 内部重建
- CI 为红色意味着需分类并修复或阻止，不要假装它已达到可合并状态
- 如果真正的阻碍是产品方向问题，就直言相告，而不是躲在工具背后
输出格式
返回：
公开状态
- issue / PR 状态
- CI / 审查状态
分类
- 合并 / 迁移-重建 / 关闭 / 暂缓
- 一段解释
LINEAR 操作
- 创建 / 更新 / 无需 Linear 项目
- 项目 / 轨道（如适用）
下一步操作者行动
- 确切的下一个步骤
良好使用场景
- “审计开放的 PR 待办列表，告诉我哪些应该合并，哪些需要重建”
- “将 GitHub issue 映射到我们的 ECC 1.x 和 ECC 2.0 程序轨道”
- “检查此 issue 是否需要创建 Linear 记录，还是应仅保留在 GitHub”