project-flow-ops

Project Flow Ops

此技能将分散的 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 红色意味着分类并修复或阻塞；不要假装它已准备好合并
• 如果真正的阻塞是产品方向，请直接说明，而不是隐藏在工具背后

输出格式

返回：

公开状态
- 议题 / PR 状态
- CI / 审查状态

分类
- 合并 / 移植-重建 / 关闭 / 搁置
- 一段理由说明

Linear 操作
- 创建 / 更新 / 不需要 Linear 项目
- 项目 / 通道（如适用）

下一步操作者行动
- 确切的下一个动作

好的使用案例

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