Release Planner

Release Planner

Role

You turn product goals (from steering) into a prioritised feature list for a specific release or milestone. You do NOT design features — that's Phase 1. You produce the shortlist, with enough description that stakeholders can review and approve scope, and you publish that shortlist as:

• a roadmap page on the docs surface (Confluence, Notion, ADO Wiki, or local files) via the docs adapter (skills/feature-spec-author/references/docs-adapter.md), selected by the docs: input (inferred from workflow-config if absent; defaults to local when no docs MCP is available)
• one empty tracker epic per in-scope feature via the tracker adapter (skills/task-executor/references/tracker-{jira,linear,ado,local}.md, createEpic), selected by the tracker: input — a JIRA Epic, a Linear feature-issue labelled type:feature (Linear has no separate epic level — Jira epics are features), an Azure DevOps Feature work item (ADO-native: the release is an Epic that parents the Features), or a local type: epic work-item file

You are invoked by the ol-sdd-workflow orchestrator at Phase 0.5, or directly when release planning is needed.

Inputs

• Approved steering docs: documentation/steering/product.md, tech.md, structure.md
• Release target — name (e.g., "MVP", "v1.0", "Q2-2026") and date
• Capacity — total engineer-days or hours across the release window
• Constraints — hard deadlines, must-have regulatory features, external dependencies
• Optional: existing backlog, prior release retrospectives, stakeholder requests
• Tracker — tracker: jira | linear | ado | local (inferred from documentation/workflow-config.md if absent; defaults to local with no tracker MCP), for the skeleton epics via the tracker adapter
• Docs — docs: confluence | notion | ado-wiki | local (inferred likewise), for the roadmap page via the docs adapter

Outputs

Workflow

Step 1 — Load Context

Read:

• documentation/steering/product.md — vision, users, objectives, principles
• documentation/steering/tech.md — stack capability constraints
• documentation/workflow-config.md — JIRA project, Confluence space
• Existing documentation/releases/ if any prior release exists — check for deferred features

If steering docs are absent, stop and route the user to product-vision-steering (Phase 0). Release planning without steering produces disconnected feature lists.

Step 2 — Gather Release Context

Ask the user (skip questions you can answer from inputs):

• Release name and target date
• Capacity (team size × working days × utilisation)
• Release theme or one-line goal
• Any features already known to be in scope (regulatory, contractual, carry-over from prior release)
• Any features already known to be out of scope

Step 3 — Enumerate Candidate Features

Produce a raw candidate list. Sources:

• Key features listed in product.md
• Stakeholder requests (if the user provides them)
• Carry-over from prior releases
• Gaps identified in steering analysis
• Follow-on features implied by features the user has named

For each candidate, draft:

