• Quantitative measurement and remediation suggestions through Figma data and AST-based code analysis.
    • Detect imports, design-token usage, and hard-coded style values, then use codemods to convert hard-coded styles into design tokens.
  • Extract scattered information as Markdown with markitdown, collect it into a single context, and provide it through MCP.

Questions

  • What results can import-statement detection produce? What insights or impact can we get from component usage counts?
  • Is MCP actually used often? Whether AI or people consume the system, guidance alone is not enough. It matters that the system makes the guidance difficult to ignore. How are they planning to solve that?
    • Ultimately, recurring errors need to be removed by something more enforceable than a prompt. TDD, SDD, and EDD seem to be attempts at that, and the constraint could go even further into the type system or language itself (https://youtube.com/watch?v=bKT2wOec_rg&feature=youtu.be (opens in a new window)).
    • Idea: collect component usage patterns and make frequently used patterns canonical. Implement by referring to those patterns, or emit a warning when code deviates from them (“Consider replacing this with the ___ pattern”). Track usage to add and remove canonical patterns over time. Could this become a “design-system language”?