Ticket writer

Pick the right ticket type, then fill in only the fields that type needs. A story is not a bug, and an epic is not an initiative. Each type has its own audience, scope, and definition of done. Mixing them produces vague tickets that nobody can act on and that bloat the backlog.

Core Principles

Type hierarchy and selection

Tickets form a hierarchy. Pick the highest level where the work still has a single, coherent purpose.

Initiative  (multi-quarter strategic outcome)
  Epic      (quarter-scale goal, one product area)
    Story   (sprint-scale user-visible value)
      Subtask  (implementation slice of a story)
    Bug     (defect against current behaviour)
    Issue   (anything else - chore, spike, question)

When to use each type

Type decision tree

1. Is this a deviation from intended behaviour? -> Bug
2. Is this a strategic goal spanning multiple teams or quarters? -> Initiative
3. Is this a large body of work that needs to be broken down but belongs to one product area? -> Epic
4. Is this user-visible value that fits in a sprint? -> Story
5. Is this an implementation slice of an existing story? -> Subtask
6. None of the above (chore, spike, investigation, tech debt, question)? -> Issue

Workflow

Phase 1: Type selection

If the user provided a type as an argument, use it. Otherwise present a selectable menu (use AskUserQuestion or the platform's equivalent interactive prompt) listing the six types with their one-line descriptions from the table above. Never dump the full table as plain text. Keep the menu compact.

If the user's intent is clear from context (e.g., they said "write a bug report" or "create an epic for checkout redesign"), skip the menu and confirm the inferred type with a single yes/no prompt.

Phase 2: Load the type-specific reference

Read the matching reference file for the selected type:

Each reference contains:

• The required fields
• The optional fields
• A field-by-field questionnaire (questions, options, follow-ups)
• The output template
• Quality checks specific to that type

Phase 3: Run the Questionnaire

Ask only the questions the reference lists for the selected type. Rules:

1. Batch compatible questions (3-4 per prompt) when using an interactive menu tool. Use free-text prompts only when the answer is truly free-form (title, description, reproduction steps).
2. Skip optional fields silently if the user says "skip" or leaves them blank. Do not add empty placeholders.
3. Follow up on ambiguous answers. If the user says "it's slow", ask "slow compared to what, and by how much?"
4. Never invent facts. If the user cannot provide environment info, reproduction steps, or metrics, leave those fields out and note the gap in a ## Open Questions section rather than fabricating values.

Phase 4: Assemble the ticket

Use the type's output template. Apply these formatting rules to every type:

• Title: Imperative mood for stories/subtasks/issues ("Add password reset via email"), descriptive for bugs ("Payment confirmation email not sent after successful charge"), outcome-oriented for epics/initiatives ("Reduce checkout abandonment by 30%").
• Body: Markdown with section headings. No emojis unless the user explicitly requests them.
• Labels: Suggest labels based on type and content (e.g., bug, severity:high, area:checkout).
• Links: Leave placeholders for parent epic / related tickets / PRs rather than inventing IDs.

Phase 5: Quality check

Before showing the final output, run the checks listed in the type's reference file. Common failures to catch:

Phase 6: Deliver

Show the final ticket to the user in a code block so they can copy-paste it. Then offer:

1. Edit a field
2. Change the type (if the content no longer fits)
3. Write a related ticket (e.g., a story under the epic just written)
4. Done

Quick reference: field matrix

Which fields are required (R), optional (O), or not used (-) per type.

Integration with other skills

Reference files