Project Flow Ops

1---2name: project-flow-ops3description: Operate execution flow across GitHub and Linear by triaging issues and pull requests, linking active work, and keeping GitHub public-facing while Linear remains the internal execution layer. Use when the user wants backlog control, PR triage, or GitHub-to-Linear coordination.4origin: ECC5---6 7# Project Flow Ops8 9This skill turns disconnected GitHub issues, PRs, and Linear tasks into one execution flow.10 11Use it when the problem is coordination, not coding.12 13## When to Use14 15- Triage open PR or issue backlogs16- Decide what belongs in Linear vs what should remain GitHub-only17- Link active GitHub work to internal execution lanes18- Classify PRs into merge, port/rebuild, close, or park19- Audit whether review comments, CI failures, or stale issues are blocking execution20 21## Operating Model22 23- **GitHub** is the public and community truth24- **Linear** is the internal execution truth for active scheduled work25- Not every GitHub issue needs a Linear issue26- Create or update Linear only when the work is:27  - active28  - delegated29  - scheduled30  - cross-functional31  - important enough to track internally32 33## Core Workflow34 35### 1. Read the public surface first36 37Gather:38 39- GitHub issue or PR state40- author and branch status41- review comments42- CI status43- linked issues44 45### 2. Classify the work46 47Every item should end up in one of these states:48 49| State | Meaning |50|-------|---------|51| Merge | self-contained, policy-compliant, ready |52| Port/Rebuild | useful idea, but should be manually re-landed inside ECC |53| Close | wrong direction, stale, unsafe, or duplicated |54| Park | potentially useful, but not scheduled now |55 56### 3. Decide whether Linear is warranted57 58Create or update Linear only if:59 60- execution is actively planned61- multiple repos or workstreams are involved62- the work needs internal ownership or sequencing63- the issue is part of a larger program lane64 65Do not mirror everything mechanically.66 67### 4. Keep the two systems consistent68 69When work is active:70 71- GitHub issue/PR should say what is happening publicly72- Linear should track owner, priority, and execution lane internally73 74When work ships or is rejected:75 76- post the public resolution back to GitHub77- mark the Linear task accordingly78 79## Review Rules80 81- Never merge from title, summary, or trust alone; use the full diff82- External-source features should be rebuilt inside ECC when they are valuable but not self-contained83- CI red means classify and fix or block; do not pretend it is merge-ready84- If the real blocker is product direction, say so instead of hiding behind tooling85 86## Output Format87 88Return:89 90```text91PUBLIC STATUS92- issue / PR state93- CI / review state94 95CLASSIFICATION96- merge / port-rebuild / close / park97- one-paragraph rationale98 99LINEAR ACTION100- create / update / no Linear item needed101- project / lane if applicable102 103NEXT OPERATOR ACTION104- exact next move105```106 107## Good Use Cases108 109- "Audit the open PR backlog and tell me what to merge vs rebuild"110- "Map GitHub issues into our ECC 1.x and ECC 2.0 program lanes"111- "Check whether this needs a Linear issue or should stay GitHub-only"