Appearance
Project Flow Ops Skill 是 Everything Claude Code 插件体系中专为 GitHub 与 Linear 协同设计的执行流控制工具。它将分散的 issue、PR 与内部任务流打通，实现高效 backlog 管理、PR triage、跨系统归类与决策。适用于需要精细区分公开协作（GitHub）与内部执行（Linear）、多项目/多团队协同、以及希望系统性提升 AI 辅助项目流转效率的开发者团队。
Everything Claude Code Project Flow Ops Skill：GitHub + Linear 协同 Backlog 控制与 PR Triage
在现代开发流程中，如何高效管理公开的 GitHub backlog 与团队内部的 Linear 任务流，是影响协作效率和交付质量的核心问题。Project Flow Ops Skill 正是为此而生——它将「公开协作」与「内部执行」两套体系有机衔接，解决了传统“只靠人工同步”或“全量镜像”带来的混乱与低效。
本指南将详细介绍 Project Flow Ops Skill 的典型应用场景、触发时机、完整操作流程、输出示例，以及与常见 Agent/Skill 的协作关系，帮助你在实际项目中用好这一生产级 AI 编程能力。
1. 这个 Skill 解决了什么问题？
在未使用 Project Flow Ops Skill 前，团队常见的痛点包括：
- PR/Issue Backlog 堆积：GitHub 上公开的 issue 和 PR 难以及时梳理、分类和归档，容易出现“僵尸 backlog”或重复劳动。
- 内部/外部执行割裂：Linear 作为内部排期与执行系统，和 GitHub 的公开协作断层，导致信息同步滞后，任务归属不清。
- 决策不透明：哪些 PR/issue 需要进入 Linear 严格跟踪，哪些只需 GitHub 公开处理，缺乏标准和自动化支持。
- 人工 triage 负担重：人工逐条归类、同步、分配，既低效又易错。
Project Flow Ops Skill 通过智能聚合、归类与流转，自动完成 backlog triage、跨系统同步和决策建议，极大减轻了人工负担，并提升了团队协作的透明度和执行力。
2. 典型触发场景与激活时机
你应在以下场景下主动调用 Project Flow Ops Skill：
- 定期梳理 PR/Issue Backlog：如每周例会前，批量审查哪些可以合并、关闭、重建或暂缓。
- 需求/任务分流决策：判断某个 issue/PR 是否需要进入 Linear 内部排期，还是仅在 GitHub 公开跟踪。
- 多项目/多团队协同：当一个任务涉及多个 repo 或跨团队，需要明确归属和执行路径。
- CI 挂红或 Review 卡住：需要判断当前阻塞点是技术、流程还是产品方向，并给出下一步建议。
- 项目/版本切换：如 ECC 1.x/2.0 多版本并行时，自动映射 backlog 至对应 program lane。
3. 实际操作流程（Step by Step）
步骤 1：读取公开面（GitHub）状态
Skill 首先自动收集以下信息：
- 当前 issue 或 PR 的状态（open/closed/merged 等）
- 作者、分支、关联 issue
- Review 评论与 CI 状态
- 是否已关联 Linear 或其他内部系统
示例输出片段：
text
PUBLIC STATUS
- PR #1234: open
- CI: failed
- Review: 2 pending comments步骤 2：智能归类（Classification）
Skill 会将每个 backlog item 归入以下四类之一，并给出理由：
| 状态 | 说明 |
|---|---|
| Merge | 已自洽、合规、可直接合并 |
| Port/Rebuild | 有价值，但需在 ECC 内部重建/迁移实现 |
| Close | 方向错误、过时、不安全或重复 |
| Park | 有潜力，但当前未排期，暂缓处理 |
示例输出片段：
text
CLASSIFICATION
- port-rebuild
- 该 PR 提供了有用的功能思路，但实现依赖外部库且未符合 ECC 代码规范，建议内部重构后再合并。步骤 3：判断是否需要创建/更新 Linear 任务
Skill 会根据以下标准判断是否要同步到 Linear：
- 该项工作已被计划、分配或跨团队协作
- 涉及多个 repo 或需要内部 owner
- 属于重要 program lane
- 纯社区贡献、一次性修复、无内部排期则无需同步
示例输出片段：
text
LINEAR ACTION
- create
- project: ECC 2.0 / API Lane步骤 4：保持 GitHub 与 Linear 一致性
- 活跃任务：GitHub 公开状态及时同步，Linear 跟踪 owner、优先级、执行进度
- 完成/拒绝：在 GitHub 公布最终结果，Linear 标记已完成或关闭
步骤 5：输出下一步操作建议
Skill 会直接给出下一步应由谁做什么，避免“决策悬空”。
完整输出示例：
text
PUBLIC STATUS
- PR #5678: open
- CI: passed
- Review: approved
CLASSIFICATION
- merge
- 该 PR 已通过所有自动化测试和代码审查，符合合并标准。
LINEAR ACTION
- no Linear item needed
NEXT OPERATOR ACTION
- 合并该 PR，并在 GitHub 关闭相关 issue。4. 常见配套 Agent 与 Skill 协作关系
Project Flow Ops Skill 通常与以下 Agent/Skill 协同使用，形成系统性协作流：
- Code Reviewer Agent：自动审查 PR 质量，为 triage 提供技术依据（Code Reviewer Agent 详解）。
- Build Error Resolver Agent：CI 挂红时自动定位并修复构建错误（Build Error Resolver Agent）。
- Blueprint Skill / Planner Agent：复杂需求分解后，将任务流映射到 Linear program lane。
- Verification Loop Skill：端到端验证后自动更新 backlog 状态（Verification Loop Skill）。
- Git Workflow Skill：规范分支、合并、rebase 流程，减少 triage 冲突（Git Workflow Skill）。
通过与上述组件协作，Project Flow Ops Skill 能在 Claude Code 体系下实现“自动梳理-智能归类-高效流转-透明交付”的闭环。
5. 使用建议与注意事项
- 不要全量同步：不是所有 GitHub issue/PR 都要进 Linear，避免信息冗余。
- 归类理由要具体：Skill 输出的 rationale 段落应简明说明决策依据，便于团队共识。
- 关注 CI/Review 状态：CI 挂红或 Review 未通过，优先分类为 block/park，避免误合并。
- 及时反馈结果：合并、关闭、重建等操作后，需同步更新两端状态，保持一致性。
- 定期批量梳理：建议每周或每版本周期，批量运行 Project Flow Ops Skill，提升 backlog 健康度。
FAQ
Q: Project Flow Ops Skill 适合哪些团队？ A: 适合有 GitHub 公开协作、Linear 内部排期，且需要高效 backlog 管理和多团队协作的中大型开发团队。
Q: Skill 输出的决策建议可以直接执行吗？ A: 可以。Skill 输出包含分类理由与下一步操作，便于直接落地，也支持人工复核后再执行。
Q: 如何与其他 Agent/Skill 组合提升效率？ A: 可结合 Code Reviewer、Build Error Resolver 等 Agent，实现自动化审查、修复与流转，形成端到端的高效协作闭环。