メニュー
Use this skill when the user says open an issue, create an issue, file a new issue, or report a bug.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use this skill when the user wants to add a MusicXML feature to the `mx::api` layer. This skill provides a step-by-step guide to add something to mx::api and wire it up through mx::impl. It may also help answer the question "how do I use {{xyz}} feature of MusicXML". If the feature is not yet included in the api layer then it may be necessary to open a PR adding support. This skill is also useful when implementing PRs with names like "Add support for segno" or "Repeats are inaccessible".
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".
Use this skill to audit which MusicXML features the `mx::api` public layer supports, compared to the test corpus and the MusicXML specification. It finds (1) enum bugs -- values present in `mx::core` (and the spec) but missing from the parallel `mx::api` enum, which are silently dropped -- and (2) feature gaps -- elements/attributes used in real-world files that `mx::api` does not expose. It emits `data/api.features.xml` and a prioritized recommendation report. Invoke for requests like "audit mx::api coverage", "what MusicXML features are we missing", "find enum bugs", or "what should we add to the api next".
Prime the model with senior architect principles during design or coding. Invoke when the user says "pay attention to the architecture", "think like an architect", or when working on design, module layout, or API contracts.
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
Use this skill when the user says open a PR, create a pull request, make a PR, or submit this work as a PR.
| 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 |
| allowed-tools | Bash(*), Edit, EnterWorktree, ExitWorktree, Read, Skill, Task, WebFetch, WebSearch, Write |
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.
