mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-06-19 19:30:29 +08:00
db7f2a6fd5
The official Agent Skills spec (agentskills.io/specification) whitelists exactly 6 top-level frontmatter keys (name/description/license/compatibility/metadata/ allowed-tools). A top-level `origin` key fails the official validator (anthropics/skills quick_validate.py ALLOWED_PROPERTIES; skills-ref validate). This moves `origin: X` -> `metadata.origin: X` across the canonical skills/ tree, preserving each value verbatim. Frontmatter-only, minimal diff. - 251 SKILL.md updated (242 new metadata block, 9 appended to existing metadata) - origin values preserved verbatim (verified 251/251) - YAML validated on all changed files - scoped to canonical skills/ only (docs/<lang> translations + tool mirrors .cursor/.kiro/.agents left untouched; presumably regenerated from canonical) Addresses #2233
113 lines
3.1 KiB
Markdown
113 lines
3.1 KiB
Markdown
---
|
|
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"
|