project-flow-ops

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"