utility-pm-skill-builder
The utility-pm-skill-builder generates a structured Skill Implementation Packet that validates whether a new product management skill should be created by checking for overlap with existing skills, confirming genuine gaps, and producing classification, frontmatter, and draft files. Use this tool when developing new PM skills for the product-on-purpose framework to ensure consistency, avoid duplication, and establish proper documentation standards before full implementation.
git clone --depth 1 https://github.com/product-on-purpose/pm-skills /tmp/utility-pm-skill-builder && cp -r /tmp/utility-pm-skill-builder/library/skill-output-samples/utility-pm-skill-builder/sample_utility-pm-skill-builder_storevine_campaign-analytics- ~/.claude/skills/utility-pm-skill-buildersample_utility-pm-skill-builder_storevine_campaign-analytics-skill.md
<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 --> ## Scenario A contributor runs the skill builder to create a "campaign-analytics" skill for defining email campaign measurement frameworks. The builder checks overlap with existing measure skills, confirms the gap (no skill covers funnel metrics, cohort analysis, or attribution models), and generates a Skill Implementation Packet. [fictional] --- ## Prompt ``` utility-pm-skill-builder Idea: A skill for defining email campaign measurement frameworks -- funnel metrics (sent > delivered > opened > clicked > converted), cohort comparison, and revenue attribution. Existing measure skills handle dashboards and event tracking but not campaign-specific analytics frameworks. ``` --- ## Output # Skill Implementation Packet: campaign-analytics > **Created**: 2026-04-11 > **Builder version**: 1.0.0 > **Status**: Draft ## Decision Create new skill. Why Gate evidence: (1) `measure-dashboard-requirements` produced a dashboard spec but skipped funnel definition and attribution; (2) `measure-instrumentation-spec` produced event schemas but not the analytical framework connecting events to outcomes; (3) `measure-experiment-design` assumed A/B test structure rather than ongoing measurement. [fictional] ## Classification | Field | Value | |-------|-------| | Type | domain | | Phase | measure | | Directory | measure-campaign-analytics | | Command | /campaign-analytics | ## Overlap Analysis ### Existing skills checked measure-dashboard-requirements, measure-instrumentation-spec, measure-experiment-design, measure-experiment-results, deliver-acceptance-criteria, define-hypothesis ### Findings Existing skills assume the PM already knows which metrics matter or are scoped to A/B tests. None address funnel definition, cohort segmentation, or revenue attribution. [fictional] ### Why this skill is still needed Fills the gap between "we need to measure campaigns" and "here is the dashboard spec" -- produces the analytical foundation that feeds downstream skills. [fictional] ## Draft Frontmatter ```yaml --- name: campaign-analytics description: Defines a measurement framework for email campaign performance covering funnel metrics, cohort analysis, KPI specification, and revenue attribution. phase: measure version: "1.0.0" updated: 2026-04-11 license: Apache-2.0 metadata: category: specification --- ``` ## Draft Files (abbreviated) **SKILL.md**: Guides PMs through defining funnel stages, KPIs, cohort comparisons, and attribution models. 6 instruction steps, output contract, quality checklist. [fictional] **TEMPLATE.md**: 7 sections -- Campaign Context, Funnel Definition, KPI Specification, Cohort Design, Attribution Model, Data Source Mapping, Open Questions. [fictional] **EXAMPLE.md**: Worked example (180 lines) for a B2B SaaS onboarding email sequence. [fictional] **Command + AGENTS.md**: Standard routing to `skills/measure-campaign-analytics/SKILL.md`. [fictional] ## Validation Checklist All 9 CI checks pass (name, description, version, updated, license, phase consistency, TEMPLATE.md sections, command path, AGENTS.md format). All 6 quality checks pass (EXAMPLE.md 180 lines, output contract, quality checklist, dominant zone identified, gap analysis on 6 skills, Why Gate names 3 prompts). [fictional] ## Next Steps 1. Review the packet and flag changes needed. 2. Run `bash scripts/lint-skills-frontmatter.sh` after promotion. 3. Test `/campaign-analytics` with a realistic scenario, then use `utility-pm-skill-iterate` to refine.
Run an ad-hoc ordered chain of pm-skills with shared context (ephemeral; routes to the pm-workflow-orchestrator)
Defines a testable hypothesis with clear success metrics and a validation approach. Use when forming assumptions to test or aligning a team on what success looks like, before any experiment is designed. To design the A/B test or experiment that will validate the hypothesis, use measure-experiment-design.
Creates a Jobs to be Done canvas capturing the functional, emotional, and social dimensions of a customer job. Use when deeply understanding customer motivations, designing for jobs, or reframing product positioning.
Creates an opportunity solution tree connecting a desired outcome to customer opportunities and candidate solutions, preventing solution-first jumps in continuous discovery. Use when structuring scattered feature ideas or communicating how the roadmap traces to outcomes. For ranking an existing flat list of candidates, use define-prioritization-framework instead; this skill discovers the list, it does not score one.
Run applicable prioritization frameworks (RICE, ICE, MoSCoW, Weighted Scoring, Kano) against a list of features or initiatives. Produces a comparison table showing where rankings agree and diverge across frameworks, and an executive summary with recommendation. Framework applicability is filtered by data availability; Kano requires customer research. Refuses to fabricate scores; produces an estimation scaffold when input data is missing.
Creates a clear problem framing document with user impact, business context, and success criteria. Use when starting a new initiative, realigning a drifted project, or communicating up to leadership.
Generates structured Given/When/Then acceptance criteria for a user story or feature slice, covering the happy path, key failure scenarios, and non-functional expectations in testable form. Use when turning requirements into verifiable scenarios for engineering handoff and QA sign-off. For a dedicated catalog of boundary conditions, error states, and recovery paths across a feature, use deliver-edge-cases; to write the stories themselves, use deliver-user-stories.
Documents edge cases, error states, boundary conditions, race conditions, and recovery paths for a feature - the systematic catalog of what can go wrong and the failure modes to design for. Use during specification to map the failure surface and ensure comprehensive coverage, or during QA planning to identify boundary and limit scenarios to test. Distinct from deliver-acceptance-criteria, which writes story-level Given/When/Then checks; this skill produces the whole-feature edge-case catalog.