PM Workflow Builder

Try it: /pm-skills:utility-pm-workflow-builder "Your context here"

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

How to Use

Invoke the skill by name (/pm-skills:utility-pm-workflow-builder on Claude Code, $utility-pm-workflow-builder on Codex):

/pm-skills:utility-pm-workflow-builder "Your context here"

Or reference the skill file directly: skills/utility-pm-workflow-builder/SKILL.md

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 Template

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.}

Existing workflow	What it covers	Overlap	Why it does not fit
{name}	{coverage}	{low/medium/high, estimate}	{the gap}

{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

```mermaid
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}

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.

Promotion Steps

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

Example Output

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:

“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.
“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.
“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:

Existing workflow	What it covers	Overlap	Why it does not fit
post-launch-learning	Instrumentation, dashboards, experiment results, retro, lessons	Medium (shares results synthesis)	Ends at team learning; produces no stakeholder map, pre-read, or meeting materials
stakeholder-alignment	Stakeholder summary, problem statement, solution brief, launch checklist	Medium (shares stakeholder mapping)	Builds a one-time buy-in case for a decision; a QBR is a recurring results-and-priorities communication
sprint-planning	Refinement, stories, edge cases	None	Different lifecycle moment entirely

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

```mermaid
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

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.

Promotion Steps

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

Real-World Examples

See this skill applied to three different product contexts:

Storevine (B2B): Storevine B2B ecommerce platform. The Campaigns team runs the same three-skill sequence for every campaign-template release; the PM promotes the chain into a durable workflow.

Prompt:

utility-pm-workflow-builder

Entry: chain promotion. Originating chain expression from the orchestrator suggestion:
deliver-launch-checklist -> deliver-release-notes -> foundation-stakeholder-update

Context the runs used: "Campaign template release for Storevine merchants - readiness,
merchant comms, internal update."

Constraints: this recurs every release; we want the handoffs written down so any PM on
the Campaigns team can run it the same way.

Output:

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

Reference the Campaign Launch workflow at _workflows/campaign-launch.md for additional guidance.

Context from user: $ARGUMENTS

</details>

<details>
<summary>Brainshelf (Consumer): Brainshelf consumer PKM app. The solo PM tunes the Resurface morning digest in a recurring results-to-next-experiment cycle and wants it written down before handing growth work to a new hire.</summary>

**Prompt:**

utility-pm-workflow-builder

need a workflow for the resurface tuning loop. every 2 weeks: look at last test’s results, clean up the idea backlog, pick the next hypothesis, design the next test. basically results -> refinement-notes -> hypothesis -> experiment-design. new growth hire starts next month and I want this repeatable, not in my head

---

**Output:**

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

Reference the Digest Experiment Loop workflow at `_workflows/digest-experiment-loop.md` for additional guidance.

Context from user: $ARGUMENTS

Workbench (Enterprise): Workbench enterprise collaboration platform. Platform PM standardizes the review run after each staged Blueprints rollout wave so feedback, learnings, and the customer-facing report follow one process across 500 enterprise accounts.

Prompt:

utility-pm-workflow-builder

Request type: new workflow (problem-first).

Problem: After each staged Blueprints rollout wave (8-12 enterprise accounts per wave),
we run an ad-hoc review. Inputs: the rollout feedback survey (sent to all admins in the
wave) and 4-6 recorded admin interviews. Required outputs, in order:
  1. Survey analysis with segment cuts (account size, vertical)
  2. Interview synthesis reconciled against the survey findings
  3. A lessons entry for the rollout playbook (institutional memory)
  4. A customer-facing rollout report for the wave's account teams

Process requirements: repeatable across waves, runnable by any platform PM, each step's
input contract explicit.

Output:

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

Reference the Enterprise Rollout Review workflow at _workflows/enterprise-rollout-review.md for additional guidance.

Context from user: $ARGUMENTS

</details>

## 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

## 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.

PM Workflow Builder

When to Use

When NOT to Use

How to Use

Instructions

Step 1: Understand the Idea

Step 2: Overlap Analysis + Why Gate

Step 3: Sequence Design

Step 4: Generate the Packet

Step 5: Review + Promotion Guidance

Output Template

Workflow Implementation Packet: {workflow-name}

Decision

Overlap Analysis

Workflow Draft

Tips and Variations

Quality Checklist

See Also

Cross-Cutting Checklist

Promotion Steps

Example Output

Workflow Implementation Packet: quarterly-business-review

Decision

Overlap Analysis

Workflow Draft

Tips and Variations

Quality Checklist

See Also

Cross-Cutting Checklist

Promotion Steps

Real-World Examples