---
name: "workflow-cycle-planning"
type: workflow
description: >-
  The cycle-planning workflow — the standing Layer 4 path a cycle boundary flows
  through: Atlas retros the closing cycle, rolls over incomplete work, and
  proposes the opening cycle's commit, with Aled as the gate on cycle membership.
  The planning counterpart to workflow-delivery-loop and
  workflow-venture-operating-loop, read alongside them. Read to see the whole
  cycle-boundary path at a glance, or to render the Layer 4 Workflows layer on
  the agents site. The ceremony itself is the self-contained task
  task-cycle-planning, owned by Atlas.
license: CC BY-NC-SA 4.0
---

# Cycle-planning workflow

The Layer 4 workflow for the planning tier. Where `workflow-delivery-loop` moves a single build ticket from Backlog to Done, and `workflow-venture-operating-loop` moves a vertical toward its mandate outcome, the cycle-planning workflow moves a delivery team across a **cycle boundary** — retro the cycle that is closing, roll over what did not finish, and commit a prioritised next cycle. It composes behaviour from Layers 1–3: Atlas owns the ceremony (`agent-atlas`), and the ceremony itself is the self-contained task `task-cycle-planning`, scheduled to walk the path on a cadence. Aled is the gate — nothing writes cycle membership without his approval.

Read this as a sibling of the other two workflows: same three-tier gate shape (fleet / operator / Owner), one tier over on the planning axis rather than the delivery or venture axis.

## The path

```mermaid
flowchart LR
  BND[Fri 16:00 UK · pre-boundary proposal<br/>boundary resolved from the cycle's endsAt] --> R1[Atlas · retro closing cycle<br/>committed vs completed, milestone movement, goal-review input]
  R1 --> R2[Atlas · roll over<br/>carry / drop / return to Backlog, one reason each]
  R2 --> R3[Atlas · propose next commit<br/>drawn top-down by priority, sized to throughput, tied to initiatives]
  R3 --> G{Owner · gate<br/>approve the commit?}
  G -->|revise| R3
  G -->|approve| W[Write cycle membership<br/>in Aled's session, on his instruction, with the marker]
  W --> AIDE[Aide · books the Owner's slice<br/>of the committed cycle into its hold windows]
```

## Stages

Retro (Atlas) → Rollover (Atlas) → Propose commit (Atlas, propose-only) → Gate (Owner) → Commit write (only on approval) → Handoff to Aide. The first three passes are `task-cycle-planning`. The gate is Aled's. The commit write is made on his explicit instruction in his session, never by the scheduled run (APP-1580, 2026-09-21). The handoff is downstream.

## The gate

**Propose-only on cycle membership is the hard boundary.** Atlas may read cycles, draft the rollover, and post a commit proposal; it may not add, remove, or move cycle membership. Aled approves, and the membership is then written in his session, on his explicit instruction, carrying the `Committed by Aled — <date>`marker that Aide tests. The unattended scheduled ceremony never writes it (Owner, 2026-09-21: *"once I approve, it should be committed"*; APP-1580, APP-1567). This is the delegation clause`task-cycle-planning` always allowed for (a write an agent makes only on the Owner's instruction, with an explicit marker). It is not a reversal of the rejection of autonomous commit. Autonomous commit was considered and rejected (`APP-629`), because an agent deciding the Owner's week's scope is a larger grant than the delivery loop makes anywhere else. This is the planning-tier mirror of the delivery loop's merge gate and the operating loop's mandate-edge gate: unflagged reading and drafting proceed autonomously; the one consequential write waits for the Owner.

## Composition

* **Behaviour + deployment:** `task-cycle-planning` (L2) — the self-contained three-pass ceremony (retro → rollover → propose commit), scheduled on the Cowork/connector surface (Linear only): it resolves the boundary and runs the ceremony in one session, propose-only, delivery teams only. **There is no separate cycle-review skill** — the ceremony is a process you run, not a craft invoked ad hoc, so it is a task, not a skill+loader. This workflow is the path; the task is the inner cycle that walks it.
* **Owning role:** `agent-atlas` (L3) — Atlas runs the ceremony under its live cycle-review/commit slice; the rest of Atlas's composition (initiative shaping, portfolio arbitration) stays future.
* **Retro input — relied on once it has a track record:** `skill-goal-review`'s `[goal-review]` output, read in the retro pass so it reads the cycle against the strategy, not activity alone. It is relied on **only once goal-review has produced a run of summaries** (`task-goal-review`, weekly on trial from 2026-07-21); until then `task-cycle-planning` reads it where one exists and notes its absence otherwise, so the workflow's first live run is not also its dependency's first live run (`APP-630` gate).
* **Context read alongside:** `task-daily-report` and project health.

## Cadence and boundary

Cycles run weekly on every delivery team that has them, resolved live from `convention-linear`'s team table — Apps, A1, MBN and Mr Pritchard (`APP-432`); where this line and that table disagree, the table wins. The ceremony runs **Friday 16:00 Europe/London**, inside `work.Planning`, as a pre-boundary proposal for the next cycle, so the Owner commits before the week starts. Linear's Sunday boundary is left untouched (Owner decision, Aled 2026-09-21, APP-1577). Which team is at a boundary is still resolved from the cycle's `endsAt`, never assumed from the day, since cycle length and start can move. It also runs on demand when Aled asks to review a closing cycle or plan the next one.

## Handoff to Aide

The commit proposal is the input **Aide** (`A1-DE`, `APP-430`) reads to turn Aled's slice of the committed cycle into booked hold-window time. The coupling is load-bearing: an overcommitted cycle propagates straight into an unbookable week (`APP-581` — the committed cycle ran ~1.8× Aide's hold capacity). So the commit is sized to observed throughput in Pass 3, and where the Aled-lane share exceeds his available hold-time the coupling is flagged in the proposal. The fix for the capacity itself sits in Aide; this workflow's job is to surface the coupling, not resolve it. Atlas commits the cycle; Aide books the Owner's slice of it — the split is deliberate.

## Relationship to the task

This workflow is the path; `task-cycle-planning` is the self-contained ceremony that walks it at the boundary. The task sits at Layer 2, the workflow at Layer 4 — the same loop seen from two layers, exactly as `workflow-delivery-loop` relates to `routine-delivery-loop`. The difference from the delivery loop is only surface: cycle-planning is Linear-only, so its Layer 2 artefact is a connector-surface **task**, where the delivery loop's is a repo-surface **routine**.