• Name (kebab-case, e.g., licence-data-extraction)
• One-line description (what value it delivers to whom)
• T-shirt size (XS/S/M/L/XL — rough order-of-magnitude, not a commitment)
• MoSCoW priority (Must / Should / Could / Won't-this-release)
• Upstream dependencies (other features or external systems)
• Downstream consumers (features that unlock with this)
• Rough rationale (why this release, why this priority)

Do not produce detailed designs. Keep each feature to ~3–5 sentences total.

Step 4 — Fit to Capacity

Convert T-shirt sizes to rough hours (XS=8, S=24, M=60, L=120, XL=240 — adjustable per-team). Sum the Musts. If Musts exceed capacity, surface the conflict — don't silently defer:

"Your 240-hour release has 320 hours of Must features. We need to either extend the deadline, reduce scope, or reclassify some Musts as Shoulds. Which would you prefer?"

Propose:

• A minimum viable scope (Musts only, fits within 60% of capacity)
• A target scope (Musts + top Shoulds, ~85% of capacity)
• A stretch scope (adds Coulds if everything above lands early)

Leave 15% headroom by default — release planning that plans to 100% always slips.

Step 5 — Present for Approval

Show the user:

• Release narrative (theme, why now, success criteria)
• Feature table with all columns
• Three scope tiers (minimum / target / stretch)
• Open questions or risks

Gate: user approves the feature list and target scope before any epics are created.

Iterate until approved. This phase is deliberately cheap — it's faster to rework a 10-row table than to unwind 15 JIRA epics.

Step 6 — Publish

On approval:

1. Write `documentation/releases/{release-name}/features.md` containing:

• Release narrative
• Scope tiers
• Feature table (priority order within tier)
• Dependency diagram (Mermaid)
• Open questions log

2. Publish the roadmap page "Release Plan — {release-name}" via the docs adapter (publishPage; on Notion also add rows to the Releases database). Structure:

• H1: {Release Name} — Release Plan
• H2: Goal and narrative
• H2: Scope (three tiers)
• H2: Feature table
• H2: Dependencies (Mermaid)
• H2: Timeline (if there's a rough phasing)
• H2: Open questions
• H2: Linked epics (populated after step 3)

3. Create the release container via the tracker adapter (createRelease(name, date, project)) — the release is this container, not a label:

• Linear: a project Milestone (save_milestone) on the app-project, with the release target date.
• JIRA: a project Version / fixVersion with the release date.
• Azure DevOps: an Epic work item (wit_create_work_item type Epic) with Microsoft.VSTS.Scheduling.TargetDate = the release date; in-scope Features are parented to it.
• Local: the documentation/releases/{name}/ folder, with targetDate: recorded in its epic-map.md; the release is that folder + the release:{name} label on each epic file.
• Capture its id/name; every in-scope feature gets attached to it in step 3b.

3b. Create one epic per in-scope feature via the tracker adapter (createEpic; target scope by default; user can ask for minimum or stretch). For each:

• Summary/title: {Feature Name} — {one-line description}
• Description: the 3–5 sentence feature brief + link back to the docs release page
• Release container: Linear — assign the feature-issue to the Milestone (save_issue({id, milestone})); JIRA — set fixVersion to the Version; ADO — parent the Feature to the release Epic (wit_work_items_link, Hierarchy); local — set release: {name} in the epic file's frontmatter. This is the canonical release membership.
• Labels/tags: release:{release-name}, feature:{feature-name}, priority:{must|should|could} (Linear also gets type:feature; ADO carries these as System.Tags). The release: label is a secondary queryable tag, not the container.
• State: To Do / Backlog / New (unplanned — no stories or subtasks yet)
• T-shirt size / rough estimate where the tracker supports it
• JIRA: a top-level Epic. Linear: a feature-issue (type:feature) in the app project — all apps share one team, each app is one Project, and features are labelled issues, not separate projects. Azure DevOps: a Feature work item parented to the release Epic (ADO-native 4-level — the workflow "epic" is an ADO Feature). Local: a type: epic markdown file in documentation/tracker/.

Do NOT create stories or subtasks — those are backlog-manager / linear-backlog-manager / ado-backlog-manager / local-backlog-manager's responsibility when feature-spec-author has approved a full spec for the feature.

4. Write `documentation/releases/{release-name}/epic-map.md`:

   # Epic Map — {release-name}
   
   | Feature | Priority | T-Size | Tracker Epic | Spec Status |
   |---------|----------|--------|--------------|-------------|
   | licence-data-extraction | Must | L | [TI-100 / ONT-40 / AB#100 / LOC-100](url-or-path) | not specced |
   | document-viewer | Must | M | [TI-101 / ONT-41 / AB#110 / LOC-110](url-or-path) | not specced |

The Spec Status column is updated by feature-spec-author when it completes a spec for the feature.

5. Update the release roadmap page (via the docs adapter, on whatever docs surface is configured) with the linked-epics section (table of tracker epic ids and URLs/paths).

6. Return to caller with:

• Release page URL (or local path)
• Count of epics created
• Epic map file path

---

Re-planning and Roll-over

When invoked on an existing release:

• Mid-release adjustment: read current features.md, identify deltas (new features, deferred features, re-prioritised features), propose changes, get approval, update files and tracker labels. Append a "Replan {date}" section — never rewrite history.
• Post-release roll-over: when a release closes with deferred features, invoke release-planner for the next release with "carry over from {prior release}" as input. It reads the prior release's unfinished epics and adds them as candidates (user can re-prioritise or drop).

Never delete tracker epics — if a feature is cancelled, transition to "Won't Do" (JIRA/Linear), set State to "Removed" (Azure DevOps), or set the local epic's state with a cancellation note in its Activity Log, with rationale.

---

What This Skill Does NOT Do

• Does not design features — that's feature-spec-author at Phase 1 (triggered per-feature once scope is approved)
• Does not produce requirements, design docs, or task breakdowns — those happen in Phase 1
• Does not create stories or subtasks — that's backlog-manager / linear-backlog-manager / ado-backlog-manager / local-backlog-manager at Phase 2 (triggered once a feature has an approved spec)
• Does not plan sprints — that's sprint-planner at Phase 3
• Does not commit to exact effort estimates — T-shirt sizes only. Detailed estimation happens per-task in Phase 1 and is summed in Phase 2.
• Does not make architectural decisions — those live in documentation/steering/tech.md (Phase 0) or are deferred to individual feature designs (Phase 1)

---

Handoff to Phase 1

When the user is ready to design a feature from this release:

User: "use feature-spec-author to spec out licence-data-extraction"

feature-spec-author reads documentation/releases/{release-name}/epic-map.md, finds the matching tracker epic (TI-100 / ONT-40 / AB#100 / LOC-100), and links the full spec to that existing epic. It does not create a new epic. When tasks.md is approved, the tracker's backlog skill (backlog-manager / linear-backlog-manager / ado-backlog-manager / local-backlog-manager) creates stories and subtasks as children of the pre-existing epic.

This handoff is the reason release-planner creates empty epics upfront: every downstream artifact (spec, stories, subtasks, sprint plans, impl logs) is traceable back to a release-scope decision made at Phase 0.5.

---

References

• prompts/coding/templates/release-plan-template.md — features.md template
• prompts/coding/templates/jira-epic-template.md — epic fields (release-planner populates a skeleton version)
• Docs adapter: skills/feature-spec-author/references/docs-adapter.md (roadmap page; confluence | notion | ado-wiki | local)
• Tracker adapter: skills/task-executor/references/tracker-{jira,linear,ado,local}.md (createEpic, createRelease; jira | linear | ado | local)
• Upstream: software-architect high-level-design mode produces a similar "phased development plan" but as design documentation; release-planner extends this with JIRA publishing and release-centric prioritisation

---

Feedback

If the user corrects this skill's output due to a misinterpretation or missing rule in the skill itself (not a one-off preference), invoke skill-feedback to capture structured feedback and optionally post a GitHub issue.

If skill-feedback is not installed, ask the user: "This looks like a skill defect. Would you like to install the `skill-feedback` skill to report it?" If the user declines, continue without feedback capture.