agentsclimarketplace

Pm release plan

Skill julianoczkowski/product-manager/skills/pm-release-plan

Turn a prioritized set of requirements into a committed Pragmatic release plan — themed, sized, and signed. Use when the PM asks to plan a release, define MVP scope, commit a date, build a release charter, or "what goes in this release". Covers MVP done right, themes, the estimation ladder, the market window, and the scope/schedule/resources change levers. Produces a Release Charter as a Markdown or Word .docx artifact.From its SKILL.md

Install
npx -y skills add julianoczkowski/product-manager --skill pm-release-plan

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

SKILL.md

5.0 KB, ~1.1k tokens by cl100k_base, as published. Nobody here has run it

Release Plan / Charter (Pragmatic Framework: Roadmap → Release)

The roadmap drives the release plan. A roadmap is a plan, not a commitment; a release charter is a signed agreement of what will be delivered. See ../pm-copilot/references/framework.md.

MVP, done right: "the version of a new product that allows a team to collect the maximum validated learning with the least effort." An MVP is not the smallest collection of features — it must be a real product that viably solves the customer's top problems from day one. Calling a finished "V1.0" an MVP is a waterfall relapse.

Core methods

Group requirements into Themes. A theme groups prioritized problems that share a persona, a product goal, a technical decision, a strategy, roadmap alignment, or a target metric. Themes make a release remarkable and coherent.

Rule: Deliver 100% of something, not 70% of everything.

Shape the release by three dimensions per theme/requirement: Size · Difficulty · Confidence. Reduce big items by splitting problems.

Estimation ladder (confidence grows with detail): Release → T-shirt sizes (S/M/L) → Iteration → story points → Day → daily updates. Product management is available to answer questions at every step. The dev team makes the final estimate.

Market Window & schedule direction: On a date-driven release, development works TO a date (iterating toward the window); Marketing, Sales and Operations work backward FROM it. On a content-driven release there is no committed date — define the exit criteria that trigger launch instead, and the go-to-market clock starts when they're met.

Change levers (iron triangle): Scope · Schedule · Resources. Decide up front which one drives the plan and how you'll absorb change.

Interview the user (batch questions)

  1. Product, version, project name.
  2. Release theme(s) — the unifying message (persona goals / major capability / set of problems).
  3. Which prioritized requirements are in scope? (pull from an existing MRD/PRD if present)
  4. Date-driven or content-driven? Is this release driven by a target date / market window, or by content (it ships when the themes are done)? Both are equally valid. Only if date-driven: what is the target date or market window? "There is no date" is a legitimate answer — that's a content-driven release, not a missing input.
  5. Major milestones — code complete, beta, final QA, release to production, GA.
  6. Change lever — will Scope, Schedule, or Resources flex when reality hits?

Artifact template — Release Charter

# Release Charter — <Product> <Version>

**Company:** <company>  ·  **Feature / Product:** <name>
**Author:** <author>  ·  **Date created:** <date>  ·  **Version:** <version>
**Project Name:** <project>   **Release Theme:** <theme>
**Schedule:** <date-driven: <target date / market window> · or content-driven: ships when <exit criteria> are met>

## Themes
- **<Theme 1>** — <what it delivers and why (persona/goal/strategy it serves)>
- **<Theme 2>** — <…>

## Deliverables (what we have agreed to deliver)
Based on requirements document **<MRD/PRD name + version>**.
### <Theme 1 / Group name>
- <requirement / capability>  — size: <S/M/L>, confidence: <low/med/high>
- <requirement / capability>
### <Theme 2 / Group name>
- <requirement / capability>

### Major milestones
| Milestone | Target date |
| :--- | :--- |
| Code complete | |
| Beta release | |
| Final QA | |
| Release to production | |
| General availability (GA) | |

## Change plan
| Driver | What will drive the plan? | How will you deal with change? |
| :--- | :--- | :--- |
| Scope | | |
| Schedule | | |
| Resources | | |

## Signatures
*This document lists what we have agreed to deliver. By signing below, I acknowledge
that this is the current plan and that I will inform product management and project
management if the plan changes.*

| Name | Title | Date | Signature |
| :--- | :--- | :--- | :--- |
| | Product Manager | | |
| | Project Manager | | |
| | Development Manager | | |
| | QA Lead | | |

Deliver the artifact

Follow ../pm-copilot/references/artifact-output.md: confirm inputs, ask Markdown or .docx, write the .md, convert to .docx on request via your environment's native document-creation capability. Then offer the next stage: set up pm-stakeholder-communication to report status against this charter, and pm-launch-plan to prepare go-to-market for the target window.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most plan spec skills give in ~1.1k tokens

Counted across 1,360 of the 2,617 authors here whose files we hold, read 2026-09-06

  • Ask one question at a timein 73 of 1360
  • Write the spec using the templatein 22 of 1360
  • Ask clarifying questions if neededin 19 of 1360, across 18 files
  • Wait for user confirmation before proceedingin 19 of 1360
  • Save plans to the plans directoryin 17 of 1360, across 13 files
  • Check for product marketing context firstin 16 of 1360, across 5 files
  • Read the plan file completelyin 16 of 1360
  • Order tasks by dependencyin 16 of 1360
  • Gather context from the conversationin 15 of 1360, across 9 files
  • Explore the codebase instead of askingin 15 of 1360, across 13 files
  • Wait for explicit user approvalin 14 of 1360, across 13 files
  • Quiz the user on the breakdownin 13 of 1360, across 7 files

Said here and by no other author read

  • Interview the user with batch questions
  • Group requirements into themes
  • Deliver 100% of something
  • Produce a release charter artifact

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.