jira-ticket

Use the jira CLI to create, update, and manage Jira tickets.

Standard Operation Procedures

Choose:

Ticket Creation

Use the type 'Story', unless explicitly specified by the user to use 'Epic'. See Context below for details about each type.
Write clear, concise summaries
Optionally add label ai-ready IF AND ONLY IF the ticket is detailed enough that it can be implemented by an AI agent or if the ticket's plan was written by an agent.
Use present tense.
Write ticket as if the work is to be done.
Summary starts with the name of the repo in square brackets: [REPO-NAME]
Craft detailed descriptions including:
Problem statement or feature description
Expected work product
Technical details when relevant
Use the Jira Text Formatting language:
Use {{monospace}} instead of {code}..{code} for inline code.
Code blocks should specify the language: {code:language} some code {code} .

Context

Ticket can be one of:

If not specified, assume "Story".

GLOBAL RULES FOR FIELDS:

If a [MANDATORY] item is not provided, STOP and ASK.
For ANY [OPTIONAL] field (like Sprint, Points, or Assignee), if the user does not EXPLICITLY provide a value, you MUST leave it blank. DO NOT guess, DO NOT default to 'active', and DO NOT infer from context.
If Assignee is specified as "me", assume user specified by the environment variable USER .

Epic creation:

Work classification [MANDATORY]: possible values: A (sustaining), B (engineering excellence) or C (product).
Capitalizable? [MANDATORY]: possible values: yes or no.
Assignee [MANDATORY]

Story creation:

Bug creation:

Sprint can be specified as "current", "active", "next", "future", etc. in which case use the jira sprints commands to find the one.

Ticket Updates

Template

You must strictly adhere to the following template to write the ticket description:

h3. Description

Work needed. Be as detailed as possible to allow coworkers to points the level of effort needed.
DO NOT make a judgement call on the level of effort itself, only describe it.

h3. Expected work product

Is this a code change? If so, provide the URL of the repository.
Is the output a document? If so what type:
- Google Docs?
- Jupyter/Quarto Notebook?
Keep this section real simple.

h3. Acceptance Criteria

NOTE: do not mention code reviews, these always happen.

h3. Out of Scope

h3. Any background context you want to provide

h3. Plan

if you are provided with a plan, copy it here, as is.

CLI Usage Patterns:

Use jira issues to list all tickets
Use jira issues --current-sprint --mine to list user's ticket in current sprint.
Use jira issues --epics-only to list epics only
Use jira issues --programs-only to list programs only
Use jira issues --in-epic <EPIC> to list issues in epic
Use jira sprints to list sprints
Use jira view <TICKET> to view a ticket.
Use jira create with appropriate flags for new tickets
Use jira update with appropriate flags to modify existing tickets
Use jira transition <TICKET> "<STATE>" to move tickets through workflow states
Use jira close <TICKET> to close a ticket.

Best Practices

Be precise and technical when documenting issues
Acknowledge successful operations with ticket numbers (use jira issues to find newly create ticket).
NEVER use superlative terms like comprehensive.
CRITICAL: do not mention brainstorming files by name, rather attached the brainstorming document to the ticket (using --attach <filename> )

Source Transparency