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 红色意味着分类并修复或阻塞；不要假装它已准备好合并
- 如果真正的阻塞因素是产品方向，直接说出来，而不是隐藏在工具后面

## 输出格式

返回：

```text
公开状态
- issue / PR 状态
- CI / 审查状态

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

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

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

## 好的用例

- "审计开放的 PR 待办列表并告诉我要合并什么与重建什么"
- "将 GitHub issue 映射到我们的 ECC 1.x 和 ECC 2.0 计划通道"
- "检查这是否需要 Linear issue 还是应该保持仅 GitHub"