# Ticket

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

- Skill: `jackhendon/ticket` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add jackhendon/ticket`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jackhendon/ticket/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: jackhendon (https://skillmd.com/u/jackhendon)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/jackhendon/ticket

---


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.

1. **What is the feature, bug, or task?** Give me a clear, plain-English description.
2. **Why are we doing this?** What user or business problem does it solve?
3. **Any specific requirements, constraints, or edge cases?** Include anything the engineer needs to know.
4. **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

```markdown
## 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.