Menu
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.
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-questions |
| description | 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. |
Never use the AskUserQuestion tool. Never render a numbered option picker. Ask every question as
plain text in the chat, then stop and wait.
Ask exactly one question, then stop and wait for the answer. Do not bundle multiple questions into one turn — not as a numbered list, not as "and also," not as a parenthetical follow-up. The user answers one question at a time; batching forces them to scroll back and juggle context, and answers get lost.
Wrong:
A few things to clarify:
- What's the target platform?
- Should it support offline mode?
- What's the expected user count?
Right:
What's the target platform?
(wait for answer, then next turn:)
Got it. Does it need to work offline?
/mx-questions/mx-questions <optional-prompt> — e.g., /mx-questions about the design of the flubber async module