PM Skill Builder

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

This skill creates new PM skills for the pm-skills library. It produces a Skill Implementation Packet - a complete design document with draft files in a staging area for review before promotion to canonical locations.

When to Use

When you have an idea for a new PM skill
When you want to add a domain skill (phase-specific), foundation skill (cross-cutting), or utility skill (meta/tooling) to the pm-skills library
When a contributor needs guided skill creation that follows repo conventions

When NOT to Use

To modify or improve an existing skill → use utility-pm-skill-iterate
To audit an existing skill against conventions → use utility-pm-skill-validate
To create a skill for a non-pm-skills context → use a general agent skill builder
To create a workflow → workflows are authored directly, not via this builder

How to Use

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

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

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

Instructions

When asked to create a new PM skill, follow these steps:

Step 1: Understand the Idea

Accept the idea in either form:

Problem-first: “What PM problem does this skill solve? Who runs into this problem, and what do they currently produce (or fail to produce)?”
Skill-first: “Describe the skill you want to create. What artifact does it produce? What PM activity does it support?”

Both entry points produce the same downstream flow. If the user provides one form, do not ask for the other - extract what you need and proceed.

If the idea is vague, ask ONE follow-up question to clarify the artifact type and target audience before proceeding.

Step 2: Gap Analysis

Check ALL existing skills for overlap. Use the Current Library Reference below (derive the live inventory from skill-manifest.json or AGENTS.md) AND scan the skills/ directory for the latest inventory. Include all four families - domain, foundation, utility, and tool - the tool family is easy to miss since it has no phase prefix pattern in common conversation.

Present findings with specificity:

Name each overlapping skill and explain what it covers
Identify the specific gap this new skill would fill
If overlap is high, trigger the Why Gate (see below)

Why Gate (triggers when overlap is found): Ask the user: “Name 2-3 specific prompts or scenarios where the existing skills fail to produce what you need.”

Kill Gate: If the user cannot articulate convincing gaps, recommend an alternative:

“Revise [existing skill] to cover this case”
“Create a workflow combining [skill A] + [skill B]”
“Add a command variant, not a new skill”
“This is a documentation improvement, not a new skill”

Do not proceed past the kill gate without either convincing evidence of a gap or explicit user override.

Step 3: Scope Check

Evaluate whether the idea should be ONE skill or MULTIPLE skills.

Splitting signals:

The idea produces multiple distinct artifact types
The idea crosses Triple Diamond phases (e.g., Discover + Deliver)
The description naturally contains “and” connecting two activities

If splitting is warranted, present the recommendation: “This seems to cover two distinct PM activities:

[Activity A] → produces [Artifact A]
[Activity B] → produces [Artifact B] These work better as separate skills that can be chained via a workflow. Want to proceed with just [Activity A] for now?”

Step 4: Classification + Repo-Fit

Determine the skill’s classification and naming:

Domain skills (phase-specific PM activities):

Phase: discover | define | develop | deliver | measure | iterate
Directory: {phase}-{skill-name}
Frontmatter: phase: {phase} (required), no classification field

Foundation skills (cross-cutting, used across phases):

No phase
Directory: foundation-{skill-name}
Frontmatter: classification: foundation (required), no phase field
Use when: the skill applies to multiple phases equally

Utility skills (meta-skills, repo tooling):

No phase
Directory: utility-{skill-name}
Frontmatter: classification: utility (required), no phase field
Use when: the skill operates on the repo, workflow, or other skills

Dialect and exemplar selection: First, pick the skill’s dialect from Skeleton Canon: The Three Sanctioned Dialects (classic, contract-shaped, or tool-family) - this fixes the required heading skeleton before any exemplar is chosen. Do not default to “mirror the closest exemplar”: an exemplar can itself carry drift (a case variant, an extra or missing section), and a straight mirror copies that drift forward into the new skill.

Then identify 1-2 existing skills in the SAME dialect that are the closest structural match:

