Home/Blog/How to Use the SQLFluff Config Builder Prompt to Turn Your SQL Style Guide into Real Lint Rules
Blog

How to Use the SQLFluff Config Builder Prompt to Turn Your SQL Style Guide into Real Lint Rules

P
promptstudio

Translate a written SQL style guide into a working SQLFluff setup for a dbt project: a .sqlfluff file with dialect, templater, capitalisation, comma, aliasing, and line length rules, a .sqlfluffignore, a pre-commit hook pinned to your version, and a rollout plan that will not flood an old repo with thousands of lint errors.

How to Use the SQLFluff Config Builder Prompt to Turn Your SQL Style Guide into Real Lint Rules

Most analytics teams have a SQL style guide. Fewer have one that is actually enforced. The guide says lowercase keywords and leading commas, but pull requests still arrive in every style, and reviewers spend their comments on formatting instead of logic. SQLFluff can enforce most of that guide automatically, but mapping each sentence to the right rule code and config key takes time. The SQLFluff Config Builder: Team SQL Style Guide to .sqlfluff Rules, dbt Templater Setup, and a Pre-commit Hook prompt does that mapping for you and hands back a working setup for a dbt project.

What the prompt produces

  1. A mapping table from each style guide sentence to a SQLFluff rule code, rule name, and config value, with NO RULE where nothing in SQLFluff checks it.
  2. A complete .sqlfluff file with dialect, templater, line length, indentation, comma position, and one section per configured rule.
  3. A .sqlfluffignore for build output, packages, and legacy folders.
  4. A pre-commit hook pinned to your SQLFluff version with the right dbt dependencies.
  5. A rollout plan so an existing repository does not fail every build on day one.
  6. Before and after snippets that show reviewers what each rule changes.

How to fill the inputs

Dialect is your warehouse, such as Snowflake, BigQuery, Postgres, or Redshift. SqlfluffVersion matters more than people expect, because rule names and some config keys changed between major versions. Use the version pinned in your requirements or lock file.

DbtSetup tells the prompt your adapter, project directory, profiles directory, profile name, and the target your CI uses. The dbt templater compiles models, so it needs a profile that works in CI.

StyleGuide is the text of your guide, pasted as is. LegacyPaths lists folders you want ignored for now. BaselineErrors is optional, but a rough count from one manual run helps the prompt size the rollout plan.

Reading the example output

The example uses a Snowflake dbt project on SQLFluff 3.2.5 with about 4,100 existing violations:

  • Each guideline gets a rule or an honest NO RULE. Lowercase keywords map to CP01, leading commas to the comma layout setting, explicit table aliases to AL01, and grouping by column names to AM06. The guideline about naming CTEs with a verb gets NO RULE, because SQLFluff does not check naming conventions like that.
  • The config is ready to commit. It includes the dbt templater section with the CI profile and target.
  • The pre-commit block is pinned. The hook version matches the SQLFluff version, and the dbt adapter is listed as an additional dependency.
  • The rollout avoids a wall of red. Linting only changed files in CI keeps new work clean while one folder per pull request is fixed over a few weeks.

Tips for better results

  • Paste your real style guide, not a summary. The prompt can only map sentences it can see.
  • If the dbt templater is too slow or hard to run in CI, ask for the jinja templater version and read the tradeoff note.
  • Review the first sqlfluff fix pull request for logic changes, not just formatting. Automated fixes are usually safe but worth a careful look the first time.
  • Keep the mapping table in your repository README so new team members know why each rule exists.

Mistakes to avoid

  • Do not copy rule codes from an older blog post into a newer SQLFluff version without checking. The prompt marks anything uncertain as VERIFY.
  • Do not turn on every rule at once on a large legacy project.
  • Do not expect SQLFluff to enforce business naming rules. Keep those in code review.

Who it is for

Analytics engineers, data platform leads setting up CI for dbt, and any team that wants its SQL style guide to be more than a document.

Related PromptDig links

Start with the SQLFluff Config Builder: Team SQL Style Guide to .sqlfluff Rules, dbt Templater Setup, and a Pre-commit Hook prompt and paste your style guide. To find more prompts for developers and data teams, Browse more prompts. If you have a config or CI prompt that saves your team time, Share a prompt.