project-flow-ops

Use it when:: Your open PR and issue backlog needs triage, or you're unsure what deserves a Linear issue and what stays on GitHub.
It does:: Reads each issue or PR's state, reviews, CI and links, classifies it, and creates or updates Linear only for active, delegated or cross-team work.
You get:: For each item, its public status, a classification with rationale, the Linear action and the exact next move.
Model:: GitHub is the public record and Linear the internal execution record; when work ships or is rejected, both get updated.
Rules:: Never merge from a title or summary without the full diff, and treat red CI as blocked, not merge-ready.

Written for ECC's own repo: it says to rebuild useful outside contributions inside ECC, so read ECC as your project.

TL;DR

A coordination workflow for maintainers who keep public work on GitHub and internal scheduling in Linear. It reads the public surface first: issue or PR state, author and branch, review comments, CI status and linked issues. Each item lands in one of four states: merge when self-contained and ready, port or rebuild when the idea is useful but should be re-landed by the maintainers, close when wrong, stale, unsafe or duplicated, and park when useful but unscheduled. Linear gets an item only when work is actively planned, spans repos or workstreams, needs internal ownership or belongs to a larger program lane, rather than mirroring every issue. While work is active, GitHub says publicly what's happening and Linear tracks owner, priority and lane; when it ships or is rejected, the resolution is posted on GitHub and the Linear task is marked. If the real blocker is product direction, it says so. It was written for ECC's own backlog, so its rebuild advice and examples name ECC.

Summarizes the skill at d2ef268.

npx skills add https://github.com/affaan-m/ecc --skill project-flow-ops

skills.sh page Source on GitHub All skills from affaan-m/ecc

Total Downloads: 5,300 on skills.sh, Nov 9, 2026
Repo stars: 299,776 affaan-m/ecc
First seen: May 19, 2026 on skills.sh

Weekly Downloads

439

+72% over the 8 weeks to Nov 9

Weekly values

Week to	Installs
Sep 21	255
Sep 28	157
Oct 5	137
Oct 12	229
Oct 19	408
Oct 26	399
Nov 2	466
Nov 9	439

Category	category:engineering category:software-engineering Test-first work, implementation from specs, git hygiene and scope control. Everything for building software: planning, coding, debugging, design, frameworks, cloud, agents and skills.
Type	type:workflow A multi-step process the agent follows: interview, debug, run a TDD loop, review.
Effect	effect:remote Its own steps change something outside your machine: post, send, deploy, provision, file issues, drive a website, or upload data to a service.
Needs	needs:issue-tracker needs:account Reads or writes an issue tracker, GitHub Issues by default. An account, API key or paid plan with an outside service.
Publisher	by:community Everyone else. Unverified vendor claims default to community.
Topics	issue-tracking code-review
Stack	stack:github stack:linear

SKILL.md

From affaan-m/ecc at d2ef268. Checked daily, last changed Nov 6, 2026.

Frontmatter

name: project-flow-ops
description: 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.
metadata:
  origin: ECC

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:

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"