codeply-cli 0.3.0 → 0.4.0

package/skills/project-flow-ops/SKILL.md

@@ -1,112 +1,112 @@
----
-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"
+---
+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"