Conciseness

The body is dense and assumes competence: the tool-kind and render-props surfaces are compact tables, and the Common Gotchas entries are one-diagnosis bullets. Minor trimming is possible: the 16-field ToolCallMessagePartProps table and the ~40-line approval-gate example are API surface that could live in tool-ui.md / human-in-loop.md, and the opening sentence "A tool is a named capability the model can call" restates a concept Claude already knows. This fits the 4 anchor (efficient, minor instances that could be trimmed) better than 5 (every token earns its place) and better than 3, which would require noticeably unnecessary explanation.

Actionability

Four complete, copy-paste-ready code blocks with real imports and file titles (next.config.ts plugin, app/toolkit.tsx, MyRuntimeProvider.tsx, app/api/chat/route.ts) plus executable human-tool and approval-gate renderers cover the common authoring cases end to end. This matches the 5 anchor; no pseudocode or missing key details that would justify 4.

Workflow Clarity

The authoring model is a clearly sequenced 4-step path (add build plugin → write toolkit → mount on client → expose to model), validation is explicit and build-time ("The compiler enforces at build time that every tool declares an execute..."), and the Common Gotchas section is a set of problem → cause → fix feedback loops for each failure mode (e.g., "humanTool() or stubTool() throws at runtime — the file was not processed by the compiler. Add the build plugin..."). This matches the 5 anchor (clear sequence, validation, error-recovery feedback loops); 4 would require missing checkpoints, which are present.

Progressive Disclosure

A References section lists all 8 bundle files with one-line scope descriptions, each verified present in ./references/, all exactly one level deep. Contextual links defer detail at the right altitude ("The full option, question, and resolution surface is in human-in-loop.md", the aui options object "documented in toolkits.md"), and the Related Skills section routes to siblings. The body keeps only the overview-level core. This matches the 5 anchor; 4 would require organization gaps that are not present.

Specificity

The description lists multiple concrete actions with comprehensive coverage: "Defines model-callable tools and renders their calls in assistant-ui", authoring via "defineToolkit({...}) compiled by withAui", mounting via "AuiConfig({ tools: Tools({ toolkit }) })", exposing via "new AISDKToolkit({ toolkit }).tools({ frontend })", plus the full tool-kind list, approval gates, MCP servers, WebMCP, and sub-agent messages. It matches the 5 anchor (multiple specific concrete actions, comprehensive coverage) rather than 4, which requires minor gaps in coverage.

Completeness

Both questions are answered explicitly: the first sentence states what the skill does ("Defines model-callable tools and renders their calls in assistant-ui") and "Reach for it when a tool is never called... or an approval gate cannot be answered" states when with concrete trigger phrases. This matches the 5 anchor exactly; the explicit 'when' rules out 3, and the specificity of both clauses rules out 4.

Trigger Term Quality

The "Reach for it when" clause carries natural failure-mode phrases users would actually say ("a tool is never called", "a tool UI does not render", "humanTool() throws at runtime", "an approval gate cannot be answered"), but common synonyms like "custom tool" or "tool call rendering" are absent, and the middle of the description is an API-name sequence (withAui, AuiConfig, AISDKToolkit) that buries the natural terms. This fits the 4 anchor (good keyword coverage, a few natural terms missing) better than 5's comprehensive synonym coverage, and better than 3, which would require missing common variations of the core terms.

Distinctiveness Conflict Risk

The skill occupies a clear niche (assistant-ui tool authoring) and the closing sentence actively routes borderline cases to siblings: "For model-composed UI use generative-ui, for MCP servers users add in the browser use react-mcp, and for the styled ToolFallback and ToolGroup use elements." Distinct triggers plus explicit boundary routing match the 5 anchor with minimal conflict risk; not 4, since overlap cases are explicitly disambiguated rather than merely minor.