Same phase > same category > similar artifact type
Read their SKILL.md to confirm instruction style, output-contract wording, and quality-checklist pattern (the canon fixes the required headings; the exemplar informs everything else - tone, step granularity, and any skill-specific extra sections)
Name the exemplars explicitly: “Modeled after [skill] - same phase, [category] category, [dialect] dialect”

Present the classification, dialect, and exemplar selection for user confirmation.

Step 4.5: Eval Readiness (the eval contract)

A new skill must ship eval-ready so coverage never falls behind: routing health and output quality are both measurable from day one. Decide the eval contract here, then emit its assets in Step 5. Four parts:

A. Nearest neighbors (C-2). Name the new skill’s 1-3 nearest neighbors - the existing skills whose triggers most overlap. Derive them from the Step 2 gap analysis plus same-phase / same-category siblings. These neighbors drive the boundary pointers (below), the near-miss trigger fixtures (Step 5), and the collision probe (Step 7).

B. Reciprocal boundary pointers (C-3). The draft SKILL.md MUST include a ## When NOT to Use section that names each neighbor and says when to use that neighbor instead. For every neighbor, also add the reciprocal pointer back: a “When NOT to Use” bullet in the neighbor’s SKILL.md pointing to the new skill. If the overlap is strong enough to be a measured collision pair, add the pair to COLLISION_PAIRS in scripts/check-trigger-fixtures.mjs so the reciprocity gate (check-reciprocal-boundary-pointers.mjs) and the collision probe both cover it. Reciprocal pointers are what kept the v2.26.0 rewrites collision-clean.

C. Output-eval family (C-4). Map the skill to an output-eval family rubric so its artifact quality is measurable. Pick by phase/category:

Family rubric	Covers (phase / kind)
`framing`	define-* problem/hypothesis/jtbd/opportunity/prioritization + foundation-okr-writer/persona/lean-canvas
`specification`	deliver-* prd/acceptance-criteria/user-stories/edge-cases/launch-checklist
`discovery`	discover-* interview-synthesis/competitive/market-sizing/journey/stakeholder
`technical`	develop-* adr/design-rationale/solution-brief/spike-summary
`measurement`	measure-* experiment-design/results/okr-grader/dashboard/instrumentation/survey
`learning`	iterate-* retrospective/lessons-log/pivot-decision/refinement-notes
`communication`	audience-facing: deliver-release-notes, foundation-stakeholder-update

Family rubrics live at docs/internal/eval-rubrics/{family}.md. If the skill fits a family that has a rubric, use that family value in the scenario frontmatter. If it opens a NEW family (meeting/tool skills have none yet), note “no family rubric yet - author one before the skill enters the output-eval roster” and skip the family value.

D. Fixture + scenario plan (C-1, C-4). Plan the two eval-asset files emitted in Step 5: a trigger-fixtures.json (routing) and an output-scenarios/<id>.md (output quality). Their shapes are specified in Step 5 items 13-14.

Present the neighbors + family + reciprocal-pointer plan for user confirmation before generating the packet.

Step 5: Generate Skill Implementation Packet

Produce the complete packet using references/TEMPLATE.md as the format. The packet includes:

