What it does
Design System Coverage Agent finds where a product's screens have quietly drifted away from the design system — the debt that accumulates one reasonable exception at a time and becomes expensive to unwind. You supply a per-screen component inventory: how many published design-system components each screen uses, and which one-off parts it uses instead. The agent computes coverage per screen, sorted worst-first, lists every one-off instance, and identifies the deviations repeated across two or more screens. That last number is the one that changes decisions. A one-off used once is a local exception. The same custom input field appearing on login, dashboard and checkout is not drift — it is a missing design-system component that three teams independently rebuilt. `top_deviations` surfaces exactly those, and `merge_suggestions` turns them into a promotion list: which components to fold into the system, and how many screens each would fix. `overall_coverage` gives the single ratio for a quarterly review, and `compute_screen_coverage` gives the per-screen breakdown behind it, so a coverage number always comes with the screens that dragged it down. Every value is computed from the inventory you provide. There is no live design or code access, nothing is fetched, and no number is invented — a language model writes only the narrative, with a template fallback when none is available. Any section you leave out is reported empty with a warning rather than filled in. If you want the inventory gathered automatically, a Figma or GitHub MCP server on your host can assemble it upstream and hand it in. That stays your host's connection; this agent holds no credentials. Built for product managers, design leads and frontend engineers who suspect the design system is being followed less than the dashboard suggests.
Example prompts
- What is our design-system coverage per screen?
- Which one-off components keep getting rebuilt across screens?
- What should we promote into the design system?
