// Create a Jira ticket in CMK with component, team, and epic matched from compass and roadmap data
Use when reviewing tests or test changes in a diff, pull request, or merge request. Triggers on assessing test quality, spotting test anti-patterns, or evaluating whether an assertion earns its place.
Generate the periodic "unsolved Checkmk check crashes on 2.4+" Slack rollup, grouped by component owner. Composes the crash-report and component-owners skills and emits Slack-ready plain text (no markdown).
Queries and reads crash reports from crash.checkmk.com
Fetch and display a Jira ticket's description, comments, attachments, and linked tickets
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
Interacts with Gerrit code review to list changes and improve them
| name | jira-create-ticket |
| description | Create a Jira ticket in CMK with component, team, and epic matched from compass and roadmap data |
Creates a Jira ticket in the CMK project. Guesses the component and developer team by querying the compass JSON endpoint. Searches for a matching roadmap epic to link to.
JIRA_API_TOKEN - Jira API tokenThe user provides a rough description of what the ticket should be about. This can be free-form text.
Analyze the user's input and automatically infer the issue type:
Never create Stories. If ambiguous, default to Task.
From the user's rough description, draft the following fields:
CMKCMK-12345)Choose the template based on the inferred issue type. Rules that apply to ALL templates:
{panel:title=Acceptance Criteria|titleBGColor=#15d1a0}
* <criterion 1>
* <criterion 2>
* <criterion 3>{panel}
h3. Steps to reproduce
# <step 1>
# <step 2>
h3. Observed behavior
<describe the behavior that is observed>
h3. Expected behavior
<describe the behavior that is expected>
h3. Root cause
Currently the root cause is unknown.
h3. Additional resource / Screenshots
<links, screenshots, or other resources if helpful>
{panel:title=What needs to be done?|titleBGColor=#77bce4}
*As a* <role>
*I want to* <goal>
*so that* <benefit>
{panel}
{panel:title=Acceptance Criteria|titleBGColor=#15d1a0}
* <criterion 1>
* <criterion 2>
* <criterion 3>{panel}
h3. In-Depth Description
<detailed description of what needs to be done>
h3. Design Information
<screenshots, design mockups, Figma links>
h3. Technical Information
<links to relevant technical information>
h3. Additional information
<misc info, e.g. who could be consulted>
Rules specific to Task:
Fetch the full component list from the compass endpoint:
.venv/bin/python .github/skills/jira-create-ticket/create_ticket.py \
--summary "<drafted summary>" \
--guess
This returns a JSON array of all ~220 components, each with name, teams, and optionally description. Review the list and pick the component that best matches the ticket's topic. Use the first team listed for that component as the developer team. If no component is a clear match, leave both empty and let the user decide.
Fetch all open roadmap epics:
.venv/bin/python .github/skills/jira-create-ticket/create_ticket.py \
--find-epics \
--summary "<drafted summary>"
This returns a JSON array of all open epics in the roadmap hierarchy (rooted at CMK-24875: Roadmap Ticket -> Business Goal -> Initiative -> Epic), each with key, summary, status, components, team. Review the list and pick the epic that best matches the ticket's topic.
Roadmap vs Component work: Checkmk uses a roadmap hierarchy: Roadmap Ticket -> Business Goal -> Initiative -> Epic -> Task/Bug. Tickets that belong to ongoing roadmap work should be linked to their epic. However, many tickets are standalone "component work" (bug fixes, small improvements, tech debt) that do NOT belong to any roadmap epic. No link is a perfectly valid choice.
Evaluate the results:
This step applies only when the issue type is Bug; skip it otherwise.
The Bug detection field records where the bug was caught. Use AskUserQuestion to ask the user, offering the options listed in bug_detection.md as bullet points.
Any selected value other than "None" is later passed to the create script via --bug-detection.
Always ask the user. Do not pick a default unless the user has explicitly told you which option to use.
Present a summary of ALL fields to the user using AskUserQuestion and ask for confirmation. The user MUST approve the ticket content before creation. Show:
If the user wants changes, incorporate them and verify again.
Once confirmed, run:
.venv/bin/python .github/skills/jira-create-ticket/create_ticket.py \
--summary "<summary>" \
--description "<description>" \
--issue-type "<type>" \
--project "<project>" \
[--component "<component>"] \
[--developer-team "<team>"] \
[--link-epic "<epic key>"] \
[--bug-detection "<value>"] \
[--priority "<priority>"] \
[--parent "<parent>"]
The script outputs a line like Created: CMK-32430 — https://jira.lan.tribe29.com/browse/CMK-32430. Parse the issue key and URL from it and present a clickable markdown link to the user:
Created [CMK-32430](https://jira.lan.tribe29.com/browse/CMK-32430)
If an epic was linked, also mention it.
--dry-run flag prints the payload without creating the ticket.jira library). Configure it via JIRA_API_TOKEN environment variable.--link-epic sets the Epic Link field on the new ticket, making it a child of the specified epic.--find-epics searches open epics filtered by component and ranked by keyword match against the summary.