project-flow-ops

SKILL.md

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"