Project Flow Ops
Unify GitHub issues and PRs with Linear so public backlog truth and internal execution lanes stay linked without duplicating every ticket.
Overview
Project-flow-ops is an agent skill most often used in Build PM (also Ship review and Operate iterate) that triages GitHub issues and PRs and links active work to Linear without mirroring every public ticket.
Install
npx skills add https://github.com/affaan-m/everything-claude-code --skill project-flow-opsWhat is this skill?
- Defines GitHub as public truth and Linear as internal execution truth for active scheduled work
- Classifies each item into Merge, Port/Rebuild, Close, or Park after reading reviews and CI
- Triages open PR and issue backlogs when the blocker is coordination, not coding
- Creates or updates Linear issues only for active, delegated, cross-functional, or scheduled work
- Four PR/issue disposition states: Merge, Port/Rebuild, Close, Park
Adoption & trust: 3.2k installs on skills.sh; 210k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
GitHub issues, PR comments, and Linear tasks disagree about what is blocked, mergeable, or worth scheduling, so execution stalls on coordination.
Who is it for?
Maintainers running a public GitHub repo plus a Linear board who need PR triage and GitHub-to-Linear linking without double-entry on every issue.
Skip if: Solo hackers with no Linear workspace or no open GitHub surface, or when the task is purely implementation with an already groomed sprint board.
When should I use this skill?
The user wants backlog control, PR triage, or GitHub-to-Linear coordination when the problem is coordination, not coding.
What do I get? / Deliverables
Each backlog item lands in a clear disposition (merge, port/rebuild, close, or park) with Linear updated only for work that belongs on the internal execution track.
- Classified backlog with merge/port/close/park outcomes
- Linear updates limited to active or scheduled work
- Triage notes citing review, CI, and linkage status
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Execution flow and backlog triage sit in Build PM as the canonical home for how work is scheduled and tracked before and during implementation. The skill is coordination and classification (merge, port, park)—not writing feature code or deploying infra.
Where it fits
Decide which open GitHub issues deserve new Linear issues for this week's sprint.
Read review comments and CI on a community PR and label it Merge versus Port/Rebuild.
Audit stale issues blocking release and park low-value threads while keeping GitHub accurate.
How it compares
Use for cross-tool execution ops—not as a GitHub CLI cheat sheet or a substitute for code review skills.
Common Questions / FAQ
Who is project-flow-ops for?
Indie maintainers and small product teams coordinating community GitHub with internal Linear scheduling.
When should I use project-flow-ops?
At Build PM when grooming backlog; at Ship when classifying stalled PRs; at Operate when auditing stale issues and CI blockers.
Is project-flow-ops safe to install?
It implies reading and updating issue/PR metadata via your connected tools; review the Security Audits panel on this Prism page and scope agent tokens minimally.
SKILL.md
READMESKILL.md - Project Flow Ops
# Project Flow Ops This skill turns disconnected GitHub issues, PRs, and Linear tasks into one execution flow. Use it when the problem is coordination, not coding. ## When to Use - 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 ## Operating Model - **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 ## Core Workflow ### 1. Read the public surface first Gather: - GitHub issue or PR state - author and branch status - review comments - CI status - linked issues ### 2. Classify the work 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 | ### 3. Decide whether Linear is warranted Create or update Linear only if: - execution is actively planned - multiple repos or workstreams are involved - the work needs internal ownership or sequencing - the issue is part of a larger program lane Do not mirror everything mechanically. ### 4. Keep the two systems consistent When work is active: - GitHub issue/PR should say what is happening publicly - Linear should track owner, priority, and execution lane internally When work ships or is rejected: - post the public resolution back to GitHub - mark the Linear task accordingly ## Review Rules - Never merge from title, summary, or trust alone; use the full diff - External-source features should be rebuilt inside ECC when they are valuable but not self-contained - CI red means classify and fix or block; do not pretend it is merge-ready - If the real blocker is product direction, say so instead of hiding behind tooling ## Output Format Return: ```text PUBLIC STATUS - issue / PR state - CI / review state CLASSIFICATION - merge / port-rebuild / close / park - one-paragraph rationale LINEAR ACTION - create / update / no Linear item needed - project / lane if applicable NEXT OPERATOR ACTION - exact next move ``` ## Good Use Cases - "Audit the open PR backlog and tell me what to merge vs rebuild" - "Map GitHub issues into our ECC 1.x and ECC 2.0 program lanes" - "Check whether this needs a Linear issue or should stay GitHub-only"