project-flow-ops

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

2|Updated Mar 29, 2015
One-click install
npx skills add https://github.com/ovisan/dotfiles --skill project-flow-ops-ovisan
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: project-flow-ops
Source: https://github.com/ovisan/dotfiles/tree/main/.agents/skills/project-flow-ops
Command: npx skills add https://github.com/ovisan/dotfiles --skill project-flow-ops-ovisan

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Disconnected GitHub issues, pull requests, and Linear tasks create coordination chaos where backlogs go untriaged, PRs stall without clear decisions, and teams lose track of what is public-facing versus internally scheduled work. ## Core Features & Use Cases - Backlog Triage: Classify every open PR or issue into merge, port/rebuild, close, or park with a clear rationale based on diffs, CI status, and review comments. - GitHub-to-Linear Coordination: Decide which work warrants a Linear issue for internal execution tracking while keeping GitHub as the public source of truth. - Execution Audits: Detect blockers from stale issues, failing CI, or unresolved review comments and surface the exact next operator action. - Use Case: Ask the Skill to audit your open PR backlog and it returns each item's public status, a classification with rationale, whether a Linear item is needed, and the concrete next move. ## Quick Start Audit the open PR backlog in this repository and tell me what to merge, rebuild, close, or park, including which items need Linear issues.

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?

Gather each PR's state, author, branch status, review comments, CI status, and linked issues, then classify it as merge, port/rebuild, close, or park. Base decisions on the full diff rather than titles or summaries, and treat failing CI as a blocker to fix or escalate.

When should a GitHub issue get a Linear issue?

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; Linear tracks internal execution while GitHub remains the public truth.

How do I keep GitHub and Linear in sync for active work?

For active work, the GitHub issue or PR states what is happening publicly while 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 external PRs that have useful ideas but do not fit?

Classify them as port/rebuild: the idea is valuable but should be manually re-landed inside your own codebase rather than merged directly. Close PRs that are wrong-direction, stale, unsafe, or duplicated, and park items that are potentially useful but not scheduled.

Can I merge a PR based on its title and summary alone?

No. Always review the full diff before merging, since titles and summaries can hide unsafe or non-compliant changes. Red CI means the PR must be fixed or blocked, never treated as merge-ready.