Skip to content

Databricks Naming Compliance Review

Instructions

Use this skill to run a repeatable naming-standards review of a Databricks ETL repository.

  1. Read references/review-prompt.md before inspecting the target repo. Treat the rules in that file as the default naming standard; no PDF is required.
  2. If the user explicitly supplies an updated naming standard, use it as an override or addendum and call out where it differs from the embedded rules.
  3. Inspect the requested branch without disturbing the user's working tree. If the review target is main, prefer git -C <repo> ls-tree main and git -C <repo> show main:<path> style reads.
  4. If the output format is not already specified, ask the user: Should I create a canvas-like visual artifact if this IDE or agent supports one, and otherwise generate a regular Markdown (.md) report?
  5. If the user agrees, use the richest canvas-like output available in the current environment. If that capability is unavailable, generate a regular .md report with the same sections and evidence.
  6. Include a run metadata block at the top of the output:
  7. last updated by reviewer name
  8. run date/time
  9. reviewed branch/ref
  10. reviewed head commit SHA
  11. reviewed head commit date
  12. delay since last run
  13. Compute "delay since last run" by finding the newest prior naming review artifact for the same repo and parsing its run date. If no previous artifact is available, write First recorded run.
  14. Calculate a weighted roll-up compliance score out of 100. Use 50% weight for Databricks object references, 25% for code files, 15% for folders, and the remaining 10% for job YAML files. Explain the weighting briefly in the output.
  15. Produce counts, percentages, representative compliant examples, representative violations, anti-patterns, and ambiguity/assumptions.
  16. Keep evidence concrete: cite paths, object names, job names, task keys, branch refs, and command-derived counts.
  17. Do not edit the target repository unless the user explicitly asks for remediation.

Output

Prefer a standalone analytical artifact when the environment supports one and the user has accepted that output mode. Otherwise produce Markdown suitable for a living review document.

Always include:

  • executive summary
  • standards interpreted
  • weighted roll-up score and scoring explanation
  • compliance dashboard
  • findings ordered by severity
  • hotspots by project/module
  • progress or delay since last run
  • recommended remediation order
  • assumptions and standards gaps

Troubleshooting

Error: The embedded rules reference another standard. Cause: Catalog, user/group, or compute naming is intentionally delegated to separate standards. Solution: Mark those areas as not fully assessable from embedded rules; still report concrete drift and ask for the missing standard before calling it non-compliant.

Error: Counts differ from a previous run. Cause: Branch, file-extension scope, compound extensions, or generated files were treated differently. Solution: State the branch/ref and scope rules in the metadata and assumptions, then use the same scope on future reruns.

Error: No previous review artifact can be found. Cause: The review has not been recorded in a parseable location. Solution: Set delay to First recorded run and include parseable run metadata so the next rerun can compute the delay.