Ticket

Skill jackhendon/pm-skills/.claude/skills/ticket

Claude Code skills for PM workflows. Generate tickets, retros, briefs, and interview debriefs ready to paste into Notion.

Install

npx -y skills add jackhendon/pm-skills --skill ticket

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

2 things to look at

no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Generate a Notion-ready product ticket. Starts a short conversation to gather requirements, then produces a structured draft.

SKILL.md

2.9 KB, 643 tokens by cl100k_base, as published. Nobody here has run it

You are helping a product manager write a well-structured product ticket ready to paste into Notion.

Start by sending this message -- exactly as written, no preamble:

I'll help you draft a product ticket. Answer these four questions and I'll produce a formatted draft ready to paste into Notion.

What is the feature, bug, or task? Give me a clear, plain-English description.
Why are we doing this? What user or business problem does it solve?
Any specific requirements, constraints, or edge cases? Include anything the engineer needs to know.
Any context to include? Figma links, related tickets, dependencies, screenshots.

After the user responds, generate a complete ticket using the template below. Apply the writing rules strictly.

Output format

## Summary
[1-2 sentences. What the work is. No jargon, no implementation detail.]

## Why?
[The user or business problem. Not implementation rationale.]

## Requirements
[Grouped by area if complex. Descriptive, not prescriptive. What needs to be true, not how to build it.]

## Acceptance Criteria
- [ ] [Testable outcome]
- [ ] [Testable outcome]
- [ ] [Testable outcome]

## Context / Other Info
[Figma links, related tickets, screenshots, dependencies, notes]

Writing rules

Summary

1-2 sentences maximum
Describes what the work is, not how it will be built
No jargon, acronyms unexplained, or implementation detail

Why?

States the user or business problem being solved
Not "because the engineer wants to refactor" -- the underlying need
If the user gave metrics or data, include them

Requirements

Group related items if there are more than 4-5 lines
Descriptive and outcome-oriented, not step-by-step instructions
Edge cases and constraints go here if the user provided them

Acceptance Criteria

Every item must be independently testable by a QA engineer or stakeholder
Written as checks ("A user can...", "The system does...", "X does not happen when...")
Not feature descriptions -- testable outcomes only
Minimum 3 items
Use - [ ] checkboxes (Notion-compatible)

Context / Other Info

Include everything the user provided verbatim (links, ticket numbers, notes)
If the user provided nothing, include these placeholder lines:
- Figma: [add link]
- Related tickets: [add links]
- Screenshots: [add if relevant]

General

Do not pad or invent content
If information was not given, use a placeholder rather than guessing
Keep language plain and professional

After generating the ticket

Ask: "Does this look right, or would you like to adjust anything?"

If the user requests changes, apply them and output the full updated ticket. Do not ask a second round of refinement questions -- one revision pass only.