@cleocode/skills 2026.5.78 → 2026.5.81
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json
CHANGED
package/skills/ct-cleo/SKILL.md
CHANGED
|
@@ -30,13 +30,24 @@ Supported sections: `session-start` · `work-loop` · `triggers` · `task-creati
|
|
|
30
30
|
|
|
31
31
|
## Skill-Specific Extensions
|
|
32
32
|
|
|
33
|
-
###
|
|
33
|
+
### Task Hierarchy (canonical source: ADR-073 §1)
|
|
34
34
|
|
|
35
|
-
|
|
36
|
-
|
|
37
|
-
edges. `cleo list --parent <sagaId>` will NOT surface members — use `cleo saga members <id>`.
|
|
35
|
+
CLEO has 4 tiers. Each defined by scope-of-change + agent ownership. All IDs stored as `T####`;
|
|
36
|
+
`type` column discriminates; prefixes (`SG-`, `E-`, `T-`) are display + import-mapping only.
|
|
38
37
|
|
|
39
|
-
|
|
40
|
-
|
|
38
|
+
| Tier | Prefix | Scope-of-change | Owner (ADR-070) |
|
|
39
|
+
|---------|--------|-------------------------------------------------|----------------------|
|
|
40
|
+
| Saga | `SG-` | ≥2 Epics across ≥2 releases (themed grouping) | Orchestrator (read) |
|
|
41
|
+
| Epic | `E-` | One releasable slice; ≥1 PR to `main` | Orchestrator (HITL) |
|
|
42
|
+
| Task | `T-` | One atomic PR-sized change; single wave | Phase Lead |
|
|
43
|
+
| Subtask | (none) | One commit; ≤2 files; rolls up to Task's PR | Worker (leaf) |
|
|
44
|
+
|
|
45
|
+
**I8 — Subtask-to-PR aggregation:** A Task ships as exactly ONE PR. Subtasks contribute commits
|
|
46
|
+
to that single PR; Subtasks never own a PR. Promote a Subtask to a sibling Task if it warrants
|
|
47
|
+
its own PR.
|
|
48
|
+
|
|
49
|
+
Full charter (8 invariants + lifecycle decision table + prefix registry) lives in
|
|
50
|
+
`.cleo/adrs/ADR-073-above-epic-naming.md` §1–§2. CLI commands for Sagas: see
|
|
51
|
+
CLEO-INJECTION.md `task-creation` section (`cleo briefing inject --section task-creation`).
|
|
41
52
|
|
|
42
53
|
For full decision trees and operation reference tables, emit sections above.
|
|
@@ -82,18 +82,29 @@ Epic (type: epic, size: large)
|
|
|
82
82
|
└── Task 5 (depends: T4) [Wave 3]
|
|
83
83
|
```
|
|
84
84
|
|
|
85
|
-
###
|
|
85
|
+
### Tier Sizing & Scope (canonical source: ADR-073 §1.1)
|
|
86
86
|
|
|
87
|
-
|
|
88
|
-
|
|
89
|
-
|
|
90
|
-
|
|
91
|
-
|
|
87
|
+
**DO NOT redefine here.** The strict definitions live in `.cleo/adrs/ADR-073-above-epic-naming.md`
|
|
88
|
+
§1.1 (tier table) + §1.2 (8 invariants I1–I8) + §1.3 (lifecycle decision table).
|
|
89
|
+
|
|
90
|
+
Quick reference for decomposition:
|
|
91
|
+
|
|
92
|
+
| Tier | Scope-of-change | Sizing |
|
|
93
|
+
|---------|----------------------------------------------------|----------------------------------------------------|
|
|
94
|
+
| Saga | Theme grouping ≥2 Epics across ≥2 releases | ≥2 child Epics |
|
|
95
|
+
| Epic | One releasable slice; ≥1 PR to `main` | 4–10 child Tasks |
|
|
96
|
+
| Task | One atomic PR-sized change; single wave | 1–7 child Subtasks (or leaf); single PR |
|
|
97
|
+
| Subtask | One commit; ≤2 files OR one module boundary | 1 commit; contributes to parent Task's single PR |
|
|
98
|
+
|
|
99
|
+
**I8 (load-bearing):** A Task ships as exactly ONE PR. Multiple Subtasks contribute commits to
|
|
100
|
+
that single PR. Subtasks never own a PR — if a unit warrants its own PR, it MUST be a Task.
|
|
101
|
+
When decomposing, ask: "does this unit need its own PR?" → Task. "Is this a commit inside a
|
|
102
|
+
larger PR?" → Subtask.
|
|
92
103
|
|
|
93
104
|
### Above-Epic: Sagas (ADR-073, v2026.5.77+)
|
|
94
105
|
|
|
95
106
|
A **Saga** groups multiple Epics into a multi-release theme. Use a Saga when the work spans
|
|
96
|
-
more than one
|
|
107
|
+
more than one releasable Epic and you want a stable handle for rollup/reporting. A Saga is a
|
|
97
108
|
labeled top-level Epic (`label='saga'`) — NOT a new TaskType — so the parent ladder (maxDepth=3)
|
|
98
109
|
under each member Epic is unaffected.
|
|
99
110
|
|
|
@@ -31,6 +31,30 @@ You are the **Orchestrator** — a conductor, never a musician. You coordinate c
|
|
|
31
31
|
| ORC-011 | Pre-release verification gate | NEVER `git push --tags` without full pipeline green: biome ci packages/, build, test, changelog, version |
|
|
32
32
|
| ORC-012 | Honest reporting | "Shipped" ≠ "designed" ≠ "in progress" — distinguish always; never claim CI green without seeing the green |
|
|
33
33
|
|
|
34
|
+
## Task Hierarchy (canonical source: ADR-073 §1)
|
|
35
|
+
|
|
36
|
+
Orchestrators MUST respect the 4-tier hierarchy. All IDs stored as `T####`; `type` column
|
|
37
|
+
discriminates; prefixes (`SG-`, `E-`, `T-`) are display + import-mapping only.
|
|
38
|
+
|
|
39
|
+
| Tier | Prefix | Scope-of-change | Orchestration role |
|
|
40
|
+
|---------|--------|-------------------------------------------------|----------------------|
|
|
41
|
+
| Saga | `SG-` | ≥2 Epics across ≥2 releases | Orchestrator (read) |
|
|
42
|
+
| Epic | `E-` | One releasable slice; ≥1 PR to `main` | Orchestrator (HITL) |
|
|
43
|
+
| Task | `T-` | One atomic PR-sized change; single wave | Phase Lead |
|
|
44
|
+
| Subtask | (none) | One commit; ≤2 files; rolls up to Task's PR | Worker (leaf) |
|
|
45
|
+
|
|
46
|
+
**I8 (load-bearing for decomposition):** A Task ships as exactly ONE PR. Subtasks contribute
|
|
47
|
+
commits to that single PR — they NEVER own a PR. When decomposing under RCASD, if a unit needs
|
|
48
|
+
its own PR it MUST be a Task, not a Subtask.
|
|
49
|
+
|
|
50
|
+
**Tier-promotion triggers (see ADR-073 §1.3 for full decision table):**
|
|
51
|
+
- Subtask edits >2 files OR crosses module boundary → split or promote to sibling Task
|
|
52
|
+
- Task generates >1 PR → split into sibling Tasks under the same Epic
|
|
53
|
+
- Epic spans >1 release → regroup under a Saga
|
|
54
|
+
|
|
55
|
+
Full charter (8 invariants I1–I8 + prefix registry) lives in
|
|
56
|
+
`.cleo/adrs/ADR-073-above-epic-naming.md` §1–§2.
|
|
57
|
+
|
|
34
58
|
## LOOM — The Core Lifecycle
|
|
35
59
|
|
|
36
60
|
**LOOM** (Logical Order of Operations Methodology) is the systematic lifecycle for ALL work. Every incoming issue, feature, bug, or idea flows through LOOM's two phases:
|