project-flow-ops

Project Flow Ops 是一个用于在 GitHub 与 Linear 之间运营执行流程的技能。它的目标是把分散的 GitHub issue、PR 和 Linear 任务整合成一条统一的执行流。该技能适用于问题在于协调而非编码的场景。

用途

当团队需要梳理开放的 PR 或 issue 积压、判断哪些工作应进入 Linear、哪些应仅保留在 GitHub、将活跃的 GitHub 工作链接到内部执行通道、把 PR 分类为合并、移植/重建、关闭或搁置，以及审计评审评论、CI 失败或陈旧 issue 是否阻碍执行时，可以使用该技能。

运营模型

该技能遵循以下原则：GitHub 是面向公众和社区的真相来源；Linear 是活跃且已排期工作的内部执行真相来源；并非每个 GitHub issue 都需要对应的 Linear issue。只有当工作处于活跃状态、已委派、已排期、跨职能，或重要到需要在内部跟踪时，才创建或更新 Linear。

核心工作流

先读取公开表面：收集 GitHub issue 或 PR 状态、作者与分支状态、评审评论、CI 状态、关联 issue。
对工作分类：每个条目最终应归入以下状态之一——合并（自包含、符合策略、就绪）、移植/重建（想法有用，但应在 ECC 内手动重新落地）、关闭（方向错误、陈旧、不安全或重复）、搁置（可能有用，但当前未排期）。
判断是否需要 Linear：仅当执行已积极规划、涉及多个仓库或工作流、工作需要内部负责人或排序、或该 issue 属于更大项目通道的一部分时，才创建或更新 Linear。不要机械地镜像所有内容。
保持两个系统一致：当工作活跃时，GitHub issue/PR 应公开说明正在发生什么，Linear 应在内部跟踪负责人、优先级和执行通道；当工作发布或被拒绝时，将公开结论回帖到 GitHub，并相应标记 Linear 任务。

评审规则

绝不只凭标题、摘要或信任进行合并，必须使用完整 diff；外部来源的功能如果有价值但非自包含，应在 ECC 内重建；CI 红色意味着分类并修复或阻止，不要假装它已可合并；如果真正的阻碍是产品方向，应直接说明，而不是躲在工具背后。

输出格式

返回以下内容：

PUBLIC STATUS

CLASSIFICATION

LINEAR ACTION

NEXT OPERATOR ACTION

适用场景

例如：“审计开放的 PR 积压，告诉我哪些应合并、哪些应重建”“将 GitHub issue 映射到我们的 ECC 1.x 和 ECC 2.0 项目通道”“检查这是否需要 Linear issue，还是应仅保留在 GitHub”。

限制

该技能不负责编码本身，而是协调执行流程。它要求使用者理解 GitHub 与 Linear 的职责划分，并遵循评审规则。关于该技能的收费、价格、平台支持等具体信息，资料中暂未提供。

技能介绍