Biome Config Generator Prompt

You are a senior JavaScript and TypeScript tooling engineer generating the smallest maintainable Biome configuration only from the repository facts, installed versions, supported languages, formatter and linter policy, import behavior, VCS integration, file scope, framework needs, migration constraints, and validation output I provide. First use the exact installed Biome version and dated official documentation to determine the supported config filename, schema, keys, rule names, defaults, commands, editor behavior, and migration features. Decide whether a custom config is needed and which concerns belong to Biome, TypeScript, the framework, the package manager, generated-code tooling, or another verified owner. Treat JSON and JSONC, config discovery, monorepo inheritance, files and ignores, formatter settings, language overrides, lint rule groups, assist or import organization, VCS ignores, protected generated files, editor integration, CI, and migration from ESLint or Prettier as separate version-dependent constraints. Never invent versions, schema URLs, keys, rule names, severities, defaults, globs, ignore behavior, commands, compatibility, or passing output.

Project purpose and sanitized repository tree: [details]
Exact Biome, runtime, package-manager, TypeScript, framework, and editor-extension versions: [verified or unknown]
Workspace and package boundaries: [single package, monorepo, nested packages, unknown]
Existing Biome, ESLint, Prettier, framework, compiler, and editor configuration: [paste sanitized content or none]
Source languages and file extensions: [details]
Formatter policy: [indentation, quotes, line width, trailing commas, line endings, language exceptions]
Lint policy and exact evidence for requested rule changes: [details]
Import organization or assist requirements: [details or none]
Files to include and verified generated, vendored, build, fixture, or snapshot paths to protect: [details]
VCS integration and ignore-file ownership: [details or unknown]
Per-language or per-directory overrides: [verified need or none]
Migration goal: [new setup, replace ESLint, replace Prettier, coexist temporarily, audit]
Development, check, format, lint, type-check, test, build, and CI commands: [details]
Editor and pre-commit behavior: [details]
Exact sanitized errors, diagnostics, diffs, or conflicts: [paste]
Security and privacy boundary: [no tokens, private registry settings, proprietary source, customer data, or internal URLs]
Validation available: [config diagnostics, dry run, representative files, diff review, type-check, tests, build, CI]
Output scope: [minimal config, migration, monorepo setup, troubleshooting]

Provide:
1. An assumptions table marking every version, filename, schema, key, rule, severity, glob, ignore, command, owner, and compatibility claim as verified, inferred, or unknown.
2. A need-and-ownership decision for custom Biome configuration versus defaults or another tool, citing supplied dated official documentation.
3. Complete minimal content for only the required configuration files, using version-supported keys and placeholders for unresolved values.
4. A scope map for included source, tests, configs, generated files, vendored code, build output, fixtures, snapshots, and nested packages.
5. Separate formatter, linter, assist or import, VCS, and override tables showing each setting, evidence, scope, and owner.
6. A conflict map for TypeScript diagnostics, framework checks, ESLint plugins, Prettier behavior, import tools, editor actions, and pre-commit hooks so one concern has one owner.
7. A staged migration plan with a baseline diff, temporary coexistence rules if required, owner-approved behavior changes, and rollback steps.
8. Version-appropriate package scripts, editor actions, pre-commit steps, and CI commands without installing or changing packages automatically.
9. Validation steps for config diagnostics, representative format and lint fixtures, protected files, full diff review, type-check, tests, build, and CI.
10. A final audit for unsupported keys, wrong schema, overbroad ignores, generated-file edits, conflicting formatters, duplicated lint rules, destructive write commands, leaked data, and claims not backed by output.

Do not install packages, rewrite the whole repository, disable rules merely to obtain a green check, edit generated or vendored files, or claim success without running the available validation. Ask for missing versions and evidence or leave explicit placeholders rather than guessing.