PromptsEdge
FreeGitHubOther

Project Flow Ops

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.

affaan-m on GitHub

Curated by PromptsEdge from a public repo · MIT license. All credit goes to the author.

What is this skill?

This skill turns disconnected GitHub issues, PRs, and Linear tasks into one execution flow.

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

Use it when the problem is coordination, not coding.

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:

StateMeaning
Mergeself-contained, policy-compliant, ready
Port/Rebuilduseful idea, but should be manually re-landed inside ECC
Closewrong direction, stale, unsafe, or duplicated
Parkpotentially 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"

Related skills

View all →