Run any Skill in Manus with one click

create-ticket

Stars3

Forks0

UpdatedJune 24, 2026 at 08:29

Create or update a GitHub issue for easy-zeebe using the `gh` CLI. Use when the user asks to "file a bug", "create a feature request", "open a GitHub issue", or "update an existing one". Supports feature, bug, and refactor issue types with structured templates; shows a draft for confirmation before creating or editing; looks up existing issues by number or URL for updates.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

emaarco

emaarco/easy-zeebe

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	create-ticket
argument-hint	[feature\|bug\|refactor] "<description>" \| update <issue-number-or-url>
allowed-tools	Bash(gh *)
description	Create or update a GitHub issue for easy-zeebe using the `gh` CLI. Use when the user asks to "file a bug", "create a feature request", "open a GitHub issue", or "update an existing one". Supports feature, bug, and refactor issue types with structured templates; shows a draft for confirmation before creating or editing; looks up existing issues by number or URL for updates.

Skill: create-ticket

Create or update a GitHub issue for this repository (feature request, bug report, or refactor task).

IMPORTANT

Always use gh-cli to create or update tickets.
Never call the api directly.
If gh-cli not available, abort the execution and ask the user to install it. The user must restart the skill then
When any gh call fails, ask the user what to do (repeat, stop, do something else)
Never hard-wrap body text. Every paragraph and list item must be a single unbroken line. Do NOT insert line breaks in the middle of a sentence to stay within 80 characters. GitHub renders markdown — let it wrap.

Instructions

Step 1 – Determine mode

Inspect $ARGUMENTS:

If context contains update and/or an issue number or GitHub issue URl, use update-mode
Otherwise use create-mode
If create mode, does not make sense based on your context, as well, use AskUserQuestion to ask the user, to add more context, about what to do.

Step 2 – Gather information

For a new issue:

Extract the issue type (feature, bug, refactor) from $ARGUMENTS; if missing, ask the user
For feature: understand the desired behaviour and why it is needed
For bug: understand the current vs. expected behaviour and reproduction steps
For refactor: understand the scope, motivation, and target state

For an issue that needs to be updated

Fetch the issue using gh issue view <number-or-url>

Step 3 – Research (optional)

If the issue involves a specific library, framework version, API, or configuration that you are not fully certain about, use AskUserQuestion to ask: "Should I search online for [topic] to get accurate details (e.g. exact property names, migration guides) before drafting?" If yes, use WebSearch / WebFetch to collect relevant facts, then incorporate them into the draft. Skip this step if you already have sufficient knowledge.

Step 4 – Draft

Draft the issue using the matching template from the Templates section below.

Step 5 – Confirm with AskUserQuestion

Use AskUserQuestion to present the full draft and ask the user to confirm before proceeding. Show the title, label, and full body in the question text. Offer three options: proceed, edit (ask what to change), or cancel. If the user requests edits, apply them and ask again via AskUserQuestion until confirmed or cancelled.

Step 6 – Create or update

Using the GitHub CLI:

Create: gh issue create --title "<title>" --body "<body>" --label "<label>"

Update (use whichever commands apply):

gh issue edit <number> --title "<title>" --body "<body>"
gh issue edit <number> --add-label "<label>" --remove-label "<label>"
gh issue comment <number> --body "<comment>"
gh issue close <number>
gh issue reopen <number>

Step 7 – Report

Run gh issue view <number> and show the final issue state with its URL.

Templates

Feature Request

**Title**: [Feature]: <short imperative title>
**Label**: enhancement

**Body**:
## Summary
<One sentence describing the desired feature>

## Motivation
<Why is this feature needed? What problem does it solve?>

## Proposed Solution
<How should the feature work? Include Zeebe/process details where relevant>

## Acceptance Criteria
- [ ] <criterion 1>
- [ ] <criterion 2>

Bug Report

**Title**: [Bug]: <short description of the broken behaviour>
**Label**: bug

**Body**:
## Description
<What is going wrong?>

## Steps to Reproduce
1. <step 1>
2. <step 2>

## Expected Behaviour
<What should happen>

## Actual Behaviour
<What actually happens>

## Environment
- Java version:
- Zeebe / Camunda version:
- Module affected:

Refactor

**Title**: [Refactor]: <short description of the change>
**Label**: refactor

**Body**:
## Summary
<What will be refactored and why?>

## Current State
<Describe the current implementation and its shortcomings>

## Target State
<Describe what the code should look like after the refactor>

## Out of Scope
<What will NOT be changed>

More from this repository

same repository

verify-model-visually

emaarco/easy-zeebe

Use while modeling a BPMN process to review a model you just edited. Runs both quality nets — the deterministic bpmnlint geometry linter and a visual review of the rendered image — and reports a combined verdict. Catches invisible elements, overlaps, crossing flows, flows routed through a shape (lint), plus messy or hard-to-read layout that needs judgment (image). Use after editing a model, or when asked to review the diagram, check the layout, or verify the model looks right.

2026-06-293

fix-model-layout

emaarco/easy-zeebe

Use while modeling a BPMN process to fix the layout problems that the BPMN linter or /verify-model-visually report — crossing flows, overlaps, flows routed through shapes, invisible or messy elements. Re-routes the affected edges deterministically, edits the diagram coordinates, or regenerates the whole layout — touching only the diagram, never the executable process. The fixing counterpart to verify-model-visually. Trigger phrases: "fix the layout", "fix the crossing flow", "repair the diagram", "clean up the BPMN layout", "auto-fix the model".

