project-flow-ops
affaan-m/ecc
Coordinate GitHub and Linear by triaging issues, linking active work, and keeping execution synchronized across public and internal layers.
What is project-flow-ops?
This skill operates execution flow across GitHub and Linear, helping you triage issues and pull requests, classify work into merge/port/close/park states, and decide what belongs in Linear versus GitHub-only. Use it when you need backlog control, PR triage, or GitHub-to-Linear coordination without duplicating work mechanically.
- Triage open PR and issue backlogs and classify work into merge, port/rebuild, close, or park states
- Decide which GitHub issues warrant a Linear task based on active planning, cross-functional scope, and internal ownership needs
- Audit CI failures, review comments, and stale issues to identify execution blockers
- Link active GitHub work to internal Linear execution lanes and program ownership
- Keep GitHub as the public-facing truth while Linear tracks internal scheduling and priority
How to install project-flow-ops
npx skills add null --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 any linked issues
- 2.Classify the work into one of four states: Merge (ready), Port/Rebuild (useful but needs internal re-landing), Close (wrong direction or stale), or Park (potentially useful but not scheduled)
- 3.Decide whether Linear action is needed by checking if execution is actively planned, multiple repos are involved, internal ownership is required, or it is part of a larger program lane
- 4.If Linear action is warranted, create or update the task with owner, priority, and execution lane; if not, leave it GitHub-only
- 5.Return a summary with public status, classification rationale, Linear action taken, and the exact next operator move
Use cases
- Audit an open PR backlog and determine which PRs to merge, rebuild internally, close, or defer
- Map GitHub issues into program lanes (e.g., ECC 1.x vs 2.0) and create corresponding Linear tasks only for active work
- Review a stale issue with unresolved CI failures and decide whether to fix, close, or park it
- Sync a completed GitHub PR back to Linear and mark the internal task accordingly
- Determine whether an external-source feature should be rebuilt inside your codebase or closed as out-of-scope
- Engineering leads and project managers coordinating across GitHub and Linear
- Teams using GitHub for community-facing work and Linear for internal execution
- DevOps and release engineers triaging backlogs and managing cross-repo workflows
project-flow-ops FAQ
No. Create or update Linear only when execution is actively planned, multiple repos or workstreams are involved, internal ownership is needed, or the issue 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. Instead, manually re-land the idea inside your codebase with your own standards and architecture.
Do not pretend it is merge-ready. Classify the PR and either fix the CI, block the merge, or close the PR. Use the CI failure as a signal to decide the next action.
When work is active, ensure the GitHub issue/PR describes 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.
Close if the issue is in the wrong direction, stale, unsafe, or duplicated. Park if it is potentially useful but not scheduled now and may be revisited later.
Full instructions (SKILL.md)
Source of truth, from affaan-m/ecc.
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/ecc and the wider catalog.
project-guidelines-example
Agent skill from affaan-m/ecc.
prompt-optimizer
Analyze and optimize prompts to match ECC components for better task execution.
pubmed-database
Search PubMed and NCBI E-utilities for biomedical literature with MeSH queries, PMIDs, and citations.
python-patterns
Pythonic idioms, PEP 8 standards, type hints, and best practices for robust Python code.
python-testing
Comprehensive pytest and TDD testing strategies for Python with fixtures, mocking, parametrization, and coverage.
pytorch-patterns
PyTorch patterns and best practices for robust, efficient, reproducible deep learning pipelines.