agentsclimarketplace
Sign in

Project flow ops

Skill Sheshiyer/skill-clusters/skills/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.From its SKILL.md

Install
npx -y skills add Sheshiyer/skill-clusters --skill project-flow-ops

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.1 KB, 641 tokens by cl100k_base, as published. Nobody here has run it

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 the agent stack
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 the agent stack 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 internal 1.x and 2.0 program lanes"
  • "Check whether this needs a Linear issue or should stay GitHub-only"

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most ship operate skills give in 641 tokens

Counted across 779 of the 1,178 authors here whose files we hold, read 2026-08-07

  • Document a rollback plan before deploymentin 41 of 779, across 22 files
  • Update the changelogin 21 of 779, across 19 files
  • Run the test suitein 20 of 779
  • Create an annotated git tagin 20 of 779
  • Clean up feature flags after full rolloutin 18 of 779, across 10 files
  • Verify deployment health after launchin 18 of 779, across 10 files
  • Test both feature flag statesin 17 of 779, across 9 files
  • Verify the working tree is cleanin 17 of 779
  • Make database migrations backward-compatiblein 16 of 779, across 8 files
  • Set up error monitoring before launchin 15 of 779, across 7 files
  • Monitor metrics at each rollout stagein 14 of 779, across 5 files
  • Create a GitHub releasein 14 of 779

Said here and by no other author read

  • Gather public issue, PR, review, CI, and linked data
  • Classify each item as merge, port-rebuild, close, or park
  • Rebuild valuable non-self-contained features internally
  • Resolve CI failures before classifying as merge-ready
  • Create Linear issues only for active or cross-functional work
  • Keep GitHub public status and Linear execution details consistent

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 326,144. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.