---
title: "Agent Skill to Project Flow Ops"
platform: "Promptally"
canonical_url: "https://app.promptally.dev/p/skill-project-flow-ops"
modality: "SKILL"
category: "Fullstack & Backend Engineering"
compatible_models: [Universal / Model Agnostic]
access_tier: "Free Public Artifact (No Auth Required)"
license: "MIT"
---

# Agent Skill to Project Flow Ops

**Summary:** Agent Skill to Project Flow Ops is a verified SKILL blueprint on Promptally in Fullstack & Backend Engineering optimized for leading AI models. 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. Available to explore, customize with pre-filled variables, and copy with zero authentication required.

## Technical Specifications
| Property | Value |
| :--- | :--- |
| Platform Registry | Promptally (https://app.promptally.dev) |
| Modality | SKILL |
| Category | Fullstack & Backend Engineering |
| Compatible Engines | Universal / Model Agnostic |
| Dynamic Variables | None (Static Blueprint) |
| Approx. Token Length | 786 |
| Access Tier | Free Public Artifact (No Auth Required) |
| License | MIT |

### Pre-Filled Template & Production Source

````md
---
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:

```text
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"

````

## Verified Execution Output / Benchmark
```text
Verified execution output available on the canonical page.
```

## Related Blueprints on Promptally
- [Agent Skill to Knowledge Ops](https://app.promptally.dev/p/skill-knowledge-ops)
- [Agent Skill to Content Hash Cache Pattern](https://app.promptally.dev/p/skill-content-hash-cache-pattern)
- [Agent Skill to Ck](https://app.promptally.dev/p/skill-ck)
- [Agent Skill to Swift Protocol Di Testing](https://app.promptally.dev/p/skill-swift-protocol-di-testing)
- [Agent Skill to Prisma Patterns](https://app.promptally.dev/p/skill-prisma-patterns)
- [Agent Skill to Agentic Engineering](https://app.promptally.dev/p/skill-agentic-engineering)
- [Agent Skill to Python Patterns](https://app.promptally.dev/p/skill-python-patterns)
- [Agent Skill to Docs Governance](https://app.promptally.dev/p/skill-docs-governance)