feat(workflows): add flexible execution shapes

.claude-plugin/marketplace.json

@@ -12,7 +12,7 @@
     {
       "name": "compound-engineering",
       "description": "OpenCode-first AI-powered development tools. Includes 29 specialized agents, 26 commands, and 24 skills spanning code review, research, design, and workflow automation, with generated Copilot support and Claude Code compatibility outputs.",
-      "version": "4.4.0",
+      "version": "4.5.0",
       "author": {
         "name": "The Rabak",
         "email": "arielvaron@gmail.com",

.github/skills/brainstorming/SKILL.md

@@ -11,7 +11,7 @@ This skill provides detailed process knowledge for effective brainstorming sessi
 The brainstorm produces three lynchpin artifacts that anchor all downstream phases:
 1. **Problem Narrative & User Story** -- the WHY (consumed by plan, work, and review)
 2. **Architectural Context Map** -- the WHERE (consumed by execution agents and reviewers)
-3. **Design Decisions** -- the WHAT (consumed by plan for task decomposition)
+3. **Design Decisions** -- the WHAT (consumed by plan for execution-slice decomposition)
 
 ## When to Use This Skill
 
@@ -306,18 +306,18 @@ This prevents wasted effort on misaligned designs.
 The brainstorm document is the **feature-level spec and handoff contract** for downstream work. The project constitution, when present, remains the repo-wide governing artifact:
 
 **`/workflows-plan` consumes:**
-- Problem narrative and user story -> structures phases around the WHY
-- Architectural context -> informs task decomposition, file mapping, dependencies
+- Problem narrative and user story -> structures execution slices around the WHY
+- Architectural context -> informs slice decomposition, file mapping, dependencies
 - Success criteria -> becomes the plan's acceptance criteria foundation
 - Key decisions -> preserved and enriched, not re-decided
 
 **`/deepen-plan` consumes:**
-- Problem narrative -> evaluates whether deepened tasks still serve the original intent
+- Problem narrative -> evaluates whether deepened slices still serve the original intent
 - Success criteria -> grounds best-practice research in actual goals
 
 **`/workflows-work` consumes:**
 - Architectural context -> populates `{{ARCHITECTURAL_CONTEXT}}` for every execution agent
-- User story -> orchestrator validates each task contributes to the story
+- User story -> orchestrator validates each slice contributes to the story
 - Problem narrative -> included in scoped prompts so agents understand purpose
 
 **`/workflows-review` consumes:**

.github/skills/deepen-plan/SKILL.md

@@ -81,7 +81,8 @@ First, read and parse the plan to extract the WHY artifacts (problem narrative,
 
 - [ ] Overview/Proposed Solution sections
 - [ ] Technical Approach/Architecture
-- [ ] Implementation phases/steps (noting which user story aspect each phase serves)
+- [ ] `execution_shape` frontmatter + `## Execution Shape` section
+- [ ] Execution packets / phase wrappers (noting which user story aspect each packet serves)
 - [ ] Code examples and file references
 - [ ] Acceptance criteria
 - [ ] Any UI/UX components mentioned
@@ -100,92 +101,117 @@ The "Serves" column ensures every deepening activity traces back to WHY we're bu
 ### 1.1 Validate Execution Readiness
 
 <thinking>
-Check if the plan has sufficiently structured execution chunks for the subagent orchestration model in /workflows-work. Plans need per-task success criteria, test commands, and file lists. Also validate that phases trace to the user story.
+Check if the plan has sufficiently structured execution packets for the subagent orchestration model in `/workflows-work`. Use `references/execution-shape.md` as the source of truth. Plans need packets that are independently executable, testable, and traceable back to the user story without forcing fake verticality.
 </thinking>
 
-**Scan each implementation task/phase for these required fields:**
+**Resolve execution shape first:**
 
-- [ ] **Files:** List of files to create or modify
-- [ ] **Depends on:** Dependencies on other tasks
-- [ ] **Success criteria:** Testable checkboxes defining "done"
-- [ ] **Test command:** Exact command to verify completion
-- [ ] **TDD alignment:** Task-level test commands collectively satisfy the resolved unit/e2e evidence contract, or the plan records a justified exception with replacement evidence
+- [ ] Read `execution_shape.mode`; if missing, default it to `vertical-slices`
+- [ ] Read `execution_shape.rationale`; require it when the mode is not `vertical-slices`
+- [ ] Ensure the body includes a matching `## Execution Shape` section
+- [ ] If the chosen mode looks wrong for the real work, add a `### WHY Reassessment` note instead of silently changing it
+
+**Scan each execution packet using the required fields from `references/execution-shape.md`:**
+
+- [ ] **`vertical-slices`:** slice type, serves, demo scenario, scope + scope fence, files, depends on, dependency type, success criteria, test command
+- [ ] **`infra-track`:** capability enabled, consumers / downstream work unlocked, scope, files, depends on, risk / rollback, validation command, success criteria
+- [ ] **`fix-batch`:** problem, repro / expected outcome, files, depends on, validation command, success criteria
+- [ ] **TDD alignment:** packet-level validation commands collectively satisfy the resolved unit/e2e evidence contract, or the plan records a justified exception with replacement evidence
 
 **Validate WHY tracing:**
 
-- [ ] **Each phase has a "Serves:" line** stating which user story aspect or success criterion it delivers
-- [ ] **Success criteria trace to plan-level success criteria** -- task criteria should be decomposed from the plan's success criteria, not invented independently
-- [ ] **No orphan phases** -- every phase should trace to at least one success criterion. If a phase doesn't serve any success criterion, flag it: "Phase [X] doesn't trace to any success criterion. Is it necessary, or is a success criterion missing?"
+- [ ] **Each packet has a purpose line** (`Serves`, `Consumers`, or equivalent) tying it to user story value or explicit downstream unlocks
+- [ ] **Success criteria trace to plan-level success criteria** -- packet criteria should be decomposed from the plan's success criteria, not invented independently
+- [ ] **No orphan packets** -- every packet should trace to at least one success criterion or explicit enabling outcome
+- [ ] **Phase wrappers stay optional** -- if the plan uses phases or tracks, confirm they are grouping containers only and do not replace packet-level tracing
 
-**Expected task format:**
+**Expected packet format:**
 
 ```markdown
-##### Task N.1: [Task Name]
+##### Slice N.1: [Slice Title]
+**Slice type:** tracer-bullet | expansion | hardening
+**Serves:** [Which aspect of the user story / which success criterion this slice delivers]
+**Demo scenario:** [Smallest end-to-end behavior this slice proves]
 **Files:** `path/to/file1.php`, `path/to/file2.php`
-**Depends on:** Task N-1.2 (or "None")
-**Success criteria:**
+**Depends on:** Slice N-1.2 (or "None")
+**Dependency type:** real | stub-available | parallel-safe
+
+###### Scope
+- **Owns:** [What this slice changes]
+- **Non-goals:** [What intentionally waits]
+- **Scope fence:** [Boundary that keeps the slice thin]
+
+###### Acceptance criteria
 - [ ] Criterion 1
 - [ ] Criterion 2
-**Test command:** `command to run`
+
+###### Evidence
+- **Test command:** `command to run`
 ```
 
 **Scoring:**
 
-Count how many implementation tasks have all four fields. Report:
+Count how many execution packets have the full structure. Report:
 
 ```
-Execution Readiness: X/Y tasks have complete structure (Z%)
+Execution Readiness: X/Y packets have complete structure (Z%)
 ```
 
 **Actions based on score:**
 
 | Score | Action |
 |-------|--------|
 | 80-100% | Plan is execution-ready. Proceed with deepening. |
-| 50-79% | Flag incomplete tasks. During deepening, add missing fields. |
-| 0-49% | Plan needs significant restructuring. Add an "Execution Readiness" enhancement pass that decomposes vague phases into structured tasks with all required fields. **Note:** `/workflows-work` will refuse to execute plans that lack this structure. |
+| 50-79% | Flag incomplete packets. During deepening, add missing fields. |
+| 0-49% | Plan needs significant restructuring. Add an "Execution Readiness" enhancement pass that decomposes vague phases/tasks into the packet shape required by the selected mode. **Note:** `/workflows-work` will refuse to execute plans that lack a coherent execution shape unless the user explicitly approves a mode change or legacy adaptation. |
 
-**For tasks missing structure, the deepening process should:**
+**For packets missing structure, the deepening process should:**
 
-1. Break vague phases into specific, scoped tasks
-2. Identify which files each task will create or modify
-3. Write concrete success criteria (not vague goals)
-4. Determine the test command (look at existing test patterns in the codebase)
-5. Make it explicit whether the test command contributes unit evidence, e2e evidence, or both
-6. Map dependencies between tasks
-7. Add a suggested commit message per task (conventional format: `feat(scope): description`)
+1. Pick or confirm the execution shape that best matches the real work
+2. Break vague phases or legacy tasks into specific packets for that mode
+3. Identify the smallest honest outcome each packet proves or unlocks
+4. Identify which files each packet will create or modify
+5. Write concrete success criteria (not vague goals)
+6. Determine the validation command (look at existing test patterns in the codebase)
+7. Make it explicit whether the validation command contributes unit evidence, e2e evidence, or both
+8. Map dependencies between packets
+9. Add a suggested commit message per packet (conventional format: `feat(scope): description`)
 
-### 1.2 Task Complexity Check
+### 1.2 Execution Shape Complexity Check
 
 <thinking>
-Check if any tasks are too large for reliable subagent execution. Large tasks with many files or success criteria should be split.
+Check if any packets are too large, too vague, or shaped incorrectly for reliable subagent execution. Cross-layer work is allowed in `vertical-slices`; the failure mode is not "touches backend and frontend" but "tries to deliver multiple outcomes or no honest outcome at all."
 </thinking>
 
-**For each task, check complexity:**
+**For each packet, check complexity against the selected mode:**
 
 | Metric | Threshold | Action |
 |--------|-----------|--------|
-| Files touched | > 3 files | Flag for splitting |
+| Outcomes or unlocks | > 1 meaningful outcome | Flag for splitting |
+| Files touched | > 6 files | Flag for review; confirm the packet is still thin |
 | Success criteria | > 5 criteria | Flag for splitting |
-| Multiple concerns | Mixes backend + frontend | Flag for splitting |
-| Vague scope | "Implement the feature" | Flag for clarification |
+| Scope fence | Missing or vague | Flag for clarification |
+| Shape fit | `vertical-slices` used for horizontal-only work, or `infra-track` / `fix-batch` used to hide a real feature slice | Reassess mode |
+| Risk controls | `Blast radius: high` with no rollback path | Add safety fields before execution |
+
+**Important:** A packet that touches backend + frontend is **not automatically too large**. If the same thin slice needs a migration, service method, API handler, and tiny UI change to prove one observable behavior, keep it intact.
 
-**If any tasks exceed thresholds:**
+**If any slices exceed thresholds:**
 
 Report:
 ```
-Task Complexity Warning: X tasks may be too large for reliable subagent execution.
+Execution Shape Warning: X packets may be too large or incorrectly shaped for reliable subagent execution.
 
-Task 2.1: "Build user auth" -- touches 5 files, 7 success criteria
-  Suggestion: Split into "Create auth service" (3 files) and "Add auth middleware" (2 files)
+Slice 2.1: "User can complete first login tracer bullet" -- 2 demo scenarios, 7 success criteria
+  Suggestion: Split into "User submits credentials and receives success state" and "User sees first authenticated dashboard shell"
 
-Task 3.2: "Build dashboard UI" -- mixes backend API + frontend component
-  Suggestion: Split into "Create dashboard API endpoint" and "Build dashboard component"
+Packet 3.2: "Create auth schema foundation" -- no demo scenario, horizontal-only outcome
+  Suggestion: Either rewrite as "User can submit credentials and persist the first auth record" or switch this track to `infra-track` if it is truly enablement-only
 ```
 
-Suggest splits that create self-contained tasks with non-overlapping file sets. Each split task should be completable by one subagent in a single session. **When splitting, ensure each new task retains its "Serves:" tracing to the user story -- a split should never orphan a task from its purpose.**
+Suggest splits that create self-contained packets with clear ownership and non-overlapping file sets where possible. **When splitting, ensure each new packet retains its tracing to the user story or enabling outcome.**
 
-**This validation ensures the plan is ready for `/workflows-work`'s subagent orchestration model**, where each task is delegated to a focused subagent with clear scope and termination criteria.
+**This validation ensures the plan is ready for `/workflows-work`'s subagent orchestration model**, where each packet is delegated to a focused subagent with clear scope, proof, and termination criteria.
 
 ### 1.5 Re-fetch Source Documents (if available)
 
@@ -607,7 +633,7 @@ Merge research findings back into the plan, adding depth without changing the or
 - User Story
 - Architectural Context
 - Success Criteria
-- Phase "Serves:" lines
+- Execution shape contract and packet tracing lines
 - Handoff frontmatter
 
 If research suggests changes to these, add a `### WHY Reassessment` note at the end of the plan for the user to review manually. Do not edit the originals.
@@ -622,7 +648,7 @@ If research suggests changes to these, add a `### WHY Reassessment` note at the
 ```markdown
 ## [Original Section Title]
 
-[Original content preserved -- including any "Serves:" lines]
+[Original content preserved -- including any execution-shape and packet tracing lines]
 
 ### Research Insights
 
@@ -664,7 +690,8 @@ At the top of the plan, add a summary section:
 - User Story: [preserved / flagged for reassessment]
 - Architectural Context: [preserved / expanded / flagged for reassessment]
 - Success Criteria: [preserved / flagged for reassessment]
-- Phase tracing: [all phases still trace to user story: yes/no]
+- Execution shape: [preserved / flagged for reassessment]
+- Packet tracing: [all packets still trace to user story or enabling outcome: yes/no]
 
 ### TDD Contract Check
 - Precedence: [plan overrides local / inherit uses local / fallback default noted]
@@ -707,16 +734,17 @@ Before finalizing:
 - [ ] Links are valid and relevant
 - [ ] No contradictions between sections
 - [ ] Enhancement summary accurately reflects changes
-- [ ] Implementation tasks have execution-ready structure (files, success criteria, test commands, dependencies)
-- [ ] TDD contract is explicit, precedence is documented, and unit/e2e evidence stays aligned with task test commands unless an exception says otherwise
+- [ ] Execution packets have execution-ready structure for the selected mode
+- [ ] TDD contract is explicit, precedence is documented, and unit/e2e evidence stays aligned with packet validation commands unless an exception says otherwise
 
 **WHY integrity:**
 - [ ] Problem Narrative, User Story, Success Criteria, and Architectural Context are unmodified from the original plan
 - [ ] Handoff frontmatter is intact and still accurate
-- [ ] Every phase still has its "Serves:" tracing line
-- [ ] No new phases added without a "Serves:" line connecting them to the user story
+- [ ] `execution_shape` frontmatter and `## Execution Shape` still agree
+- [ ] Every packet still has its tracing line
+- [ ] No new packets were added without a tracing line connecting them to the user story or enabling outcome
 - [ ] Enhancements tagged with which success criterion they serve
-- [ ] Scope-expanding recommendations flagged in "Scope Warnings" rather than silently added to phases
+- [ ] Scope-expanding recommendations flagged in "Scope Warnings" rather than silently added to packets
 - [ ] If WHY reassessment was needed, it's in a clearly marked section at the end (not inline edits)
 - [ ] `tdd` frontmatter and `## TDD & Evidence Contract` still agree on precedence, effective loop, evidence, and exceptions
 

.github/skills/orchestrating-swarms/SKILL.md

@@ -28,7 +28,7 @@ Use swarms when the work has real parallelism, specialist boundaries, or depende
 - Keep the team small. Extra workers are justified only when they remove wall-clock time or increase specialist quality.
 
 ### Task design
-- Write tasks as outcomes, not vague topics.
+- Write work items as outcomes, not vague topics.
 - Keep scopes non-overlapping unless the assignment is an explicit cross-check.
 - Prefer DAG-style dependencies over ad hoc sequencing.
 - State what evidence counts as done: files changed, tests run, findings delivered, screenshots captured, or open questions listed.
@@ -42,7 +42,7 @@ Have workers report in a terse, machine-checkable shape:
 - `risks`: unresolved concerns
 
 ### Leader responsibilities
-- Keep the canonical task list and dependency map.
+- Keep the canonical slice/work-item list and dependency map.
 - Resolve blockers instead of letting workers stall silently.
 - Merge duplicate findings and remove contradictory advice.
 - Re-run shared verification after integrating worker output.

.github/skills/setup/SKILL.md

@@ -211,7 +211,7 @@ options:
 - `tdd.evidence.unit`: `required` or `optional`
 - `tdd.evidence.e2e`: `required` or `optional`
 - `tdd.exceptions`: `[]` by default. Plans must carry any justified exceptions.
-- `review_mode`: "bulk" (default), "inline", or "both" (controls per-task review in workflows:work)
+- `review_mode`: "bulk" (default), "inline", or "both" (controls per-slice review in workflows:work)
 
 Write `compound-engineering.local.md`: