agentleFS
Sign inStart free
SamuelNDCESamuelNDCE/claude-super-skill-library/skills/misc-utilities/project-flow-ops/SKILL.md

project-flow-ops

Skill1 starsChanged 3 months agoMITView on GitHub

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.

7 other projects use a version of this, 4 of them edited.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

10 rules. 10 are common, 0 are distinctive, and 0 are very specific to this project.

  • 10

    Common

    Most of the 4 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Common:

    Use it when the problem is coordination, not coding.

    line 11
  2. Common:

    Not every GitHub issue needs a Linear issue

    line 25
  3. Common:

    Create or update Linear only when the work is:

    line 26
  4. Common:

    Every item should end up in one of these states:

    line 47
  5. Common:

    Create or update Linear only if:

    line 58
  6. Common:

    Do not mirror everything mechanically.

    line 65
  7. Common:

    When work is active:

    line 69
  8. Common:

    When work ships or is rejected:

    line 74
  9. Common:

    Never merge from title, summary, or trust alone.

    line 81
  10. Common:

    If the real blocker is product direction, say so instead of hiding behind tooling

    line 84

“Common” is measured: kept by at least 6 in 10 of the 4 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
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:

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:

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"

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free