01Safety
30.0 / 30
What changed in the harness
Selection accuracy 98→95, token cost up 1%, unconfirmed writes 100%→100%.
Category breakdown
Where the score comes from.
Earned points across the four signals Gradable measures. Safety and Legibility are scored out of 30; Economics and Discoverability are scored out of 20.
02Legibility
23.6 / 30
03Economics
15.1 / 20
04Discoverability
18.7 / 20
Highest-impact fix
Estimated gain +1 pointRewrite 10 underspecified tool descriptions
State each tool's behavior, explain every parameter, and declare return semantics, prioritizing tools exercised by failed selection tasks.
Description evidence
Defects and rewrites.
10 defects found across the exposed tool descriptions. Suggested rewrites make purpose, inputs, boundaries, and returns easier for an agent to understand.
| Tool | Defect types | Suggested rewrite |
|---|---|---|
design_review_checklist |
no_return_description |
Generate a structured design-review checklist for a project type (mobile app, website, landing page, dashboard). Returns a checklist assembled from the knowledge base, organized by area, with the key rules and anti-patterns to check for each. Use it to audit an existing design or as acceptance criteria for a new one. |
get_design_roadmap |
no_return_description |
The SaglitzDesign roadmap: a phased, expert design process for a given project type (website, landing page, iOS app, Android app, macOS app, SaaS web app). Returns an ordered list of phases, each with its goal and the exact knowledge-base doc ids to consult. Use this FIRST when starting any design project, then fetch phase docs as you reach them. |
knowledge_freshness |
no_return_description |
Check how fresh each knowledge document is. Returns, per document, its id, age since last verification, its category's staleness threshold, and whether it is currently stale. Use this to decide which docs need re-research; refresh workflow is documented in the repo's /refresh-knowledge command. |
get_component_recipe |
no_return_description |
Get production-ready, accessible reference CODE for a UI component in a chosen stack (react-tailwind, html-css, swiftui, compose). Returns copy-paste code covering all states, ARIA/accessibility, keyboard support and correct motion, grounded in the SaglitzDesign specs — or, if stack is omitted, the spec plus all available stacks. Use when you need to actually build a button, input, modal, toast, card, switch, tabs, empty-state, or list-row. Pair with get_component_guidance (the design rationale) and generate_design_tokens (the theme). |
fix_contrast |
no_return_description |
Repair a failing color pair: given a foreground and background hex, compute the nearest accessible color (hue & saturation preserved, lightness nudged) that meets the WCAG 2.2 target. Returns the corrected hex value and its resulting contrast ratio — not just a pass/fail report. Use when audit_accessibility flags a pair and you need the corrected value to ship. For a full pass/fail audit use audit_accessibility; to build a whole palette use generate_color_system. |
generate_elevation_system |
no_return_description |
Generate a cohesive elevation / box-shadow ramp (layered ambient + direct light) with semantic level names (flat…modal). Returns ready-to-paste CSS custom properties and a Tailwind @theme block for the ramp, plus dark-mode guidance. Deterministic. Use one shadow token per level instead of hand-tuning shadows per component. |
generate_motion |
no_return_description |
Generate a motion system: easing tokens (decelerate/accelerate/standard/spring as cubic-beziers), duration tokens, and keyframe animations (fade-in, slide-up, scale-in, spring-pop, shimmer). Returns the requested animation(s) as ready-to-paste real code in CSS, Framer Motion, or SwiftUI — grounded in the animation-craft rules (ease-out on enter, small distances, never scale(0), honor reduced-motion). Deterministic. |
create_design_system |
no_return_description |
THE one-call foundation. Turn a brand color + product vibe + platform into a complete, coherent design-system starter. Returns accessibility-verified color (light+dark), a matched font pairing, an icon library, a modular type scale, an elevation ramp, ready-to-paste design tokens (CSS/Tailwind or SwiftUI/Compose), the components to build, and a build checklist — all generated to work together. Use this FIRST when someone says 'design/build me a website/app' to lay the foundation, then get_component_recipe for each component and get_design_roadmap for the full process. |
generate_layout_system |
no_return_description |
Generate the layout foundation the other generators leave out: breakpoints (with what changes at each), container max-widths, edge padding, a column grid, an intrinsic auto-fit card grid, container queries, and a fluid section-rhythm scale. Returns ready-to-paste CSS custom properties and a Tailwind v4 @theme block, plus the rules that matter more than the numbers (design narrow-first, cap the measure at 45–75ch, prefer intrinsic layout to media queries). Deterministic real code. Pair with generate_type_scale and generate_design_tokens. |
import_design_tokens |
no_return_description |
Read an EXISTING design system and convert it: paste CSS custom properties (a Tailwind v4 @theme block, a shadcn :root block, plain CSS), a W3C DTCG token file, or a theme object as JSON. Returns the semantic roles it names, the semantic roles it is missing, a WCAG contrast check on the pairs it defines, and the whole set re-emitted as CSS / Tailwind / SwiftUI / Compose / DTCG. The inverse of generate_design_tokens — use it to take a web theme to iOS or Android, to audit an inherited system, or to see what a third-party theme leaves undefined. Only NAMED tokens are read; a bare hex inside a rule carries no role and is never imported as one (use audit_design_system to count those). JavaScript configs are never evaluated. |
Selection evidence
Confusable tool pairs.
16 pairs where similar names or overlapping descriptions may send an agent toward the wrong tool.
| Tool A | Tool B | Confidence | Why they collide |
|---|---|---|---|
create_design_system |
audit_design_system |
medium | Both act on 'a design system' — a request like 'help with our design system' could route to either the generator (new foundation) or the auditor (existing code analysis) without a clear existing-vs-new signal. |
generate_design_tokens |
import_design_tokens |
high | Both operate on design tokens across the same formats (CSS/Tailwind/SwiftUI/DTCG); a task like 'give me design tokens in Tailwind format' is ambiguous about whether the user has an existing theme to convert (import) or wants new ones authored (generate). |
get_component_guidance |
get_component_recipe |
high | Both target 'a UI component' with a component name param; a phrase like 'help me build a modal' could mean design guidance or actual code, and the tools are explicitly cross-referenced in each other's descriptions. |
get_design_doc |
get_design_examples |
medium | Both 'get' design content by a query/id; 'show me examples of onboarding' vs fetching a doc titled similarly could be conflated, though get_design_examples is fairly distinctly about real-world screenshots. |
get_design_doc |
get_design_language |
medium | Both fetch a full reference document by an id/enum; a request like 'get me the material-3 doc' could plausibly be routed to either get_design_doc(id) or get_design_language(language) since both return full prescriptive documents. |
get_design_doc |
get_design_roadmap |
low | Both fetch design content, but get_design_roadmap is clearly phased/process-oriented while get_design_doc is a single doc lookup; confusion is less likely given distinct framing. |
get_design_language |
compare_design_languages |
medium | A task like 'how does iOS handle navigation vs Android' could trigger either fetching one language's full doc or the comparison tool; overlapping platform enums increase ambiguity. |
get_design_language |
get_design_roadmap |
low | Both take a project/platform-like enum, but one returns a design system spec and the other a phased process — distinct enough that confusion is unlikely except for vague 'ios app' requests. |
get_design_roadmap |
get_design_examples |
low | Minor lexical overlap around 'design' and 'website' but roadmap (process planning) and examples (screenshots) serve very different intents, low real confusion risk. |
list_design_knowledge |
search_design_knowledge |
high | Both search/browse the same knowledge base; an open-ended query like 'what do you have on accessibility' could be routed to either listing by category or searching by natural language, and their descriptions explicitly reference each other. |
generate_color_system |
generate_elevation_system |
low | Both are deterministic 'system' generators but operate on clearly distinct visual properties (color vs shadow); unlikely to be confused given specific inputs (brand_color vs levels). |
generate_color_system |
generate_layout_system |
low | Shared 'generate system' phrasing but color and layout are semantically distant enough that a natural request wouldn't plausibly conflate them. |
generate_elevation_system |
generate_layout_system |
low | Both output CSS/Tailwind system tokens but for unrelated concerns (shadows vs grids/breakpoints); low chance of genuine confusion. |
suggest_font_pairing |
suggest_icon_library |
low | Both take an 'intent/vibe' string and return curated recommendations, but fonts vs icons are distinct enough asks that confusion is unlikely despite similar input shape. |
design_review_checklist |
get_design_roadmap |
low | Both take a project_type-like param for planning, but checklist (review/audit criteria) vs roadmap (phased process) differ enough in framing to rarely be confused. |
list_design_knowledge |
design_review_checklist |
low | Minor shared vocabulary ('design', 'knowledge base') but list_design_knowledge is a browse/index tool while design_review_checklist generates an audit checklist — different enough intents. |
Compare the field