2026-06-253

automate-process

emaarco/easy-zeebe

Generate full hexagonal glue-code for a Zeebe BPMN process across all five layers — inbound workers, inbound/outbound port interfaces, application services, and a process out-adapter. Use when the user asks to "automate a process", "generate glue-code for a BPMN process", or "scaffold workers and adapters". Accepts a ProcessApi file, a BPMN model, or a plain description; skips files that already exist; optionally runs the review-process audit first.

2026-06-243

create-adr

emaarco/easy-zeebe

Write a new Architectural Decision Record (ADR) for this project in MADR format with interactive content gathering and user confirmation before writing. Use when the user asks to "write an ADR", "create an architectural decision record", or "document a design decision". Auto-numbers from the existing ADR index, derives the filename slug from the title, and shows a full draft for review before writing the file.

2026-06-243

create-persistence-adapter

emaarco/easy-zeebe

Scaffold or update a complete JPA persistence adapter (outbound adapter) — entity, JPA repository, mapper, and adapter class — for a domain aggregate. Use when the user asks to "create a persistence adapter", "generate a JPA adapter", "scaffold the persistence layer", or "create an outbound db adapter". Accepts a repository port file or domain entity; generates all four files at once; updates existing files by adding missing methods or fields.

2026-06-243

create-process-adapter

emaarco/easy-zeebe

Create or update a Zeebe process out-adapter (outbound adapter) that calls the process engine via `startProcess`, `sendMessage`, and `sendSignal`. Use when the user asks to "create a process adapter", "generate the outbound Zeebe adapter", "wire up the process port", or "add a process out-adapter for a BPMN process". Accepts a ProcessApi file, a BPMN model, or a plain description; updates existing adapters by adding missing methods and correcting stale constant references.

2026-06-243

name	create-ticket
argument-hint	[feature\|bug\|refactor] "<description>" \| update <issue-number-or-url>
allowed-tools	Bash(gh *)
description	Create or update a GitHub issue for easy-zeebe using the `gh` CLI. Use when the user asks to "file a bug", "create a feature request", "open a GitHub issue", or "update an existing one". Supports feature, bug, and refactor issue types with structured templates; shows a draft for confirmation before creating or editing; looks up existing issues by number or URL for updates.

Skill: create-ticket

Create or update a GitHub issue for this repository (feature request, bug report, or refactor task).

IMPORTANT

Always use gh-cli to create or update tickets.
Never call the api directly.
If gh-cli not available, abort the execution and ask the user to install it. The user must restart the skill then
When any gh call fails, ask the user what to do (repeat, stop, do something else)
Never hard-wrap body text. Every paragraph and list item must be a single unbroken line. Do NOT insert line breaks in the middle of a sentence to stay within 80 characters. GitHub renders markdown — let it wrap.

Instructions

Step 1 – Determine mode

Inspect $ARGUMENTS:

If context contains update and/or an issue number or GitHub issue URl, use update-mode
Otherwise use create-mode
If create mode, does not make sense based on your context, as well, use AskUserQuestion to ask the user, to add more context, about what to do.

Step 2 – Gather information

For a new issue:

Extract the issue type (feature, bug, refactor) from $ARGUMENTS; if missing, ask the user
For feature: understand the desired behaviour and why it is needed
For bug: understand the current vs. expected behaviour and reproduction steps
For refactor: understand the scope, motivation, and target state

For an issue that needs to be updated

Fetch the issue using gh issue view <number-or-url>

Step 3 – Research (optional)

Step 4 – Draft

Draft the issue using the matching template from the Templates section below.

Step 5 – Confirm with AskUserQuestion

Step 6 – Create or update

Using the GitHub CLI:

Create: gh issue create --title "<title>" --body "<body>" --label "<label>"

Update (use whichever commands apply):

gh issue edit <number> --title "<title>" --body "<body>"
gh issue edit <number> --add-label "<label>" --remove-label "<label>"
gh issue comment <number> --body "<comment>"
gh issue close <number>
gh issue reopen <number>

Step 7 – Report

Run gh issue view <number> and show the final issue state with its URL.

Templates

Feature Request

**Title**: [Feature]: <short imperative title>
**Label**: enhancement

**Body**:
## Summary
<One sentence describing the desired feature>

## Motivation
<Why is this feature needed? What problem does it solve?>

## Proposed Solution
<How should the feature work? Include Zeebe/process details where relevant>

## Acceptance Criteria
- [ ] <criterion 1>
- [ ] <criterion 2>

Bug Report

**Title**: [Bug]: <short description of the broken behaviour>
**Label**: bug

**Body**:
## Description
<What is going wrong?>

## Steps to Reproduce
1. <step 1>
2. <step 2>

## Expected Behaviour
<What should happen>

## Actual Behaviour
<What actually happens>

## Environment
- Java version:
- Zeebe / Camunda version:
- Module affected:

Refactor

**Title**: [Refactor]: <short description of the change>
**Label**: refactor

**Body**:
## Summary
<What will be refactored and why?>

## Current State
<Describe the current implementation and its shortcomings>

## Target State
<Describe what the code should look like after the refactor>

## Out of Scope
<What will NOT be changed>