agentsclimarketplace
Sign in

Utility pm workflow builder

Skill product-on-purpose/pm-skills/skills/utility-pm-workflow-builder

Guides a contributor from a workflow idea to a complete Workflow Implementation Packet (draft workflow file, draft workflow command, cross-cutting update checklist) in a staging area for review. Runs overlap analysis against the existing workflows with a Why Gate, then helps select and sequence skills with authored handoffs. Use when creating a new multi-skill workflow or promoting a repeated ad-hoc chain into a durable one. To build a single skill instead, use utility-pm-skill-builder; to run a sequence without authoring anything, use the chain command or utility-pm-workflow-orchestrator.From its SKILL.md

Install
npx -y skills add product-on-purpose/pm-skills --skill utility-pm-workflow-builder

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

What its file declares

Copied from the file, not written here

The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

8.6 KB, ~1.9k tokens by cl100k_base, as published. Nobody here has run it

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

What ships with it: 2 files

19.0 KB alongside SKILL.md

references/

Gives 0 of the 12 instructions most automation workflows skills give in ~1.9k tokens

Counted across 813 of the 1,214 authors here whose files we hold, read 2026-09-06

  • Use conventional commit message formatin 38 of 813, across 34 files
  • Write tests before implementing codein 26 of 813, across 12 files
  • Achieve at least 80 percent test coveragein 24 of 813, across 11 files
  • Mock external dependencies for unit testsin 22 of 813, across 10 files
  • Read product marketing context before asking questionsin 21 of 813, across 6 files
  • Implement rollback plans for every deploymentin 21 of 813, across 9 files
  • Follow the arrange-act-assert patternin 20 of 813, across 9 files
  • Delete branches after mergingin 20 of 813, across 18 files
  • Test all edge cases and error scenariosin 20 of 813, across 8 files
  • Use semantic selectors for UI testsin 19 of 813, across 7 files
  • Define sequence type and audience contextin 18 of 813, across 5 files
  • Monitor feature drift and prediction distribution driftin 18 of 813, across 5 files

Said here and by no other author read

  • scan the workflows directory at runtime for current inventory
  • ask one clarifying question if the idea is vague
  • name each overlapping workflow and estimate coverage
  • record why gate evidence or user overrides in the packet
  • resolve every step to an installed skill by exact name
  • author handoffs for each step consuming and producing outputs

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.