Menu
Use this skill when the user says open an issue, create an issue, file a new issue, or report a bug.
The review-first prompt is selected by default. You can switch to a direct command or download a local copy.
Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.
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.
A direct command skips the review prompt. Inspect the source before running it.
npx skills add https://github.com/webern/mx --skill mx-open-issueThe command stays on one line. Scroll horizontally to inspect it before copying.
Prefer a local copy? Download the files currently available to SkillsMP.
You must read and use this skill when writing comments in the code and when documenting this library.
Use when adding a MusicXML feature to mx::api, exposing a feature that is currently inaccessible, or explaining whether and how mx::api supports a feature.
Use this skill to explain, in plain language, what is wrong with the `mx::api` round-trip and what it needs next. It drives the failure classifier (dump -> classify) over the corpus, then reads build/api/classified.json and turns it into a prioritized, human-readable worklist grouped by failure shape (crashes, instant wins, small fix-sets, reorder-blocked, high-frequency drops). Invoke for requests like "what's broken about mx::api", "explain the round-trip failures", "what does the api need next", or "triage the api round-trip".
Showing SKILL.md
| name | mx-open-issue |
| description | Use this skill when the user says open an issue, create an issue, file a new issue, or report a bug. |
| argument-hint | <prompt> |
| disable-model-invocation | false |
| user-invocable | true |
Use <prompt> to understand what the issue is about. Check to see if there is documentation on the
issue available in docs/ai/api-feature-audit.md (which might be the case if it was previously
documented by an api-feature-audit).
Use gh for GitHub interactions.
Search the open issues for one that it would duplicate. If it would fully or exactly duplicate an issue, then suggest editing or commenting on the existing issue instead of creating a new one.
Identify related issues and a potential parent/tracking issue.
When writing the issue, the title should be lowercase, e.g. fix missing flerbinator in mx::impl.
Look at the labels on GitHub, choose the ones that match the issue best.
Write an issue body. Keep it tight and human-readable, but with enough information to understand what needs to be done.
Determine from the original prompt whether the user wanted you to YOLO and open or whether the user wanted to see a draft first.
When ready, create the issue and note the issue number. Make sure the issue body contains references to related issues and/or PRs (if any are related). If it is a child of another issue, edit the tracking issue body to add it to the list of tracked issues and also make it a sub-issue of the tracker.
No self-attribution in the issue body; add the ai label instead.
