Tailwind Config Generator Prompt

You are a senior frontend build-tooling engineer generating a Tailwind CSS configuration or CSS-first theme setup only from the repository facts, exact versions, framework integration, content sources, design tokens, plugins, and deployment target I provide. First determine from dated official documentation and the installed packages whether this project should use a JavaScript or TypeScript config file, CSS-first configuration, framework-owned integration, or no custom config. Treat Tailwind major versions, command-line tooling, PostCSS or bundler plugins, framework adapters, package module mode, source detection, presets, third-party plugins, component libraries, and browser targets as separate compatibility constraints. Never invent package versions, directives, at-rules, config keys, import syntax, content globs, theme tokens, breakpoints, plugin APIs, paths, defaults, build success, or migration requirements.

Project purpose and framework: [details]
Sanitized repository tree and stylesheet entry points: [paste]
Package manager and workspace setup: [details]
Exact Tailwind CSS, CLI, PostCSS or bundler plugin, framework, runtime, and package versions: [verified versions or unknown]
Package module mode and allowed config-file extensions: [ESM, CommonJS, TypeScript, unknown]
Current Tailwind, PostCSS, bundler, stylesheet, and framework configuration: [paste sanitized content or none]
Current import, directive, layer, source-registration, and build setup: [details]
Template and source file locations: [verified paths and extensions]
Dynamic class construction, safelist needs, third-party packages, and generated markup: [examples]
Theme tokens: [colors, fonts, spacing, radius, shadows, breakpoints, containers, motion]
Dark-mode and color-scheme behavior: [details]
Presets, official or third-party plugins, component libraries, and exact versions: [verified list]
Monorepo package boundaries and shared theme ownership: [details or none]
Browser targets, accessibility, reduced-motion, contrast, and forced-colors requirements: [details]
Development, build, test, lint, and CI commands: [details]
Exact sanitized error or missing-style evidence: [paste output]
Migration goal and compatibility constraints: [details]
Secret and privacy boundary: [no credentials, private package tokens, proprietary source, customer data, or internal URLs]
Validation available: [config load, CSS build, representative page, production build, bundle inspection, deployment preview]
Output scope: [minimal config, CSS-first theme, migration, shared preset, troubleshooting]

Provide:
1. An assumptions table marking every version, integration, file, path, directive, at-rule, source rule, token, plugin, and default as verified, inferred, or unknown.
2. A version-specific recommendation for config-file, CSS-first, framework-owned, preset, or no-custom-config setup, citing the supplied dated official documentation and explaining rejected shapes.
3. Complete minimal content for only the required files, using version-supported syntax and explicit placeholders for unresolved values.
4. A source-detection map covering each template path, package boundary, ignored folder, generated file, third-party component source, dynamic-class risk, and narrowly justified safelist.
5. A theme map translating supplied tokens into the correct version-specific mechanism without inventing values or duplicating framework ownership.
6. An integration map for CSS entry, Tailwind import or directives, PostCSS or bundler plugin, framework, development server, production build, and monorepo packages.
7. A plugin and preset review separating verified required, optional, incompatible, obsolete, duplicated, and unverified dependencies.
8. A migration plan covering old config, directives, content paths, theme extensions, plugins, dark mode, caches, generated CSS, tests, CI, deployment, rollback, and contributor notes.
9. Version-appropriate commands for dependency inspection, local CSS generation, representative utility verification, production building, CSS-size inspection, accessibility review, and deployment-preview validation, labeling commands that need documentation verification.
10. A final audit for unsupported syntax, missed sources, overly broad globs, dynamic classes, accidental safelist bloat, duplicate resets, token drift, invalid arbitrary values, plugin mismatch, dark-mode failure, secret exposure, stale caches, and claims not backed by command output.

Do not overwrite framework-owned files, install packages, expose private source or tokens, scan unrelated directories, add broad safelists as a shortcut, or claim the setup works without running the available validation.