project-flow-ops

Triages GitHub issues and pull requests and coordinates execution tracking with Linear.

Updated Jan 28, 2026
One-click install
npx skills add https://github.com/ttphats/project-detedxs26 --skill project-flow-ops-ttphats
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: project-flow-ops
Source: https://github.com/ttphats/project-detedxs26/tree/main/.augment/skills/ecc/project-flow-ops
Command: npx skills add https://github.com/ttphats/project-detedxs26 --skill project-flow-ops-ttphats

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams working across GitHub and Linear often lose track of which issues and pull requests need internal execution tracking, leading to stale backlogs, unlinked work, and inconsistent public versus internal status. ## Core Features & Use Cases - Backlog Triage: Classifies open PRs and issues into merge, port/rebuild, close, or park states based on diffs, CI status, and review comments. - GitHub-to-Linear Coordination: Decides when a GitHub item warrants a Linear issue and keeps public status and internal execution lanes consistent. - Structured Audit Output: Returns a standard report covering public status, classification rationale, Linear action, and the exact next operator move. - Use Case: Ask it to audit an open PR backlog and it will tell you which PRs to merge, which to rebuild internally, which to close, and which ones need Linear tracking. ## Quick Start Audit the open PR backlog and tell me what to merge, rebuild, close, or park, and which items need a Linear issue.

Frequently Asked Questions about project-flow-ops

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I triage a GitHub pull request backlog?▼

Review each PR's full diff, CI status, review comments, and linked issues, then classify it as merge, port/rebuild, close, or park. Never merge based on title or summary alone; red CI means fix or block, not merge-ready.

When should a GitHub issue get a Linear ticket?▼

Create a Linear issue only when work is active, delegated, scheduled, cross-functional, or important enough to track internally. Do not mirror every GitHub issue mechanically; many items should remain GitHub-only.

How do I keep GitHub and Linear status in sync?▼

While work is active, the GitHub issue or PR states what is happening publicly and Linear tracks owner, priority, and execution lane internally. When work ships or is rejected, post the public resolution to GitHub and update the Linear task accordingly.

What should I do with a valuable PR that does not fit the codebase?▼

Classify it as port/rebuild: the idea is useful but should be manually re-landed inside your own project rather than merged directly. This applies to external-source features that are valuable but not self-contained.

What are the limitations of automated PR triage?▼

Triage cannot replace product direction decisions; if the real blocker is strategy, that must be stated directly rather than hidden behind tooling. It also requires access to full diffs, CI results, and review context to classify accurately.