项目流程运维 是做什么的？
该技能将分散的 GitHub 问题、拉取请求和 Linear 任务转变为统一的执行流程。
在问题涉及协调而非编码时使用。
何时使用
- 分类开放的拉取请求或问题待办事项
- 决定哪些内容应进入 Linear，哪些应仅保留在 GitHub
- 将活跃的 GitHub 工作与内部执行轨道关联
- 将拉取请求分类为合并、移植/重建、关闭或搁置
- 审计审查评论、CI 失败或过时问题是否阻碍执行
操作模型
- GitHub 是公开和社区真相来源
- Linear 是活跃排期工作的内部执行真相来源
- 并非每个 GitHub 问题都需要 Linear 问题
- 仅当工作满足以下条件时才创建或更新 Linear：
- 活跃
- 已委派
- 已排期
- 跨功能
- 重要到需要在内部跟踪
核心工作流
1. 先读取公开表面信息
收集：
- GitHub 问题或拉取请求状态
- 作者和分支状态
- 审查评论
- CI 状态
- 关联问题
2. 对工作进行分类
每项内容应归入以下状态之一：
| 状态 | 含义 |
|---|---|
| 合并 | 自包含、符合策略、已就绪 |
| 移植/重建 | 好想法，但需在 ECC 内部手动重建 |
| 关闭 | 方向错误、过时、不安全或重复 |
| 搁置 | 可能有用，但当前未排期 |
3. 决定是否值得创建 Linear 条目
仅当满足以下条件时才创建或更新 Linear：
- 正在积极规划执行
- 涉及多个仓库或工作流
- 工作需要内部归属或排序
- 该问题是更大程序轨道的一部分
不要机械地镜像所有内容。
4. 保持两个系统一致
当工作活跃时：
- GitHub 问题/拉取请求应说明公开正在发生什么
- Linear 应在内部跟踪负责人、优先级和执行轨道
当工作交付或被拒绝时：
- 将公开解决结果回写到 GitHub
- 相应地标记 Linear 任务
审查规则
- 切勿仅凭标题、摘要或信任进行合并；应使用完整差异
- 当外部来源的功能有价值但不自包含时，应在 ECC 内部重建
- CI 红色表示需要分类并修复或阻止；不要假装它已可合并
- 如果真正的阻碍是产品方向，请直接说明，而不是躲在工具后面
输出格式
返回：
公共状态
- 问题 / 拉取请求状态
- CI / 审查状态
分类
- 合并 / 移植-重建 / 关闭 / 搁置
- 一段理由说明
Linear 操作
- 创建 / 更新 / 无需 Linear 条目
- 项目 / 轨道（如适用）
下一步操作人员行动
- 精确的下一步行动
良好用例
- “审计开放的拉取请求待办事项，告诉我哪些应该合并，哪些应该重建”
- “将 GitHub 问题映射到我们的 ECC 1.x 和 ECC 2.0 程序轨道”
- “检查这需要一个 Linear 问题还是应仅保留在 GitHub”