| name | calendar-dag-scheduler |
| description | Use when today's real calendar availability needs to become a concrete ticket execution calendar backed by the issue-tracker dependency graph. |
Calendar DAG Scheduler
Use this skill when the question is:
- which ticket goes in which time block today
- how do we turn free windows into real execution blocks
- how do we respect dependencies instead of scheduling fantasy work
- how do we place grouped review and patch blocks into the day
This skill is the calendar-writing planner.
It does not itself decide ticket state transitions in the configured issue_tracker.
It hands those tickets to linear-day-allocator.
Inputs to gather first
- local date and timezone
- today's
calendar_provider events
- today's free windows
- candidate child issues from the active
issue_tracker project
- parent/child relationship data
- dependency graph or blocker graph
- current issue state counts
- parallelism posture for the day
- any fixed review windows or meetings
Start by reading:
../ticket-day-operator/SKILL.md../parallel-lane-orchestrator/SKILL.md../review-batch-orchestrator/SKILL.md
Use the configured calendar_provider and issue_tracker adapters. Examples include Google
Calendar or Outlook Calendar for calendar_provider, and Linear, Jira, GitHub Issues, or
Shortcut for issue_tracker.
Goal
Produce one calendar-backed execution map for the current day:
- real free windows only
- one dependency-ready ticket or one explicit grouped block per window
- independent work scheduled in parallel where possible
- shared review and patch windows scheduled intentionally
Workflow
1. Read calendar truth
- fetch all remaining events for the local day
- compute real free windows
- identify hard blocks versus movable holds
Rules:
- do not plan over existing hard commitments
- do not assume a fake 16-hour day if Calendar says otherwise
- preserve transition time around meetings when the day is fragmented
2. Filter the board to schedulable child work
- exclude parent issues
- exclude tickets blocked by unresolved upstream dependencies
- exclude tickets whose remaining work is too discovery-heavy for today's schedule
- include grouped review or patch blocks when the DAG says multiple tickets should converge
For each candidate, capture:
- ticket id
- state
- parent
- blockers
- likely effort
- unlock value
- whether it can run in parallel
3. Build execution waves from the DAG
Create one or more waves:
- Wave A: dependency-ready execution tickets
- Wave B: grouped review block for Wave A
- Wave C: patch and re-review tickets only if review is expected to surface findings
- later waves only if calendar capacity remains
Rules:
- do not place a downstream ticket before its blocker-clearing ticket
- parallelize only tickets that do not compete for the same critical file surface or runtime resource
- reserve at least one block for grouped review if multiple tickets are expected to hit review together
4. Map waves into calendar blocks
For each free window, assign exactly one of:
- one execution ticket
- one grouped review block
- one grouped patch block
- one replanning block if the day is highly uncertain
Rules:
- calendar titles must be legible and operator-facing
- include ticket ids directly in the block title when one ticket owns the block
- grouped blocks must name the wave and the participating tickets
- update an existing same-day block instead of duplicating it
5. Write the calendar plan
Create or update calendar blocks for the day.
Each block should carry:
- ticket id or grouped block label
- planned lane or wave
- intended outcome for the block
- any dependency note if relevant
Close rule
This skill is complete only when:
- today's free windows were read from Calendar
- only dependency-ready child work was scheduled
- the day has explicit execution and review structure
- Calendar was updated or an auth blocker was surfaced honestly
