Menu
Use this skill when the user says open a PR, create a pull request, make a PR, or submit this work as a PR.
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.
Based on SOC occupation classification
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 an issue, create an issue, file a new issue, or report a bug.
| name | mx-open-pr |
| description | Use this skill when the user says open a PR, create a pull request, make a PR, or submit this work as a PR. |
| argument-hint | <prompt> |
| disable-model-invocation | false |
| user-invocable | true |
| allowed-tools | Bash(*), Edit, EnterWorktree, ExitWorktree, Read, Skill, Task, WebFetch, WebSearch, Write |
Use <prompt> and your context to understand what the PR 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 this PR would close or that it is related to. Make a list of issues that it closes and issues that is related to. It might also be related to other PRs.
When writing the PR, the title should be lowercase and start with one keyword, e.g.
Look at the labels on GitHub, choose the ones that match the pr best.
Write a PR body. Keep it tight and human-readable, but with enough information to understand what was done and why.
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 pr and note the pr number. Make sure the PR body contains references to issues closed and issues/PRs related (if any).
No self-attribution in the PR body; add the ai label instead.
Do not use excessive bold and italics in the PR body. Go easy on the keywords since they will add a lot of backtick formatting as well.
Template/sample:
## Human Summary
TODO: human writes here
## Summary
`accidentalMap` in `Converter.cpp` was missing the entry for `sharpSharp`. Added a single item to the map so that the
double sharps are now fully supported in `mx::api`.
## Testing
- [x] `SharpSharp_PitchData` fails before the fix, passes after
- [x] All PitchData tests pass (`*_PitchData`: 37 assertions in 8 test cases)
- [x] Full test suite passes (3917 assertions in 219 test cases)
## References
- Closes #123
- Progresses #456
- Fixes a bug introduced in #789