Decision - recommendation + Why Gate evidence (if applicable)
Classification - type, phase (if domain), category, directory name
Overlap Analysis - what was found, why this skill is still needed
Exemplar Skills - which existing skills modeled, why
Draft Frontmatter - complete, valid YAML block. The frontmatter MUST begin with --- at byte 0 of the file (no preceding content of any kind, including HTML comments, BOM, or whitespace). Place any attribution comment AFTER the closing --- fence, never before. Reference: library/skill-output-samples/SAMPLE_CREATION.md Section 5.
Draft SKILL.md - full content (not an outline), following the Step 4 dialect’s canon heading skeleton and the chosen exemplars’ instruction style
Draft TEMPLATE.md - section headers with guidance comments
Draft EXAMPLE.md - complete, realistic example (150-300 lines) with a specific PM scenario, every section filled, optional sections demonstrated both filled and skipped
Draft Command - command frontmatter
AGENTS.md Entry - exact text to add
Validation Checklist - all CI rules checked against the draft
Next Steps - local CI, testing, contribution workflow
Draft trigger-fixtures.json (C-1, routing eval) - evals/trigger-fixtures.json: a JSON object { "schema": 1, "skill": "{name}", "runs_per_query": 3, "trigger_threshold": 0.5, "queries": [...] }. The queries array needs >= 16 total, >= 8 with "expect": "trigger" (drawn from the skill’s real intents, NOT just artifact keywords - include intent-only asks) and >= 8 with "expect": "no-trigger", of which >= 2 are near-misses aimed at the Step 4.5 neighbors (mark them "near_miss_of": "{neighbor}"). Split each class ~60/40 across "split": "train" / "split": "validation". This is the B-4 fixture contract (scripts/check-trigger-fixtures.mjs).
Draft output-scenario (C-4, output-quality eval) - evals/output-scenarios/{id}.md: frontmatter scenario: {id} / skill: {name} / family: {family from Step 4.5} / created: {date}, then a realistic input brief (>= 100 chars of body) that gives the skill arm and a freehand control the same raw material. This is the B-7 asset contract (scripts/check-output-eval-assets.mjs). Omit family only if Step 4.5 found no rubric yet.

Step 6: Write to Staging Area

Write all generated files to the staging area:

_staging/pm-skill-builder/{skill-name}/
├── SKILL.md               ← draft skill file
├── references/
│   ├── TEMPLATE.md        ← draft template
│   └── EXAMPLE.md         ← draft example
├── evals/
│   ├── trigger-fixtures.json        ← draft routing fixtures (C-1)
│   └── output-scenarios/{id}.md     ← draft output-quality scenario (C-4)
└── command.md             ← draft command

Note: _staging/ is gitignored - draft artifacts never ship in releases. The staging folder is discarded after promotion.

Report what was written and where.

Step 7: Promote (on confirmation)

Ask: “Review the packet above. When ready, I’ll promote the files to their canonical locations. Proceed? [yes/no]”

If yes, promote by copying each file from staging to its canonical path:

Staging file	Canonical location
`_staging/pm-skill-builder/{skill-name}/SKILL.md`	`skills/{dir-name}/SKILL.md`
`_staging/pm-skill-builder/{skill-name}/references/TEMPLATE.md`	`skills/{dir-name}/references/TEMPLATE.md`
`_staging/pm-skill-builder/{skill-name}/references/EXAMPLE.md`	`skills/{dir-name}/references/EXAMPLE.md`
`_staging/pm-skill-builder/{skill-name}/evals/trigger-fixtures.json`	`skills/{dir-name}/evals/trigger-fixtures.json`
`_staging/pm-skill-builder/{skill-name}/evals/output-scenarios/{id}.md`	`skills/{dir-name}/evals/output-scenarios/{id}.md`
`_staging/pm-skill-builder/{skill-name}/command.md`	`commands/{command-name}.md`

Where {dir-name} is the classification-prefixed directory (e.g., deliver-change-communication).

Then:

Create the target directories: skills/{dir-name}/references/ and skills/{dir-name}/evals/output-scenarios/
Copy each file to its canonical location
Append the AGENTS.md entry from the packet; if Step 4.5 declared a collision pair, add it to COLLISION_PAIRS in scripts/check-trigger-fixtures.mjs and add the reciprocal “When NOT to Use” bullet to each neighbor’s SKILL.md
Run CI validation: bash scripts/lint-skills-frontmatter.sh && bash scripts/validate-agents-md.sh && bash scripts/validate-commands.sh, then the eval-asset gates node scripts/check-trigger-fixtures.mjs, node scripts/check-output-eval-assets.mjs, node scripts/check-reciprocal-boundary-pointers.mjs, and the collision probe node scripts/check-new-skill-collision.mjs --skill={name} (C-2 - confirms the new skill recalls its own triggers and steals none of a neighbor’s). Regenerate the catalog surfaces: node scripts/gen-skill-manifest.mjs && node scripts/gen-skill-manifest.mjs --agents
If validation passes, delete the staging folder: _staging/pm-skill-builder/{skill-name}/
If validation fails, report the error and keep staging intact for fixes

