project-flow-ops
Syncs GitHub activity with Linear for unified project execution and issue tracking.
Install
mkdir -p .claude/skills/project-flow-ops && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/17018" && unzip -o skill.zip -d .claude/skills/project-flow-ops && rm skill.zipInstalls to .claude/skills/project-flow-ops
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
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.Key capabilities
- →Triage GitHub issues and pull requests
- →Link active GitHub work to Linear tasks
- →Classify pull requests into merge, port/rebuild, close, or park
- →Audit review comments and CI failures
- →Maintain consistency between GitHub and Linear
- →Decide when a Linear issue is warranted for GitHub work
How it works
The skill first gathers information from GitHub, then classifies the work into one of four states. It then decides if a Linear issue is needed based on specific criteria and ensures consistency between the two systems.
Inputs & outputs
When to use project-flow-ops
- →Triaging GitHub PRs
- →Syncing issue backlogs
- →Linking PRs to Linear tasks
About this skill
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 EGC |
| 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 EGC 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:
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 EGC 1.x and EGC 2.0 program lanes"
- "Check whether this needs a Linear issue or should stay GitHub-only"
When not to use it
- →When the problem is coding, not coordination
- →When every GitHub issue needs a Linear issue
- →When the work is not active, delegated, scheduled, or cross-functional
Limitations
- →Not every GitHub issue needs a Linear issue
- →Linear is only updated for active, delegated, scheduled, or cross-functional work
- →The skill does not perform coding tasks
How it compares
This skill provides a structured operating model for coordinating work between GitHub and Linear, ensuring that GitHub remains public-facing while Linear tracks internal execution, rather than treating both as equivalent or disconnected.
Compared to similar skills
project-flow-ops side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| project-flow-ops (this skill) | 0 | 3mo | No flags | Intermediate |
| task-master | 22 | 6mo | Review | Intermediate |
| github-project-management | 4 | 6mo | Review | Advanced |
| sprint-planning | 0 | — | No flags | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by Fmarzochi
View all by Fmarzochi →You might also like
task-master
sfc-gh-dflippo
AI-powered task management for structured, specification-driven development. Use this skill when you need to manage complex projects with PRDs, break down tasks into subtasks, track dependencies, and maintain organized development workflows across features and branches.
github-project-management
ruvnet
Comprehensive GitHub project management with swarm-coordinated issue tracking, project board automation, and sprint planning
sprint-planning
SebastienDegodez
Use when planning sprint content, prioritizing stories within milestones, estimating capacity, or analyzing dependency graphs between stories. Covers MoSCoW prioritization, milestone management, velocity tracking, and dependency resolution for GitHub-based workflows.
plan-issue
bjorngun
Create an implementation plan for a GitHub issue, with a local planning file and issue updates. Use when: planning work, creating a task breakdown, generating a plan for an issue, updating issue fields from an existing plan, following a plan, continuing with the next task, working on a specific task
pm
josecoelho
GitHub Issues-based project management for obsidian-tasks-caldav
prepare
This-Is-NPC
Create implementation preparation artifacts from approved requirements. Use when a user asks to convert requirements into a project management issue and generate or create the implementation branch using workflow naming rules.