{"slug": "your-prompt-templates-are-tool-calls-how-askuserquestion-s-4-option-cap-bit-me", "title": "Your Prompt Templates Are Tool Calls: How AskUserQuestion's 4-Option Cap Bit Me Three Times", "summary": "A developer building the Suhail orchestrator for Claude Code discovered that the AskUserQuestion tool caps menus at four options, causing validation errors or silently dropping options like the critical 'Abort' function. The bug recurred across three sessions because the root cause was in prompt templates rather than code, leading to a rule that every menu template must include an 'Abort' option and stay within the tool's schema limits.", "body_md": "The same bug hit me in three separate sessions before I fixed it properly. Each time, my orchestrator reached a decision point, tried to present its menu, and burned a turn on a validation error instead of a question:\n\n```\nInputValidationError: {\n  \"code\": \"too_big\",\n  \"maximum\": 4,\n  \"path\": [\"questions\", 0, \"options\"]\n}\n// abridged; the full payload includes the Zod message\n```\n\nClaude Code's `AskUserQuestion`\n\ntool caps every question at 4 options. My menu had 5.\n\nFirst strike: the end-of-run menu. Second strike: a blocker-recovery menu. Third strike: the same recovery menu two weeks later, after I thought I'd fixed it. That repetition is the story.\n\nA one-off validation error is not worth a blog post. What makes this one worth writing up is why it recurred: the cause wasn't a typo. It was a template.\n\n[Suhail](https://github.com/wessamfathi/suhail), my Claude Code orchestrator, is a set of markdown prompt files, and its menus live in those files as literal option lists: the template says exactly what to present, and the model presents it verbatim. Five options go into one `AskUserQuestion`\n\ncall, the schema rejects it, and the round-trip to the model is wasted. In my runs the model then retried with four options and continued, which is why, the first two times, I let the retry count as the fix.\n\nThe recovery is so cheap that the bug reads as a hiccup, not a defect.\n\nBut decision menus are the natural accumulation point of any orchestrator. Every new capability wants a slot: continue, commit, skip, retry, abort, show status. The menu only grows. A 5-option template doesn't fail once; it fails on every run that reaches it, one wasted turn each time, until you fix the template.\n\nThe wasted turn is the benign version. Suhail's public changelog records the malignant one: the interactive complete-handler menu grew past the cap, and instead of erroring, the presented menu simply lost its last option. The option that got pushed out of reach was `Abort`\n\n.\n\nThe menu previously exceeded the 4-option cap, pushing`Abort`\n\noption in the interactive complete-handler made reachable.`Abort`\n\nout of reach; the menu is now split so`Abort`\n\nis always selectable.\n\nThat's from [Suhail's CHANGELOG](https://github.com/wessamfathi/suhail/blob/main/CHANGELOG.md), v0.13.0. When the model squeezes an oversized menu down to fit the schema, it decides what to drop, and it dropped the escape hatch. A user staring at that menu had no way to abort the run. No error anywhere.\n\nVerified against the live tool schema, July 2026:\n\n`too_big`\n\nerror above; a single option is also invalid. This is schema validation, not model behavior you can prompt around.`multiSelect`\n\nexists.The code-level fix is trivial: trim to 4, or split into two questions. The durable fix started with noticing where the bug lived. It was in the template file, not in any tool call. So the rules I now apply to every prompt file that scripts a menu:\n\n`Abort`\n\n.And because menus accumulate, the annotation has to be on *every* menu. While fact-checking this post I grepped Suhail's main branch and found two more menus already at five options, plus an instruction telling the model to add an \"Other\" option the tool already provides. That cleanup shipped as v1.1.1 while this post was in draft. The accumulation never stops; the cap has to be part of how menus get written.\n\nWhen a model builds tool calls from your prompt files, every canonical list in those files is a tool call waiting to be validated, and the failure is either a wasted turn or, worse, a silently trimmed menu with the important option gone. Lint your templates against the limits of the tools they feed, because the model will follow your doc verbatim, straight into the validator.\n\nThe schema will win.\n\n*The recurring menu here is from Suhail, the orchestrator I use daily against production Expo/Supabase repos. Tool limits verified against Claude Code's live AskUserQuestion schema (v2.1.216) and docs as of July 2026.*", "url": "https://wpnews.pro/news/your-prompt-templates-are-tool-calls-how-askuserquestion-s-4-option-cap-bit-me", "canonical_source": "https://dev.to/__declspec/your-prompt-templates-are-tool-calls-how-askuserquestions-4-option-cap-bit-me-three-times-56l6", "published_at": "2026-07-24 21:23:02+00:00", "updated_at": "2026-07-24 22:01:51.342133+00:00", "lang": "en", "topics": ["developer-tools", "ai-agents", "large-language-models"], "entities": ["Suhail", "Claude Code", "AskUserQuestion", "Zod"], "alternates": {"html": "https://wpnews.pro/news/your-prompt-templates-are-tool-calls-how-askuserquestion-s-4-option-cap-bit-me", "markdown": "https://wpnews.pro/news/your-prompt-templates-are-tool-calls-how-askuserquestion-s-4-option-cap-bit-me.md", "text": "https://wpnews.pro/news/your-prompt-templates-are-tool-calls-how-askuserquestion-s-4-option-cap-bit-me.txt", "jsonld": "https://wpnews.pro/news/your-prompt-templates-are-tool-calls-how-askuserquestion-s-4-option-cap-bit-me.jsonld"}}