Design rationale lives in the GitHub issue, PR, or effort brief - not in a permanent packet file.

Provide post-promotion guidance:

“Run CI locally: bash scripts/lint-skills-frontmatter.sh”
“Test the skill: try /{command-name} with a realistic scenario”
“If contributing: create a GitHub issue with the skill-proposal template, then open a PR”

Current Library Reference

Do not hand-maintain a skill inventory in this file. A static table here has drifted from the real catalog before (most recently: an entire family untracked, plus a missing row in another) because every new or removed skill would require a hand edit here too. Instead, derive the live inventory at run time, every time, from one of:

skill-manifest.json (repo root) - generated, machine-readable; every skill’s name, classification, phase (if any), category, and description.
AGENTS.md - generated, human-browsable; the same catalog grouped by family with a short description per skill.

Both are regenerated by node scripts/gen-skill-manifest.mjs (and --agents) whenever a skill is added, changed, or removed, so they track skills/ on disk exactly - unlike a hand-written table, they cannot drift.

The families, for orientation (no counts kept here on purpose - read the manifest for the current total):

Family	Phase-scoped?	Directory prefix	Covers
Domain	Yes (discover/define/develop/deliver/measure/iterate)	`{phase}-`	PM activities scoped to one Triple Diamond phase
Foundation	No	`foundation-`	Cross-cutting artifacts used across phases (canvases, personas, OKRs, meeting artifacts, stakeholder communication, pre-build risk review)
Utility	No	`utility-`	Meta/tooling skills that operate on the repo, workflow, or other skills (this skill is one)
Tool	No	`tool-`	Workshop facilitation formats (Foundation Sprint family, Design Sprint family, standalone facilitation formats)

For gap analysis (Step 2), read skill-manifest.json or AGENTS.md in full - all four families, not just domain and foundation - before judging overlap. The tool family is the easiest to miss because none of its skills share a phase name with the idea being pitched.

Output Contract

The builder MUST produce draft files for the new skill:

SKILL.md - full skill instructions (including a When NOT to Use section naming neighbors, C-3)
references/TEMPLATE.md - output template with guidance comments
references/EXAMPLE.md - complete worked example (150-300 lines)
evals/trigger-fixtures.json - routing eval fixtures (C-1; B-4 contract)
evals/output-scenarios/{id}.md - output-quality scenario + family rubric (C-4; B-7 contract)
command.md - slash command file

All drafts are written to _staging/pm-skill-builder/{skill-name}/ (gitignored).

On promotion, files are copied to canonical locations, AGENTS.md is updated, and the staging folder is discarded.

Examples

See references/EXAMPLE.md for a completed Skill Implementation Packet demonstrating a realistic domain skill creation.

Output Template

Skill Implementation Packet: {Skill Name}

Created: {date} Builder version: 1.0.0 Status: Draft | Promoted | Abandoned

Decision

{Recommendation: create / revise existing / workflow / command / docs-only}

{Why Gate evidence if applicable - the 2-3 specific prompts or scenarios where existing skills fail}

Classification

Field	Value
Type	{domain / foundation / utility}
Phase	{discover / define / develop / deliver / measure / iterate / n/a}
Category	{specification / research / coordination / validation / reflection / ideation / problem-framing}
Directory	{phase/classification}-{skill-name}
Command	/{command-name}

Overlap Analysis

Existing skills checked

{List of skills reviewed during gap analysis}

Findings

{What was found - specific overlap and differentiation}

Why this skill is still needed

{The gap this skill fills that no existing skill covers}

Exemplar Skills

Skill	Why selected
{exemplar-1}	{Same phase, similar category, closest structural match}
{exemplar-2}	{Additional reference for a specific pattern}

Draft Frontmatter

