Delivery High Level Plan

Delivery High-Level Execution Plan

Purpose / When to Activate

Owner: Planning Sub-Agent. Not invoked directly by the Delivery Orchestrator.

Used by the Planning Sub-Agent as:

• The sole planning output for Tier 1 (MicroDelivery) when a brief plan is sufficient
• The first planning pass before prepare-execution-plan is invoked for Tier 2/3 Stories

Do NOT activate if Stories are unclear, acceptance criteria are missing, or product scope is still evolving.

Process

CRITICAL — Anti-Collision Guard (MUST execute before writing any output file): Before writing contexts/artefacts/plans/{id}.plan.md, check if the target file already exists on disk:

• If it does NOT exist → proceed normally.
• If it DOES exist → read the existing file first. Then decide:
  • If the existing content is from a different entity (different story ID, different epic) → STOP immediately, surface the ID collision to the human, do not proceed.
  • If the existing content is from the same entity and an update is warranted → proceed, but preserve any human edits or prior findings that remain relevant. Treat this as an update, not a replacement.
  • If the existing content is identical or still valid → skip writing, report "no changes needed". This guard prevents the silent data loss incident of 2026-03-17 where concurrent sessions overwrote story files.

1. Load only relevant memory and rules
2. Read each Story and acceptance criteria fully
3. Identify required behavior and boundaries
4. Break work into minimal execution steps
5. Surface dependencies and risks
6. Avoid premature optimization or over-engineering
7. Produce a clean, high-signal plan

Outputs

Execution Plan — Story <ID>

Objective:
<what must be achieved exactly>

Steps:
1. <clear action> — purpose
2. <clear action> — purpose
3. <clear action> — purpose

Dependencies:
- <if any>

Risks / Constraints:
- <if any>

Validation Gates:
- acceptance criteria covered: yes | no
- rules compliant: yes | no

Saves to contexts/artefacts/plans/{id}.plan.md.

For Tier 2/3: this output feeds directly into prepare-execution-plan for file-level decomposition.

Mandatory Delivery Sequence (Non-Negotiable)

Every plan produced by this skill MUST include the following steps in this order as the final phase of any delivery:

... → create/reuse exact PR → persist pending_review → ci-watch-and-fix
        → WAIT: observe without mutation
        → QUALIFIED: hold for external merge
        → REMEDIATE: bounded fix, fresh admission and exact publication binding
        → BLOCKED: preserve state and escalate without retry or mutation
        → external exact-current merge → watcher projects done → cleanup

• ci-watch-and-fix is always mandatory — it is never optional.
• The plan must persist pending_review immediately after exact PR/head/base binding and before hosted observation.
• QUALIFIED is not merge permission and must not mark the Story done. Only the configured-target watcher may project done after verifying an external exact-current merge.
• WAIT and BLOCKED do not consume remediation or mutate the candidate. REMEDIATE is allowed only for the authoritative selected attempt's completed aggregate failure.

Turn budget note: A 3-cycle CI remediation loop can consume ~60–90 tool turns. Plans for complex stories should reserve turn budget for CI remediation. Combined implementation + CI remediation should target under 150 turns out of the daemon's 200-turn budget.

Quality Checks

• Every acceptance criterion maps to at least one step
• No rule is violated
• Scope is unchanged from the Story
• Dependencies are explicit
• Nothing ambiguous remains
• Mandatory delivery sequence (exact PR binding → pending_review → ci-watch-and-fix → external exact-current merge → watcher projection → cleanup) is present in every plan

Non-Goals

This skill must NOT:

• Redefine product scope
• Add new features
• Make architectural decisions beyond stated constraints
• Start coding
• Bypass rules

A good execution plan makes coding boring. Boring is reliable. Reliable scales.