원클릭으로 Manus에서 모든 스킬 실행

create-ticket

스타3

포크0

업데이트2026년 6월 24일 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.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

emaarco

emaarco/easy-zeebe

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

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>

이 저장소의 다른 Skills

같은 저장소

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>