<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->
---
name: {skill-name}
description: {20-100 word description on a single line - linter reads first line only}
phase: {phase}          # for domain skills only - omit for foundation/utility
classification: {type}  # for foundation/utility only - omit for domain
version: "1.0.0"
updated: {date}
license: Apache-2.0
metadata:
  category: {category}
  frameworks: [triple-diamond]
  author: product-on-purpose
---

Linter constraint: description: must be a single-line value (no >- or | folding). The linter extracts only the first line after the key using sed. Multiline YAML would capture the literal >- string and fail the 20-100 word check.

Draft SKILL.md

{Full draft content - not an outline. Includes:

Title and introductory paragraph
When to Use section
When NOT to Use section (if applicable)
Instructions (numbered steps)
Output Contract
Quality Checklist
Examples reference

Mirrors the section structure of the selected exemplar skill.}

Draft TEMPLATE.md

{Section headers with guidance comments for each section. Each section has:

A ## header
A brief instruction comment explaining what goes here
Placeholder structure showing the expected format}

Draft EXAMPLE.md

{A complete, realistic example - 150-300 lines.

Picks a specific PM scenario appropriate to the skill’s domain
Fills every TEMPLATE.md section with concrete content
Demonstrates optional sections both filled and skipped
Shows what “good” looks like for ambiguous sections}

Draft Command

---
description: {One-line description of what the command does}
---

Use the `{skill-name}` skill to {primary action}.

Read the skill instructions from `skills/{directory-name}/SKILL.md` and follow them to {describe the task}.

Use `skills/{directory-name}/references/TEMPLATE.md` as the output format.

Context from user: $ARGUMENTS

Convention: Command files use only description: in frontmatter. No name, arguments, or skill_file fields. The optional idea argument is handled via $ARGUMENTS in the prose body, matching all existing commands.

AGENTS.md Entry

#### {skill-name}
**Path:** `skills/{directory-name}/SKILL.md`

{1-2 sentence description. Imperative verb start, use-case focus.}

---

Convention: Level-4 header (kebab-case skill name), **Path:** line, blank line, description paragraph, --- separator. No **Command:** field. Must pass validate-agents-md.sh which checks path ↔ directory sync.

Validation Checklist

CI Validation (must pass - enforced by linter + validators)

name matches directory name
description is 20-100 words (single-line, no >-)
version present (exactly one root-level, no metadata.version)
updated present (ISO date format)
license present (Apache-2.0)
Phase/classification consistency (domain has phase:, foundation/utility has classification:)
references/TEMPLATE.md exists with ≥3 ## sections
Command file references correct skill path (validate-commands.sh)
AGENTS.md entry uses #### {name} + **Path:** format (validate-agents-md.sh)

Quality Checks (should pass - builder-enforced, not CI-gated)

references/EXAMPLE.md is a complete artifact (150-300 lines), not an outline
Output contract present in SKILL.md
Quality checklist present in SKILL.md
Gap analysis checked all existing skills (not just same-phase)
Why Gate evidence is specific (names prompts/scenarios, not vague)

Next Steps

Review: Read through the packet above. Flag any sections that need changes.
Local CI: Run bash scripts/lint-skills-frontmatter.sh after promotion.
Test: Try using /{command-name} with a realistic PM scenario.
Contribute: If submitting to pm-skills, create a GitHub issue using the skill-proposal template, then open a PR with the promoted files.
Iterate: Use the pm-skill iteration utility (when available) to refine based on testing feedback.

Example Output

Skill Implementation Packet: Change Communication

Created: 2026-03-22 Builder version: 1.0.0 Status: Draft

Decision

Recommendation: Create new skill.

A mid-stage SaaS company needs a repeatable way to produce change management communications when shipping features that alter user workflows. Existing skills cover adjacent concerns (release notes for external announcements, launch checklists for cross-functional readiness) but nothing guides the actual writing of internal adoption-focused communications that help users understand what changed, why it matters, and what they need to do differently.

Classification

Field	Value
Type	domain
Phase	deliver
Category	coordination
Directory	deliver-change-communication
Command	/change-communication

Overlap Analysis

Existing skills checked

