PM

Classifies work type and produces a structured product brief with acceptance criteria.

2|Updated Apr 26, 2026
One-click install
npx skills add https://github.com/anderson-joyle/claude-a-team --skill pm-anderson-joyle
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: PM
Source: https://github.com/anderson-joyle/claude-a-team/tree/main/skills/pm
Command: npx skills add https://github.com/anderson-joyle/claude-a-team --skill pm-anderson-joyle

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It converts an ambiguous software request into a structured product brief that makes scope, constraints, and measurable acceptance criteria explicit, reducing misalignment across downstream roles.

Core Features & Use Cases

  • Work type and problem framing: Classifies the work type and writes a precise problem statement plus current vs expected behavior.
  • Structured acceptance criteria: Produces acceptance criteria as stable, ID-based structured objects suitable for verification.
  • Evidence-backed clarity: Grounds decisions in provided artifacts and evidence, and raises blocking questions when evidence conflicts with the user description.

Quick Start

Use the PM skill when you need to produce a structured product brief with acceptance criteria from a normalized intake request and supporting evidence.

Frequently Asked Questions about PM

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I turn an ambiguous software request into structured acceptance criteria?

Acceptance criteria for software requirements should be structured as stable, ID-based objects suitable for verification. This approach ensures that work type classification and problem framing are explicit, and surfaces blocking questions when supporting evidence conflicts with the request description.

How do I define scope and constraints for a new software engineering workflow?

To define scope and constraints, classify the work type and articulate a precise problem statement comparing current versus expected behavior. This produces a structured product brief making scope, constraints, and measurable acceptance criteria explicit to reduce downstream misalignment.

What is the best way to surface blocking questions when evidence conflicts with a software request?

Ground decisions in provided artifacts and evidence during the intake process to identify inconsistencies. When evidence conflicts with the user description, the system raises these discrepancies as explicit blocking questions before finalizing scope and acceptance criteria.

Does generating a product brief require a normalized intake request and supporting evidence?

Yes, producing a structured product brief requires a normalized intake request and supporting evidence. The process classifies work type and defines scope by grounding decisions in these provided artifacts, ensuring inconsistencies are surfaced as blocking questions before proceeding.

How do I output a structured product brief using a shared artifact envelope?

Set the artifact_type to pm_output and assign the body to PMOutputBody within the shared artifact envelope. You must preserve the request_id, schema_version, and relevant parent_artifact_ids to maintain proper artifact tracking and schema integrity throughout the workflow.