project-flow-ops
affaan-m/everything-claude-code
Triage GitHub issues and PRs, link active work to Linear, keep execution synchronized across public and internal layers.
What is project-flow-ops?
Coordinates execution flow between GitHub (public-facing) and Linear (internal execution). Use it to classify PRs and issues, decide what needs internal tracking, and keep both systems consistent as work moves from backlog to active to shipped.
- Triage open PR and issue backlogs into merge, port/rebuild, close, or park states
- Classify which GitHub work warrants a Linear task based on active planning and cross-functional scope
- Link active GitHub work to Linear execution lanes and ownership
- Audit CI failures, review blockers, and stale issues that prevent execution
- Sync public GitHub resolutions back to internal Linear tracking
How to install project-flow-ops
npx skills add https://github.com/affaan-m/everything-claude-code --skill project-flow-opsHow to use project-flow-ops
- 1.Gather the GitHub issue or PR state, author, branch status, review comments, CI status, and linked issues
- 2.Classify the work into one of four states: Merge, Port/Rebuild, Close, or Park
- 3.Decide whether the work warrants a Linear task (active, delegated, scheduled, cross-functional, or program-critical)
- 4.Return public status, classification rationale, Linear action, and next operator move
- 5.Keep both systems consistent: update GitHub with public resolution and mark Linear task accordingly
Use cases
- Audit an open PR backlog and decide what to merge versus rebuild internally
- Map GitHub issues into program lanes (e.g., ECC 1.x vs 2.0 roadmaps)
- Determine whether a GitHub issue needs a Linear task or should remain GitHub-only
- Unblock execution by identifying real product direction blockers hidden behind tooling issues
- Keep GitHub and Linear consistent when work ships or is rejected
- Engineering leads managing public and internal backlogs
- Project managers coordinating across GitHub and Linear
- Teams using GitHub for community contributions and Linear for scheduled execution
project-flow-ops FAQ
No. Create or update Linear only if execution is actively planned, multiple repos are involved, the work needs internal ownership, or it is part of a larger program lane. Do not mirror everything mechanically.
The GitHub contribution is useful but not self-contained enough to merge as-is. The idea should be manually re-landed inside the project's internal codebase with proper integration.
Classify and fix or block the work; do not pretend it is merge-ready. If the real blocker is product direction, say so instead of hiding behind tooling issues.
When work is active, GitHub shows what is happening publicly while Linear tracks owner, priority, and lane internally. When work ships or is rejected, post the resolution back to GitHub and mark the Linear task accordingly.
Use it for backlog triage, PR classification, GitHub-to-Linear coordination, and auditing whether review comments or CI failures are blocking execution.
Full instructions (SKILL.md)
Source of truth, from affaan-m/everything-claude-code.
name: project-flow-ops description: 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. metadata: origin: ECC
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:
| State | Meaning |
|---|---|
| Merge | self-contained, policy-compliant, ready |
| Port/Rebuild | useful idea, but should be manually re-landed inside ECC |
| Close | wrong direction, stale, unsafe, or duplicated |
| Park | potentially 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"
Related skills
More from affaan-m/everything-claude-code and the wider catalog.
security-review
Security checklist and patterns for authentication, input validation, secrets, and sensitive features.
golang-patterns
Idiomatic Go patterns, best practices, and conventions for building robust, efficient, and maintainable applications.
coding-standards
Baseline coding conventions for naming, readability, immutability, and quality across projects.
frontend-patterns
React and Next.js patterns for components, state management, performance, and modern frontend practices.
backend-patterns
REST/GraphQL API design, database optimization, and server-side patterns for Node.js, Express, and Next.js.
golang-testing
Go testing patterns: table-driven tests, subtests, benchmarks, fuzzing, and TDD methodology.