How to Use Taste-Skill Design System Mapping for Official Packages Like Material and Fluent

Taste-skill forces the selection of official design-system packages—such as @fluentui/react-components for Fluent UI or @material/web for Material 3—by matching brief cues against a hard-coded table in SKILL.md, ensuring one canonical UI language per project.

The taste-skill repository by Leonxlnx provides a structured agent framework that eliminates styling ambiguity through explicit design-system mapping. This system reads project briefs, identifies UI language cues like "Microsoft enterprise dashboard" or "Google-style interface," and mandates the use of specific official packages rather than reinventing CSS. Mastering this mapping ensures your generated applications inherit proper accessibility tokens and maintainable component architectures.

Understanding the Design-System Table

The mapping logic resides in the design-system table within skills/taste-skill/SKILL.md at lines 89–90. According to the source code, the agent evaluates brief keywords to select exactly one official package:

• Fluent UI – triggered by cues like "Microsoft," "enterprise SaaS," or "dashboards" → mandates @fluentui/react-components or @fluentui/web-components
• Material 3 – triggered by "Google-ish" or "Material-flavored" descriptions → mandates @material/web plus Material 3 design tokens

This table enforces the Honesty rule: the agent must use the official package when the brief matches a known UI language, prohibiting custom CSS implementations that would fragment the design language.

Architectural Workflow for Implementation

The skill implements a five-phase guardrail system to ensure proper package integration:

1. Brief Analysis – the agent parses the design direction from the project brief (Section 0)
2. Design-System Decision – matches brief cues against the table to force selection of the official package
3. Single System Enforcement – bans mixing two design systems in the same component tree (Section 2.A)
4. Installation Verification – checks package.json for the required dependency and emits the exact install command if missing (Section 3.F)
5. Theme Placement – instantiates the theme provider once in app/layout.tsx (or root page component) to prevent sub-section overrides (Section 3.D)

Installing Official Packages

Before component imports, the skill verifies package presence. If dependencies are missing, the agent emits these installation commands:

# Fluent UI (React Components)

npm i @fluentui/react-components

# Material 3 Web Components

npm i @material/web

Configuring Root-Level Theme Providers

For systems shipping theme providers, taste-skill requires instantiation at the application root to establish the token context globally.

Fluent UI Provider in app/layout.tsx:

import "./globals.css";
import { FluentProvider, webLightTheme } from "@fluentui/react-components";

export default function RootLayout({
  children,
}: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body>
        <FluentProvider theme={webLightTheme}>
          {children}
        </FluentProvider>
      </body>
    </html>
  );
}

Material Web Provider in app/layout.tsx:

import "./globals.css";
import { ThemeProvider } from "@material/web/theme/theme-provider.js";
import { theme } from "@material/web/theme/theme.js";

export default function RootLayout({
  children,
}: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body>
        <ThemeProvider theme={theme}>
          {children}
        </ThemeProvider>
      </body>
    </html>
  );
}

Consuming Components from the Mapped System

Once the theme provider is mounted at the root, child components import directly from the mandated package without additional style wrappers.

Fluent UI Button:

"use client";
import { Button } from "@fluentui/react-components";

export default function CallToAction() {
  return <Button appearance="primary">Get Started</Button>;
}

Material 3 Elevated Button:

"use client";
import { MdFilledButton } from "@material/web/button/filled-button.js";

export default function CallToAction() {
  return <md-filled-button>Get Started</md-filled-button>;
}

Block File Naming Conventions

When the agent generates content blocks that rely on a specific design system, it stores markdown files using a suffix pattern that signals downstream tooling:

blocks/<category>/<name>--fluent.md
blocks/<category>/<name>--material.md

This --fluent or --material suffix indicates the block expects the corresponding @fluentui/react-components or @material/web package to be present in package.json, preventing runtime errors in consuming applications.

Summary

• The design-system mapping lives in skills/taste-skill/SKILL.md (lines 89–90) and maps brief cues to @fluentui/react-components or @material/web
• The Honesty rule forces official package use over custom CSS when brief keywords match known UI languages
• Only one design system is permitted per project tree (Section 2.A)
• Theme providers must be mounted once in app/layout.tsx to establish global token contexts (Section 3.D)
• Content blocks use suffixes like --fluent.md or --material.md to declare design-system dependencies

Frequently Asked Questions

What happens if my brief contains cues for both Material and Fluent?

The taste-skill agent resolves ambiguity by selecting the strongest match from the design-system table in SKILL.md. However, Section 2.A explicitly bans mixing two design systems in the same component tree, so the agent must choose one canonical system or request clarification rather than generating code that imports from both @fluentui/react-components and @material/web.

Where does the agent check for package installation?

According to Section 3.F of the skill definition, the agent examines package.json before emitting any import statements. If the required official package is missing, the skill emits the exact npm install command for @fluentui/react-components or @material/web rather than generating code that would throw module-not-found errors.

Why must the theme provider go in app/layout.tsx specifically?

Section 3.D mandates that theme providers for Fluent or Material be instantiated once in the root layout to ensure design tokens cascade properly through the component tree. Placing the provider in app/layout.tsx (or the equivalent root page component) prevents sub-sections from overriding themes and breaking visual consistency, while allowing all child components to inherit the correct token values without individual wrapper boilerplate.

Can I use @fluentui/web-components instead of the React package?

Yes. The design-system table in skills/taste-skill/SKILL.md lists both @fluentui/react-components and @fluentui/web-components as valid targets for Fluent UI projects. The selection depends on your project's framework requirements, but the mapping logic and installation guardrails apply identically to both official packages.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}