project-flow-ops

Topics in the source

• Project Flow Ops
• When to Use
• Operating Model
• Core Workflow
• 1. Read the public surface first
• 2. Classify the work
• 3. Decide whether Linear is warranted
• 4. Keep the two systems consistent

This skill turns disconnected GitHub issues, PRs, and Linear tasks into one execution flow. Use it when the problem is coordination, not coding. Triage open PR or issue backlogs Decide what belongs in Linear vs what should remain GitHub-only Link active GitHub work to internal execution lanes Classify PRs into merge, port/rebuild, close, or park Audit whether review comments, CI failures, or stale issues are blocking execution GitHub is the public and community truth Linear is the internal execution truth for active scheduled work Not every GitHub issue needs a Linear issue Create or update Linear only when the work is: active delegated scheduled cross-functional important enough to track internally Gather: GitHub issue or PR state author and branch status review comments CI status linked issues Every item should end up in one of these states: | State | Meaning | |-------|---------| | Merge | self-contained, policy-compliant, ready | | Port/Rebuild | useful idea, but should be manually re-landed inside ECC | | Close | wrong direction, stale, unsafe, or duplicated | | Park | potentially useful, but not scheduled now | Create or update Linear only if: execution is actively planned mu

This is an excerpt. Refer to the complete source and its current requirements.