ワンクリックでManusで任意のスキルを実行

create-ticket

スター8

フォーク0

更新日2026年4月22日 21:16

Create or update a GitHub issue for bpmn-to-code 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で実行

ソース

Miragon

Miragon/bpmn-to-code

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).

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, use AskUserQuestion to ask the user for more context.

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; ask about plugin version, build tool (Gradle/Maven), process engine (Camunda 7/Zeebe/Operaton), and output language (Kotlin/Java) if relevant.
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, ask the user: "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

Read the matching issue template from .github/ISSUE_TEMPLATE/ to get the exact sections and labels:

feature → .github/ISSUE_TEMPLATE/feature_request.yml
bug → .github/ISSUE_TEMPLATE/bug_report.yml
refactor → .github/ISSUE_TEMPLATE/refactoring.yml

Extract the title prefix, labels, and every textarea/input/dropdown field (label + description) from the YAML to compose the issue body. Fill each section with the information gathered in Step 2.

Step 5 – Show and confirm

Use AskUserQuestion to present the full draft (create) or the current state + proposed changes (update) and ask whether to proceed, edit, or cancel. Apply any requested edits and ask again before continuing.

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 – Create and link a branch

Only for create-mode (skip for updates if the issue already has a linked branch):

Branch name: <type>/issue-<number> — e.g. fix/issue-39 or feat/issue-120
- Use the same type as the issue label (fix for bugs, feat for features, refactor for refactors)
Detect the default development branch (prefer develop over main/master):
```
gh api repos/<owner>/<repo>/branches --jq '.[].name'
```
Create the branch and link it to the issue:
```
gh issue develop <number> --repo <owner>/<repo> --name <branch> --base <dev-branch>
```
This creates the branch AND links it to the issue (visible in the issue's Development sidebar).

Step 8 – Report

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

このリポジトリの他の Skills

同じリポジトリ

create-unit-test

Miragon/bpmn-to-code

Write or refactor unit tests following the canonical project pattern. Use when adding new unit tests or standardizing existing ones.

2026-07-218

generate-rule-to-enforce-bpmn-styleguide

Miragon/bpmn-to-code

Generate a Kotlin SingleModelValidationRule implementation for ONE rule from BPMN_STYLE_GUIDE.md. Use when drafting / iterating on a single rule, or when the user asks to 'generate a rule for <slug>', 'create the element-id-format rule', or 'add just this one rule to the test module'. For all rules at once, use generate-rules-to-enforce-bpmn-styleguide.

2026-07-208

generate-rules-to-enforce-bpmn-styleguide

Miragon/bpmn-to-code

Generate Kotlin SingleModelValidationRule implementations for every deterministic (or hybrid) rule in BPMN_STYLE_GUIDE.md, so they can be enforced at test time by the bpmn-to-code-testing module. llm-only rules stay in the style guide for /validate-bpmn-style. Use when the user asks to 'generate validation rules from the style guide', 'enforce BPMN conventions in CI', or 'automate style checks in tests'. For a single rule, use generate-rule-to-enforce-bpmn-styleguide.

2026-07-208

build-bpmn-styleguide

Miragon/bpmn-to-code

Interactively author a BPMN_STYLE_GUIDE.md for your project — a handbook that explains how the team models BPMN processes (naming, allowed elements, IDs, topics, engine-specific special cases). The output is a document humans can read; embedded YAML annotations let downstream skills enforce the rules. Use when the user asks to 'create a BPMN style guide', 'set up BPMN conventions', or 'define BPMN naming rules'.

2026-07-178

create-process-service

Miragon/bpmn-to-code

Create a complete Spring Boot service project from a BPMN file with hexagonal architecture. Bootstraps via Spring Initializr, configures bpmn-to-code, and generates workers, use cases, and services wired to ProcessApi constants — no raw strings anywhere. Use when the user wants to start a new process service from a BPMN model.

2026-06-178

migrate-bpmn-to-code-v1-to-v2

Miragon/bpmn-to-code

Migrate generated API usage from bpmn-to-code v1.1.0 to v2.0.0. Use when the user asks to 'upgrade to v2', 'migrate from v1 to v2', 'fix TaskTypes references', or 'update bpmn-to-code API calls after upgrade'.

2026-06-178

name	create-ticket
argument-hint	[feature\|bug\|refactor] "<description>" \| update <issue-number-or-url>
allowed-tools	Bash(gh *), AskUserQuestion
description	Create or update a GitHub issue for bpmn-to-code 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).

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, use AskUserQuestion to ask the user for more context.

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; ask about plugin version, build tool (Gradle/Maven), process engine (Camunda 7/Zeebe/Operaton), and output language (Kotlin/Java) if relevant.
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

Read the matching issue template from .github/ISSUE_TEMPLATE/ to get the exact sections and labels:

feature → .github/ISSUE_TEMPLATE/feature_request.yml
bug → .github/ISSUE_TEMPLATE/bug_report.yml
refactor → .github/ISSUE_TEMPLATE/refactoring.yml

Step 5 – Show and confirm

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 – Create and link a branch

Only for create-mode (skip for updates if the issue already has a linked branch):

Branch name: <type>/issue-<number> — e.g. fix/issue-39 or feat/issue-120
- Use the same type as the issue label (fix for bugs, feat for features, refactor for refactors)
Detect the default development branch (prefer develop over main/master):
```
gh api repos/<owner>/<repo>/branches --jq '.[].name'
```
Create the branch and link it to the issue:
```
gh issue develop <number> --repo <owner>/<repo> --name <branch> --base <dev-branch>
```
This creates the branch AND links it to the issue (visible in the issue's Development sidebar).

Step 8 – Report

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