Tools provided
Tools the agent exposes — your AI client calls them automatically when it needs them.
- check_design_coverage — Score a per-screen component inventory: design-system coverage for each screen, the overall ratio, and the instance counts behind it. A screen with no recorded instances is reported as UNKNOWN coverage, never as 100 percent, and a screen missing its design-system count is dropped and named rather than scored as zero.
- list_one_offs — List every one-off component in the inventory you supply, rank the deviations that recur across two or more screens, and turn each into a promote-or-fold suggestion. Component names differing only by case, locale or invisible characters are counted as one component, and that fold is reported rather than applied silently.
- match_design_tokens — Match every raw value on every layer of a design node against your design-token table, and report which values are tokenized and which are hardcoded. Matching is EXACT equality within a category after notation is normalized (case, invisible characters, whitespace, short hex): there is no nearest-token search, so a value with no token is reported as a miss rather than painted with something close.
- generate_component — Generate a Vue 3 single-file component or a React TSX component, its Storybook story and its snapshot test from the design node's layers and your design tokens. Every class, prop, aria-label and CSS declaration is derived from a layer you supplied; a value with no exact token is emitted as your own raw value so the gap stays visible in the diff. Deterministic templating - no model writes any of the source.
- extract_component_api — Read a component's real public interface out of its source: every prop with its type, default and required-ness, the events it emits, and the slots it exposes. A member whose type the source does not state is reported as unknown rather than as any, and a type that lives in another file is named as unresolved rather than guessed at.
- reconcile_props — Compare the properties the design declares against the props a component really has, and report the matches, the design properties the component is missing, the props the design never mentions, type and required-ness disagreements, and near-name pairs that are probably one property under two spellings. Names are matched exactly or not at all - a notation-only fold is reported as a rename, never counted as a match.
- design_api_contract — Build an OpenAPI 3.0 document from the endpoints you are designing, and - when you also supply the previously published contract - diff the two, classify every change as breaking or additive, and derive the semver impact and the next version. Without a baseline the impact is unknown, not a patch bump. Parameters and response fields are bare names or {"name","type"}: a type change is detected only where both sides declared one, and the report counts the fields it could not compare.
- generate_sdk — Generate TypeScript and PHP client stubs for the endpoints you supply: one method per endpoint, every declared parameter actually sent, unique method names, and any input warnings printed in a banner at the top of the source. Supply the previously published contract as well and you also get the changelog; without it the changelog is omitted rather than claiming nothing changed.
- lint_design_file — Apply design-system, accessibility and handoff-readiness rules to the design file nodes you supply, and return every violation against the real node it was found on. Merges the design-lint, component-audit and handoff-checklist checks into one rule set. A rule whose reference data you did not supply is reported as unevaluated and left out of the score, never counted as a pass.
- run_full — Run every capability you supplied the input for, in registry order, and return one report. Capabilities whose input is missing are listed as skipped with the fields they need — never run against a fixture and never reported as zero.
- list_capabilities — List what this agent can do: every tool it advertises, what each one is for, and the arguments each one reads. Useful for discovery before the first call.
- plan_inputs — Plan the inputs for a tool: returns the questions to ask, the JSON schema of the arguments, and a ready-to-edit example. Every argument it names is an argument the tool actually reads.
- discover_intent — Understand your goal and co-design the exact input through clarifying questions before anything runs.
- open_form — Use this the moment the user wants to run this agent on their own input. It opens an interactive form that collects the run arguments. Do NOT check credentials, do NOT ask clarifying questions in chat, and do NOT run any analysis before calling this — the form is the entry point for running the agent.
- run_form — Internal: invoked by the open_form form when the user submits. Reads exactly the same arguments as run_full and forwards all of them. Not for direct use.