All current skills reviewed (full catalog scan). Closest matches:

deliver-release-notes - produces external-facing release announcements
deliver-launch-checklist - tracks cross-functional launch readiness
deliver-user-stories - defines implementation requirements
discover-stakeholder-summary - maps stakeholder needs and influence

Findings

deliver-release-notes: Covers what shipped and why users should care, but targets external audiences (changelog readers, update-notification subscribers). Change communications target internal users, support teams, and account managers who need to understand workflow impact and guide adoption.

deliver-launch-checklist: Includes “communications sent” as a line item but does not guide what those communications should contain, how to structure them for different audiences, or how to sequence rollout messaging.

Why this skill is still needed

No existing skill produces the actual communication artifact - the email, Slack message, or internal knowledge-base update that tells affected users what changed, what they need to do differently, and where to get help. This is a distinct coordination artifact in the Deliver phase.

Exemplar Skills

Skill	Why selected
deliver-release-notes	Same phase (deliver), same category (coordination), closest artifact type - both produce written communications about product changes
deliver-launch-checklist	Same phase (deliver), different category - shows how to structure a multi-audience coordination artifact with checkpoints

Draft Frontmatter

<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->
---
name: deliver-change-communication
description: Creates targeted change management communications for feature launches that alter user workflows. Guides audience segmentation, impact assessment, message drafting, and rollout sequencing to drive adoption and reduce support burden for SaaS product changes.
phase: deliver
version: "1.0.0"
updated: 2026-03-22
license: Apache-2.0
metadata:
  category: coordination
  frameworks: [triple-diamond]
  author: product-on-purpose
---

Draft SKILL.md

Representative excerpt showing all section headers with sample content. A full implementation would expand each section to 5-15 lines.

# Change Communication

Change communication bridges the gap between shipping a feature and ensuring
affected users successfully adopt the new workflow.

## When to Use

- When a feature launch changes existing user workflows
- When multiple audience segments need different levels of detail
- When support teams need advance preparation for user questions

## Instructions

### Step 1: Identify the Change and Affected Audiences
Gather the feature context and segment audiences by impact level.

### Step 2: Assess Workflow Impact
Map before/after workflows for each audience segment.

### Step 3: Draft Per-Audience Messages
Write targeted communications using the template structure.

### Step 4: Plan Rollout Sequence
Determine timing and channels for each audience segment.

### Step 5: Review and Finalize
Verify completeness, tone, and accuracy with stakeholders.

## Output Contract

Use `references/TEMPLATE.md` to structure the output.

## Quality Checklist

- [ ] All affected audience segments are identified
- [ ] Before/after workflow changes are explicit
- [ ] Each message includes what changed, why, and what to do next
- [ ] Support enablement section is complete
- [ ] Rollout timing accounts for audience dependencies

## Examples

See `references/EXAMPLE.md` for a completed example.

Draft TEMPLATE.md

Representative excerpt with section headers and guidance comments.

# Change Communication: {Feature Name}

## Change Summary

> Describe the feature change in 2-3 sentences. Focus on what users will
> experience differently, not technical implementation details.

## Affected Audiences

> List each audience segment with their relationship to the change.

| Audience | Impact Level | Primary Channel |
|----------|-------------|-----------------|
| {segment} | High / Medium / Low | {email / Slack / in-app / KB article} |

## Workflow Impact Assessment

> For each audience, describe the before and after states.

### {Audience Segment}

**Before**: {current workflow}
**After**: {new workflow}
**Action required**: {what they need to do differently}

## Communications

### {Audience Segment} Message

> Draft the actual message content for this audience.

**Subject**: {email subject or message headline}
**Body**: {complete message text}

## Support Enablement

> What does the support team need to know to handle questions?

## Rollout Schedule

> When does each communication go out, relative to the launch?

| Audience | Timing | Channel | Owner |
|----------|--------|---------|-------|
| {segment} | {T-N days / launch day / T+N days} | {channel} | {person} |

Draft EXAMPLE.md

