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,…
The mx::api design doctrine. You MUST read this before designing or changing anything in the mx::api layer: adding or reshaping public types in src/include/mx/api/, wiring them through mx::impl, writing comments in api headers, or reviewing any of the above.
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.
Use this skill when the user says open a PR, create a pull request, make a PR, or submit this work as a PR.
Ask the user clarifying questions one at a time to refine a plan or task. Invoke with `/mx-questions` or automatically when more information is needed.