Utility Pm Workflow Builder

<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->

PM Workflow Builder

This skill creates new multi-skill workflows for the pm-skills library. It produces a Workflow Implementation Packet - a draft _workflows/<name>.md file, a draft commands/workflow-<name>.md command, and the cross-cutting update checklist - in a staging area for review before promotion to canonical locations. The builder authors; it never executes a chain and it never promotes its own output.

When to Use

• You have an idea for a new multi-skill workflow ("I need a workflow for

quarterly business reviews")

• You know the skills you want to chain and want them captured durably

("chain competitive-analysis, experiment-results, pivot-decision")

• A /chain run (orchestrator Mode B) proved reusable and its completion

output suggested promoting the chain to a durable workflow; hand this skill the exact chain expression from that suggestion

When NOT to Use

• To run a sequence once without authoring anything -> use the /chain

command or utility-pm-workflow-orchestrator directly

• To build or modify a single skill -> use utility-pm-skill-builder,

utility-pm-skill-validate, or utility-pm-skill-iterate

• To customize an existing workflow -> edit its _workflows/<name>.md

directly; the overlap analysis below will point you there when coverage is high

Instructions

Step 1: Understand the Idea

Accept the idea in any of three entry forms, all converging on the same downstream flow:

• Problem-first: "I need a workflow for X." Identify the recurring PM

process, who runs it, and the artifact trail it should leave.

• Skills-first: a list of skills the user already wants to chain.
• Chain-promotion: a literal chain expression (for example

measure-experiment-results -> discover-stakeholder-summary), usually pasted from the orchestrator's completion suggestion, plus the context the run used.

If the idea is vague, ask ONE clarifying question (the recurring trigger and the final artifact), then proceed. Do not interrogate.

Step 2: Overlap Analysis + Why Gate

Scan the _workflows/ directory at run time for the current inventory (list every *.md except README.md). Never rely on a remembered count or a hardcoded list. Compare the idea against ALL existing workflows:

• Name each overlapping workflow and what it covers.
• Estimate coverage overlap honestly.

Kill gate (>70% coverage overlap): recommend, in order, (a) customizing the existing workflow, (b) adding a step to it, or (c) just using /chain for the occasional run. Do not proceed.

Why Gate (any meaningful overlap): ask for 2-3 specific scenarios where the existing workflows fail to produce what is needed. Do not pass the gate without that evidence or an explicit user override (record the override in the packet's Decision section).

Step 3: Sequence Design

Select and order the steps with the user. Apply the chain-expression contract's validation rules at authoring time (skills/utility-pm-workflow-orchestrator/references/PARSE-CONTRACT.md, Mode B Chain Expression Contract):

• Every step must resolve to an installed skill at skills/<name>/SKILL.md

by EXACT name. Never approximate or auto-correct; on a miss, refuse the step and OFFER the closest real names (an offer, never a substitution).

• Category 1 content skills only. Refuse as steps, each with a one-line

explanation: Tier-3 maintenance skills (utility-pm-skill-*, utility-pm-release-conductor, utility-pm-changelog-curator, utility-update-pm-skills, foundation-prioritized-action-plan), dispatch skills that fan out to sub-agents (utility-pm-critic, utility-pm-workflow-orchestrator, and peers), and existing workflows (a workflow never nests a workflow). Self-reference is impossible by construction: this builder is itself Tier-3.

• For EACH step, author the handoff: what the step consumes from the prior

step's output, and what it must produce for the next. This authored handoff guidance is exactly what distinguishes a durable workflow from an ad-hoc chain; a packet without real handoffs is not ready.

Step 4: Generate the Packet

Write the complete Workflow Implementation Packet to _staging/workflows/<name>/ (gitignored; the same review model as the skill builder). Never write to canonical locations.

_staging/workflows/<name>/
├── workflow.md      <- draft _workflows/<name>.md
├── command.md       <- draft commands/workflow-<name>.md
└── PACKET.md        <- decision, overlap analysis, checklist, promotion steps

Use references/TEMPLATE.md as the packet format. The workflow draft must carry the full section inventory the current _workflows/*.md files share (see the TEMPLATE's embedded skeleton); the command draft mirrors the existing commands/workflow-*.md shape, including one literal skills/<name>/SKILL.md path per step and the $ARGUMENTS footer. Derive a linear mermaid context-flow diagram from the final sequence (step names as nodes, execution order as edges).

Step 5: Review + Promotion Guidance

Present the packet and stop. The builder itself never promotes. On approval, the user (or a follow-up session) moves the drafts to their canonical paths and works the packet's Cross-Cutting Checklist, which names every count and documentation surface that adding a workflow trips, including the validator-blind .github/workflows/release.yml release-note template. The builder never edits those cross-cutting files itself.

Output Format

The packet follows references/TEMPLATE.md:

1. Decision - recommendation plus Why Gate evidence (or the recorded override) 2. Overlap Analysis - every overlapping workflow, what it covers, the gap 3. Workflow Draft - complete _workflows/<name>.md content 4. Command Draft - complete commands/workflow-<name>.md content 5. Cross-Cutting Checklist - every surface to update at promotion, with its enforcing validator (or "validator-blind" where none exists) 6. Promotion Steps - the move-verify-validate sequence

See references/EXAMPLE.md for one complete worked packet.

Quality Checklist

Before presenting the packet, verify:

• [ ] Overlap analysis scanned the live _workflows/ directory (no remembered list, no hardcoded count)
• [ ] Why Gate evidence is specific (named scenarios) or an explicit override is recorded
• [ ] Every step resolves to an installed skill by exact name
• [ ] No Tier-3 maintenance skill, dispatch skill, or workflow appears as a step
• [ ] Every step has an authored handoff (consumes / produces), not just a skill name
• [ ] The workflow draft carries every section in the TEMPLATE's skeleton (metadata table, When to Use with Do NOT use, per-step blocks, context-flow diagram, tips, quality checklist, see also)
• [ ] The command draft names each step's skills/<name>/SKILL.md path and ends with the $ARGUMENTS footer
• [ ] The mermaid diagram matches the final sequence exactly
• [ ] Everything written under _staging/workflows/<name>/; no canonical path touched
• [ ] The Cross-Cutting Checklist is reproduced in full, including the .github/workflows/release.yml release-note row

Reference Files

• Packet template: references/TEMPLATE.md
• Worked example (quarterly business review): references/EXAMPLE.md
• Chain-expression contract applied at authoring time: `skills/utility-pm-workflow-orchestrator/references/PARSE-CONTRACT.md`
• Workflow exemplars: `_workflows/sprint-planning.md`, `_workflows/customer-discovery.md`
• Command exemplar: `commands/workflow-sprint-planning.md`
• Sibling builder for single skills: `skills/utility-pm-skill-builder/SKILL.md`

<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->

Workflow Implementation Packet: quarterly-business-review

Produced by utility-pm-workflow-builder. Everything below is a DRAFT in

_staging/workflows/quarterly-business-review/; nothing has been written to

a canonical location. A human reviews, promotes, and works the checklist.

Decision

Build it. Recommend creating the quarterly-business-review workflow. The Why Gate fired (the idea overlaps Post-Launch Learning and Stakeholder Alignment) and was passed with three specific scenarios where existing workflows fail:

1. "Prep the Q3 QBR for the payments platform" needs the quarter's experiment evidence AND a stakeholder map AND meeting materials in one pass; running Post-Launch Learning gets the evidence but stops before any stakeholder or meeting artifact exists. 2. "Our QBR pre-read goes out 48 hours before the meeting" requires a written async update as a distinct artifact; Stakeholder Alignment produces a problem case for buy-in, not a recurring results communication. 3. "New VP joined; reset who attends and what they care about" needs the stakeholder map refreshed each quarter as a first-class step, which no existing workflow sequences with results synthesis.

• Workflow name: quarterly-business-review (file: _workflows/quarterly-business-review.md)
• Command: /workflow-quarterly-business-review (file: commands/workflow-quarterly-business-review.md)
• Steps: measure-experiment-results -> discover-stakeholder-summary -> foundation-stakeholder-update -> foundation-meeting-agenda
• Entry form: chain-promotion. Originating chain expression, pasted from the orchestrator's completion suggestion: measure-experiment-results -> discover-stakeholder-summary -> foundation-stakeholder-update -> foundation-meeting-agenda with context "Q3 QBR for the payments platform team".

Overlap Analysis

Scanned the live _workflows/ directory (twelve files at scan time; the scan, not this packet, is authoritative). Meaningful overlaps:

The gap: a recurring, evidence-first communication loop that ends in meeting materials. No existing workflow sequences results synthesis into stakeholder mapping into an async pre-read into an agenda.

Workflow Draft

The complete draft of _workflows/quarterly-business-review.md:

---
title: Quarterly Business Review
---

# Quarterly Business Review Workflow

> **Turn a quarter of experiment evidence into a stakeholder-ready QBR: results, who cares, the pre-read, and the meeting agenda.**

---

## Workflow Metadata

| Field | Value |
|-------|-------|
| **Workflow** | Quarterly Business Review |
| **Command** | `/workflow-quarterly-business-review` |
| **Skills** | `measure-experiment-results` -> `discover-stakeholder-summary` -> `foundation-stakeholder-update` -> `foundation-meeting-agenda` |
| **Phases Covered** | Measure, Discover, Foundation (cross-cutting) |
| **Estimated Duration** | 2-3 hours |
| **Prerequisite Inputs** | The quarter's experiment data or dashboard exports; the attendee list or org context for the review |
| **Final Output** | Results synthesis, refreshed stakeholder map, async pre-read update, and a time-boxed QBR agenda |

---

## When to Use This Workflow

Use the Quarterly Business Review workflow when:

- A recurring business review is coming up and the quarter's evidence needs to become decision-ready materials
- Leadership attendance or priorities shifted and the stakeholder picture needs a refresh before you communicate results
- You want the pre-read and the meeting agenda to tell the same story as the underlying data

**Do NOT use this workflow when:**

- You are mid-quarter and only need one experiment written up (use the `measure-experiment-results` skill directly)
- You are building a case for a specific decision rather than reviewing a period (use [Stakeholder Alignment](stakeholder-alignment.md))
- You want the team-internal learning loop after a launch (use [Post-Launch Learning](post-launch-learning.md))

---

## Workflow Steps

### Step 1: Experiment Results

**Skill:** [`measure-experiment-results`](../skills/measure-experiment-results/SKILL.md)

**What you do:** Compile the quarter's experiments into a single results synthesis: what ran, what moved, what was learned, and what it implies for next quarter's bets.

**Input requirements:**

- Experiment readouts, dashboard exports, or metric snapshots for the quarter
- The quarter's stated goals or OKRs for framing

**Output:** A results document with per-experiment outcomes and a quarter-level summary of wins, misses, and learnings.

**Handoff to next step:** The quarter-level summary (especially the misses and the asks they imply) tells the next step which stakeholders have skin in the game this cycle.

---

### Step 2: Stakeholder Summary

**Skill:** [`discover-stakeholder-summary`](../skills/discover-stakeholder-summary/SKILL.md)

**What you do:** Refresh the stakeholder map for this review cycle: who attends or reads, their influence and interest, what each cares about in this quarter's results, and any new players since last quarter.

**Input requirements:**

- The results summary from Step 1
- Attendee list, org chart context, or notes on recent leadership changes

**Output:** A stakeholder summary with influence/interest levels and per-stakeholder concerns tied to this quarter's outcomes.

**Handoff to next step:** The per-stakeholder concerns decide the pre-read's emphasis and translations; the audience mix (engineering vs leadership vs mixed) selects the update's audience variant.

---

### Step 3: Stakeholder Update

**Skill:** [`foundation-stakeholder-update`](../skills/foundation-stakeholder-update/SKILL.md)

**What you do:** Write the async pre-read that goes out before the meeting: the quarter's results translated for the mapped audience, with the primary call to action (decisions needed at the QBR) up front.

**Input requirements:**

- Results synthesis from Step 1
- Stakeholder map from Step 2 (audience variant and emphasis)
- The channel the pre-read ships on (email, Notion, exec memo)

**Output:** A channel-ready pre-read update with the CTA, results narrative, and per-audience translations.

**Handoff to next step:** The decisions the pre-read asks for become the agenda's Decision topics; everything already answered in the pre-read stays OUT of the meeting and frees agenda time.

---

### Step 4: Meeting Agenda

**Skill:** [`foundation-meeting-agenda`](../skills/foundation-meeting-agenda/SKILL.md)

**What you do:** Build the time-boxed QBR agenda (stakeholder-review or exec-briefing variant): decision topics from the pre-read's asks, discussion topics from the open misses, owners, and attendee prep pointing at the pre-read.

**Input requirements:**

- The pre-read from Step 3 (its CTA list becomes the Decision topics)
- Meeting length and attendee list

**Output:** An attendee-facing agenda with time-boxed, type-tagged topics and prep expectations.

---

## Context Flow Diagram

graph LR A["measure-experiment-results"] --> B["discover-stakeholder-summary"] B --> C["foundation-stakeholder-update"] C --> D["foundation-meeting-agenda"]

---

## Tips and Variations

**Recurring use:** Keep last quarter's packet beside this one; Step 2 starts from the previous map and only refreshes deltas, which cuts the run to about an hour.

**Lightweight version:** When the audience is unchanged since last quarter, skip Step 2 and reuse the prior stakeholder summary; the pre-read still consumes the fresh Step 1 results.

**Enhanced version:** Add `foundation-meeting-recap` after the QBR itself, then `iterate-lessons-log` for commitments made in the room; that closes the loop into next quarter's evidence base.

**Team collaboration:** Run Step 1 with the data owner, Steps 2-3 solo, and circulate the Step 3 pre-read for comment before locking the Step 4 agenda.

---

## Quality Checklist

Before considering this workflow complete, verify:

- [ ] Every experiment in the quarter appears in the Step 1 synthesis with an outcome (no silent omissions)
- [ ] The stakeholder map reflects THIS cycle's attendees, not last quarter's copy
- [ ] The pre-read's primary CTA states the decisions needed at the QBR, above the results narrative
- [ ] Agenda Decision topics match the pre-read's asks one-to-one
- [ ] Material already answered in the pre-read does not reappear as meeting discussion time

---

## See Also

- [Post-Launch Learning](post-launch-learning.md) - the team-internal learning loop after a single launch
- [Stakeholder Alignment](stakeholder-alignment.md) - building a buy-in case for one specific decision

---

*Part of [PM-Skills](../README.md) - Open source Product Management skills for AI agents*

Command Draft

The complete draft of commands/workflow-quarterly-business-review.md:

---
description: Run the Quarterly Business Review workflow (experiment-results -> stakeholder-summary -> stakeholder-update -> meeting-agenda)
---

Run the Quarterly Business Review workflow to turn a quarter of evidence into stakeholder-ready review materials.

This workflow uses multiple skills in sequence. For each step, read the skill instructions and follow them to create the artifact.

## Workflow Steps

### Step 1: Experiment Results

Use the `measure-experiment-results` skill from `skills/measure-experiment-results/SKILL.md`.

Compile the quarter's experiments into one results synthesis with wins, misses, and learnings.

### Step 2: Stakeholder Summary

Use the `discover-stakeholder-summary` skill from `skills/discover-stakeholder-summary/SKILL.md`.

Refresh the stakeholder map for this review cycle from the results and the attendee context.

### Step 3: Stakeholder Update

Use the `foundation-stakeholder-update` skill from `skills/foundation-stakeholder-update/SKILL.md`.

Write the async pre-read for the mapped audience with the decisions needed up front.

### Step 4: Meeting Agenda

Use the `foundation-meeting-agenda` skill from `skills/foundation-meeting-agenda/SKILL.md`.

Build the time-boxed QBR agenda from the pre-read's asks and the open discussion items.

## Output

Create all four artifacts in sequence, ensuring each builds on the previous.

Reference the Quarterly Business Review workflow at `_workflows/quarterly-business-review.md` for additional guidance.

Context from user: $ARGUMENTS

Cross-Cutting Checklist

Adding this workflow trips every surface below. Work each row at promotion; the right column names the validator that catches a miss, and the rows marked validator-blind have NO net: this checklist is the only control.

• [ ] _workflows/quarterly-business-review.md created - check-workflow-generator-coverage (enforcing); gen-site.mjs emits the site page automatically (Pattern S: no hand-authored docs page)
• [ ] commands/workflow-quarterly-business-review.md created - validate-commands (enforcing)
• [ ] AGENTS.md workflows section + command list updated - validate-agents-md, check-agents-md-command-sync (enforcing)
• [ ] README.md workflow table row + workflow/command count phrasings - check-count-consistency (enforcing)
• [ ] QUICKSTART.md workflow and command count phrasings - check-count-consistency (enforcing)
• [ ] site/src/content/docs/index.mdx hand-authored workflow table + the guided-workflows count line - check-landing-page-counts --strict (enforcing)
• [ ] site/src/content/docs/reference/runtime-components.md content-library counts line (workflow and command counts) - check-count-consistency (enforcing)
• [ ] .github/workflows/release.yml release-note template's slash-command bullet - validator-blind (no validator scans YAML; the new /workflow-quarterly-business-review command makes the generated public release notes false until this bullet is updated by hand)
• [ ] CHANGELOG.md entry under [Unreleased] - release motion
• [ ] Regenerate the resource index if CI asks: node scripts/gen-resource-index.mjs - gen-resource-index --check (enforcing, CI-only)

Promotion Steps

1. Move workflow.md to _workflows/quarterly-business-review.md and command.md to commands/workflow-quarterly-business-review.md (copy, verify, then delete staging). 2. Work the Cross-Cutting Checklist above, in order. 3. Run the validators named in the checklist locally; let CI run regardless (CI is a superset: it builds the site and checks rendered links). 4. Open a PR; squash-merge per repo convention (linear history).

<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->

Workflow Implementation Packet: {workflow-name}

Produced by utility-pm-workflow-builder. Everything below is a DRAFT in

_staging/workflows/{workflow-name}/; nothing has been written to a

canonical location. A human reviews, promotes, and works the checklist.

Decision

{One-paragraph recommendation: build this workflow / customize an existing one / use /chain instead. If the Why Gate fired, list the 2-3 specific scenarios where existing workflows fail; if the user overrode the gate, record the override explicitly.}

• Workflow name: {workflow-name} (file: _workflows/{workflow-name}.md)
• Command: /workflow-{workflow-name} (file: commands/workflow-{workflow-name}.md)
• Steps: {ordered skill list}
• Entry form: {problem-first | skills-first | chain-promotion (paste the originating chain expression)}

Overlap Analysis

{One row per existing workflow with meaningful overlap. Scan the live _workflows/ directory; never a remembered list.}

{Closing line: the specific gap this new workflow fills.}

Workflow Draft

{The COMPLETE draft of _workflows/{workflow-name}.md. The skeleton below is the section inventory every shipped workflow carries; fill every section, remove none.}

---
title: {Display Name}
---

# {Display Name} Workflow

> **{One-line bold tagline: what goes in, what comes out.}**

---

## Workflow Metadata

| Field | Value |
|-------|-------|
| **Workflow** | {Display Name} |
| **Command** | `/workflow-{workflow-name}` |
| **Skills** | `{skill-1}` -> `{skill-2}` -> `{skill-3}` |
| **Phases Covered** | {phases} |
| **Estimated Duration** | {duration} |
| **Prerequisite Inputs** | {what the user must bring} |
| **Final Output** | {the artifact trail} |

---

## When to Use This Workflow

Use the {Display Name} workflow when:

- {trigger 1}
- {trigger 2}

**Do NOT use this workflow when:**

- {anti-trigger with a pointer to the neighboring workflow or skill that fits}

---

## Workflow Steps

### Step 1: {Step Title}

**Skill:** [`{skill-1}`](../skills/{skill-1}/SKILL.md)

**What you do:** {the human-level activity}

**Input requirements:**

- {input 1}

**Output:** {the artifact this step produces}

**Handoff to next step:** {what the next step consumes from this output}

---

{Repeat the step block for every step; the final step omits the handoff.}

## Context Flow Diagram

graph LR A["{skill-1}"] --> B["{skill-2}"] B --> C["{skill-3}"]

---

## Tips and Variations

{2-4 practical tips: lightweight variant, enhanced variant, team usage.}

---

## Quality Checklist

Before considering this workflow complete, verify:

- [ ] {testable completion check per step}

---

## See Also

- [{Neighbor workflow}]({neighbor}.md) - {when to use it instead}

---

*Part of [PM-Skills](../README.md) - Open source Product Management skills for AI agents*

Command Draft

{The COMPLETE draft of commands/workflow-{workflow-name}.md, mirroring the existing workflow-* command shape. One literal skills/<name>/SKILL.md path per step is REQUIRED (validate-commands enforces at least one).}

---
description: Run the {Display Name} workflow ({skill-1} -> {skill-2} -> {skill-3})
---

Run the {Display Name} workflow to {outcome}.

This workflow uses multiple skills in sequence. For each step, read the skill instructions and follow them to create the artifact.

## Workflow Steps

### Step 1: {Step Title}

Use the `{skill-1}` skill from `skills/{skill-1}/SKILL.md`.

{One-line step instruction.}

{Repeat per step.}

## Output

Create all artifacts in sequence, ensuring each builds on the previous.

Reference the {Display Name} workflow at `_workflows/{workflow-name}.md` for additional guidance.

Context from user: $ARGUMENTS

Cross-Cutting Checklist

Adding a workflow trips every surface below. Work each row at promotion; the right column names the validator that catches a miss, and the rows marked validator-blind have NO net: this checklist is the only control.

• [ ] _workflows/{workflow-name}.md created (the draft above) - check-workflow-generator-coverage (enforcing); gen-site.mjs emits the site page automatically (Pattern S: no hand-authored docs page)
• [ ] commands/workflow-{workflow-name}.md created - validate-commands (enforcing); a command-less workflow must instead join check-workflow-coverage's documented optional list (advisory)
• [ ] AGENTS.md workflows section + command list updated - validate-agents-md, check-agents-md-command-sync (enforcing)
• [ ] README.md workflow table row + workflow/command count phrasings - check-count-consistency (enforcing)
• [ ] QUICKSTART.md workflow and command count phrasings - check-count-consistency (enforcing)
• [ ] site/src/content/docs/index.mdx hand-authored workflow table + the guided-workflows count line - check-landing-page-counts --strict (enforcing)
• [ ] site/src/content/docs/reference/runtime-components.md content-library counts line (workflow and command counts) - check-count-consistency (enforcing)
• [ ] .github/workflows/release.yml release-note template's slash-command bullet - validator-blind (no validator scans YAML; a new workflow command makes the generated public release notes false until this is updated BY HAND)
• [ ] CHANGELOG.md entry under [Unreleased] - release motion
• [ ] Regenerate the resource index if CI asks: node scripts/gen-resource-index.mjs - gen-resource-index --check (enforcing, CI-only)

Promotion Steps

1. Move workflow.md to _workflows/{workflow-name}.md and command.md to commands/workflow-{workflow-name}.md (copy, verify, then delete staging). 2. Work the Cross-Cutting Checklist above, in order. 3. Run the validators named in the checklist locally; let CI run regardless (CI is a superset: it builds the site and checks rendered links). 4. Open a PR; squash-merge per repo convention (linear history).