A complete example would demonstrate a change communication package for a realistic SaaS scenario - such as migrating a dashboard reporting interface from a legacy layout to a new design system. It would fill every template section with concrete content: three audience segments (power users, casual viewers, account administrators), before/after workflow descriptions, drafted messages per audience, a support FAQ, and a rollout timeline spanning T-5 through T+3 days. Target length: 150-300 lines.

Draft Command

---
description: Create change management communications for a feature launch
---

Use the `deliver-change-communication` skill to create targeted change communications.

Read the skill instructions from `skills/deliver-change-communication/SKILL.md` and follow them to guide the user through audience segmentation, impact assessment, and message drafting.

Use `skills/deliver-change-communication/references/TEMPLATE.md` as the output format.

Context from user: $ARGUMENTS

AGENTS.md Entry

#### change-communication
**Path:** `skills/deliver-change-communication/SKILL.md`

Creates targeted change management communications for feature launches that alter user workflows. Use when multiple audiences need different messages about what changed, why, and what to do next.

---

Validation Checklist

CI Validation

name matches directory name (deliver-change-communication)
description is 20-100 words (single-line) - 33 words
version present ("1.0.0")
updated present (2026-03-22)
license present (Apache-2.0)
Phase/classification: domain skill has phase: deliver, no classification: field
references/TEMPLATE.md has ≥3 ## sections (6 sections)
Command file references correct path (skills/deliver-change-communication/SKILL.md)
AGENTS.md entry uses #### change-communication + **Path:** format

Quality Checks

references/EXAMPLE.md will be a complete artifact (150-300 lines)
Output contract present in draft SKILL.md
Quality checklist present in draft SKILL.md
Gap analysis checked all 27 existing skills
Why Gate not triggered (no high overlap - release-notes and launch-checklist serve different purposes)

Next Steps

Review: Read through the packet above. Flag any sections that need changes.
Local CI: Run bash scripts/lint-skills-frontmatter.sh after promotion.
Test: Try using /change-communication with a realistic feature launch scenario.
Contribute: If submitting to pm-skills, create a GitHub issue using the skill-proposal template, then open a PR with the promoted files.
Iterate: Use the pm-skill iteration utility (when available) to refine based on testing feedback.

Real-World Examples

See this skill applied to three different product contexts:

Storevine (B2B): Storevine B2B ecommerce platform . using the skill builder to create a campaign-analytics skill

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

Quality Checklist

Before finalizing the packet, verify all items in both tiers:

CI Validation (must pass)

name matches directory name
Description is 20-100 words (single-line, no multiline YAML)
version, updated, license all present
Classification correct (domain → phase:, foundation/utility → classification:)
Directory name follows convention: {phase/classification}-{skill-name}
TEMPLATE.md has ≥3 ## sections
Command file references correct skill path
AGENTS.md entry uses #### + **Path:** format

Quality Checks (should pass)

Gap analysis checked all existing skills (not just same-phase)
Why Gate evidence is specific (names prompts/scenarios, not vague)
EXAMPLE.md is a complete artifact (150-300 lines), not an outline
Output contract is present in draft SKILL.md
Quality checklist is present in draft SKILL.md

Eval contract (C-1..C-4; ship eval-ready)

Nearest neighbors named (C-2); When NOT to Use section points to each
Reciprocal “When NOT to Use” pointer added back from each neighbor (C-3); collision pair added to COLLISION_PAIRS if strong overlap
evals/trigger-fixtures.json present and meets the B-4 contract (>=16 queries, >=8/class, >=2 near-misses, train/validation split)
evals/output-scenarios/{id}.md present with scenario/skill/family frontmatter mapping to an existing rubric (or family deferred with a noted reason)
Collision probe run, key-free: check-new-skill-collision.mjs --skill={name} --emit-tasks, then dispatch the pm-skill-router sub-agent (Haiku) over the emitted queries and apply the verdict; the new skill recalls its triggers and steals none of a neighbor’s. (Unattended CI may instead use the Messages-API path with ANTHROPIC_API_KEY.)