Agent Skills for Product Managers: Repeatable Product Work

Use skills for repeatable procedure

Product management contains recurring workflows—problem synthesis, interview analysis, specification review, experiment planning, launch readiness, and decision records—but the inputs and decisions remain contextual. An Agent Skill can standardize how evidence is gathered and transformed without deciding strategy by fiat.

The Agent Skills specification defines a portable SKILL.md plus optional scripts, references, and assets. The OpenAI skills guide and Claude Code skills guide explain current client discovery and activation. Keep the reusable method in the skill and keep live company data behind the host's authorized tools.

A useful product skill says exactly which recurring job it supports and which artifact it produces. “Help with product management” is too broad to activate reliably or evaluate.

Pick a narrow workflow

Start with a task that has recognizable inputs and a stable output. Good candidates include:

• Synthesize interview notes into observed problems and open questions.
• Turn approved requirements into a reviewable product brief.
• Audit a draft specification for missing states, constraints, and metrics.
• Prepare an experiment plan from a stated hypothesis.
• Build a launch-readiness checklist from an approved scope.
• Convert a completed decision into a durable decision record.

Do not combine discovery, prioritization, specification, execution tracking, and launch approval into one giant skill. Separate skills are easier to trigger, review, and maintain.

Declare inputs and authority

For each workflow, distinguish:

1. Source evidence: interviews, tickets, analytics, research, policies, and existing decisions.
2. Working assumptions: statements allowed for exploration but not yet verified.
3. Decision rights: the person or group authorized to choose scope, priority, metric, launch, or customer commitment.
4. Output: the artifact the skill may draft.
5. Stopping conditions: missing evidence or authority that requires a question.

A skill may organize options and consequences. It should not silently turn an inference into a roadmap promise, invent customer demand, or present a generated priority as an approved decision.

Design an evidence ledger

Product artifacts become unreliable when observations, interpretations, and decisions blend together. Require the skill to label each material statement:

• Observed: directly supported by a named source.
• Calculated: derived from visible inputs and a reproducible method.
• Inferred: a plausible explanation that needs validation.
• Proposed: an option for consideration.
• Decided: explicitly approved by the authorized owner.
• Unknown: not established by the available evidence.

Preserve links, dates, segments, and sample sizes when provided. Never manufacture quotes, counts, metrics, or attribution. When sources conflict, show the conflict instead of averaging it away.

Build the artifact as a template

Place stable templates in assets/ or references/ rather than expanding SKILL.md indefinitely. A product brief template might include:

1. Problem and affected audience.
2. Evidence and confidence.
3. Desired outcome and non-goals.
4. Proposed scope and important states.
5. Constraints, dependencies, and risks.
6. Measurement plan and guardrails.
7. Open questions and named decision owners.
8. Approval status and change history.

The skill should omit empty decorative sections only when the template allows it; it should not fill gaps with plausible prose. Missing information is an output.

Separate workflow from live integrations

A skill supplies the method. MCP servers or other tools may supply current tickets, analytics, documents, or research. If the workflow needs both, make the boundary visible:

• The skill defines which sources to request and how to reconcile them.
• The tool or server enforces authentication and access.
• Retrieved content remains untrusted input.
• Writes back to a tracker, roadmap, or document require separate authorization.

Do not embed credentials in the skill. Do not assume that access to one project grants permission to summarize another, or that read access grants authority to update priority or status.

Handle customer research carefully

For interview or feedback synthesis:

1. Preserve the difference between a participant's words and the analyst's interpretation.
2. Track repeated themes without implying statistical representativeness.
3. Include disconfirming evidence and meaningful variation.
4. Redact or exclude sensitive personal data before model processing.
5. Link findings to source records where policy permits.
6. Keep proposed actions separate from observed needs.

A polished summary can still be wrong. The skill should make traceability easier than rhetoric.

Make prioritization transparent

If a skill calculates a prioritization score, document the formula, inputs, time horizon, and missing values. Show the component scores rather than only the rank. Treat the result as decision support, not an objective truth.

Avoid silently substituting repository popularity, ticket volume, or a model's confidence for customer value. Metrics are proxies with failure modes. Record who approved the final priority and why the team accepted or overrode the calculated order.

Protect consequential actions

Drafting is different from publishing. Keep explicit approval around:

• Changing roadmap priority or committed dates.
• Updating issue status or assigning work.
• Sending customer or executive communications.
• Publishing research, specifications, or release notes.
• Starting an experiment or changing production configuration.
• Deleting or merging source records.

The skill can prepare the exact proposed mutation and a preview. The host and external system should enforce the permission boundary.

Evaluate with representative cases

Test the skill on:

1. Complete evidence with a straightforward output.
2. Contradictory research that must stay unresolved.
3. Missing metrics where the skill should ask rather than invent.
4. Sensitive source material that should be excluded or redacted.
5. A request to publish or reprioritize without authority.
6. A nearby task that should not trigger the skill.

Review factual traceability, unsupported claims, template completeness, decision-boundary compliance, and usefulness to the next human reviewer. Update the skill when product policy, templates, tools, or client behavior changes.

A practical skill checklist

Before adopting a product-management skill, verify:

• A narrow trigger and named output.
• Required and optional inputs.
• Evidence labels and citation rules.
• Explicit decision owners and stopping conditions.
• A versioned template and change history.
• Safe handling of customer and company data.
• Separate approval for external writes and commitments.
• Examples with both complete and missing evidence.
• A maintenance owner and review date.

The best product skill makes reasoning inspectable. It reduces repetitive assembly while keeping uncertainty, accountability, and final product judgment visible.