-
Resolve the repo. Default kymostudio/kymostudio. Confirm with:
gh repo view --json nameWithOwner -q .nameWithOwner
-
Pick the template + read its current fields. This repo ships GitHub issue
forms under .github/ISSUE_TEMPLATE/. The body MUST mirror the fields of the
matching template (one ## <Label> heading per form field, same order). gh issue create --body does NOT apply forms, so reproduce them by hand. Classify the
request:
- bug / something broken →
bug_report.yml → apply label bug.
- idea / enhancement / "should be able to" →
feature_request.yml → set the
Issue Type Feature (org-level type, NOT a label — this template carries
type: Feature and no enhancement label).
Always Read the chosen YAML first (do not hardcode from memory — fields drift) and
use its label: value and its body[].attributes.label strings verbatim. As of
this writing they are:
Affected-package options (same list in both forms): python / js /
rust / core engine / editor / vscode-extension / mcp / api / website /
icons / mobile / desktop-app / docs.
# bug_report.yml (label: bug)
## Affected package — one of the options above
## Version — package version or git commit (use "main @ <short-sha>" if unknown)
## What happened? — what the user did and what went wrong (include URL if any)
## Reproduction — minimal .kymo/.bpmn source + command, if applicable
## Expected behavior
## Environment — OS + Python/Node version (omit if N/A)
# feature_request.yml (type: Feature — no label)
## Problem / motivation — what's hard or impossible today (include URL if any)
## Proposed solution
## Alternatives considered (omit if none)
## Affected package — any of the options above (multiple allowed)
-
Fill the fields (IN ENGLISH). Title ≤ ~70 chars, shaped as
<area>: <desired action/outcome> (e.g. editor: drop welcome page, show editor directly for guests). Fill every required field from the user's description; leave
a required field you can't infer as _TBD_ rather than dropping it. Drop optional
fields that don't apply. When the description points at a code area, search for the
relevant files (Grep/Glob, do NOT guess names) and name them inside the matching
field (e.g. under What happened? / Proposed solution) — the forms have no
dedicated Scope field.
-
Choose labels automatically. Build the label set from existing repo labels —
never invent a label (gh would error, or --force-create would pollute the
repo). Always list the live labels first and only use names that appear:
gh label list --repo kymostudio/kymostudio --limit 100
Then assemble:
-
Type:
- bug → label
bug (bug_report's own label).
- feature → Issue Type
Feature (org-level), set in a separate step (see
step 5) — do not add an enhancement label.
-
Area label (when one exists for the affected area): this repo uses #-prefixed
area labels. Map the affected package/area to its label if that label exists:
| affected area | area label |
|---|
| editor | #editor |
| website / landing / playground | #landing |
| icons / website-icons | #icons |
| website-design / design system | #design |
| dbml import | #dbml |
Packages with no matching area label yet (python, js, rust/core, mcp, mobile,
desktop-app, vscode-extension) get no area label — do not create one.
-
documentation: add when the issue is primarily about docs (affected area
docs, or a docs-only change).
-
Anything else (good first issue, help wanted, question, @epic, >loop,
assignee, milestone) is added only when the user explicitly asks.
Pass each label with its own --label flag (names contain #/spaces — quote them).
-
Create or edit the issue, then set the type. Apply the labels from step 4.
Bug — new issue:
gh issue create --repo kymostudio/kymostudio \
--title "<title>" \
--label "bug" --label "#editor" \
--body "<body>"
Feature — new issue (no enhancement label; set the Feature type after):
url=$(gh issue create --repo kymostudio/kymostudio \
--title "<title>" \
--label "#editor" \
--body "<body>")
num=${url##*/}
gh api repos/kymostudio/kymostudio/issues/$num -X PATCH -f type=Feature
Editing an existing issue (user gave an issue number/URL — reformat title/body
to the template, reconcile labels, set/clear the type):
gh issue edit <number> --repo kymostudio/kymostudio \
--title "<title>" \
--add-label "#editor" --remove-label "enhancement" \
--body "<body>"
gh api repos/kymostudio/kymostudio/issues/<number> -X PATCH -f type=Feature
Why the REST PATCH ... -f type=…: the form's type: only auto-applies when
an issue is filed through the GitHub web form. When this skill creates/edits via
the CLI, the type must be set explicitly. The installed gh (2.64) has no
--type flag, so use the REST API. Valid org types: Bug / Feature / Task.
For a bug you may likewise set -f type=Bug (optional — the bug label already
marks it).
-
Report back. Return the issue URL plus a 1–2 line summary, and note what was
applied — issue type (Feature/Bug) and labels (area, etc.). Beyond the
auto type/labels above, do not add assignee/milestone/extra labels unless asked.
