DataOps & Quality Engineering Review Prompt

When to use: Deliberately invoke in Agent mode against a Databricks Asset Bundle monorepo (or similar multi-bundle ETL repo) to produce a point-in-time maturity assessment. Re-run periodically (e.g. monthly, or after a sprint focused on quality improvements).

The agent needs read access only; no writes to the target repo are required unless you ask it to save the report.

Example outcome (redacted): assess-dataops-maturity

What this review covers

Every run produces evidence across three headline views:

View	What it answers
Repository overview	How the monorepo is organised — bundle count and layout, shared config, CI/CD pipelines, job definitions, and key infrastructure files
Practice adoption	What percentage of bundles use bundle config, PR validation, lint, unit tests, dependency manifests, schema enforcement, and data-quality checks
Top opportunities	Highest-impact gaps and next steps — prioritised recommendations ranked by value vs effort

Full sections below add depth: findings by area (structure, dependencies, CI/CD, test automation, data quality), recent commit activity, programme/epic alignment (if the user supplies one), maturity scores, and progress since the last run.

Test automation vs data quality

These are separate dimensions in this review — do not conflate them.

	Test automation	Data quality
Purpose	Verify that code behaves as intended	Verify that data in tables meets expectations
When it runs	Before merge or deploy — in CI or local dev	After data is written — pipeline post-checks, scheduled monitoring, or profiling
Typical tooling	pytest, pylint, extracted functions, conftest.py, chispa	DQ frameworks, pipeline expectations, catalog monitoring, bespoke SQL consistency checks
What failure means	A bug or regression in transform logic	Bad, missing, stale, or inconsistent data
Example pattern	Two pilot bundles with pytest suites under Tests/	Post-check task or monitoring on key jobs

---

Prompt

Perform a comprehensive DataOps and Quality Engineering review of this Databricks Asset Bundle monorepo (or equivalent multi-bundle ETL repo). Produce a structured markdown report covering the sections below. Be specific — use actual file names, line counts, and percentages rather than generalities.

Open each run with a brief At a glance block (repository overview headline stats, practice-adoption table summary, top 3 opportunities) before the numbered sections. Keep test automation (§3.4) and data quality (§3.5) clearly separated using the definitions in Test automation vs data quality above.

1. Repository Overview

• Count the total number of top-level Asset Bundles (folders containing a databricks.yml or equivalent).
• Count the total number of Python source files (.py) across the repo.
• Describe the typical bundle directory structure with an example tree.
• List the key infrastructure files at the repo root and their purposes (shared targets config, CI pipeline definition, etc.).

2. Practice Adoption Audit

For every bundle, check and tabulate adoption of each practice below. Show bundle count, percentage of total bundles, and any relevant notes:

Practice to check	How to check
Asset Bundle config	Has databricks.yml (or platform equivalent)
CI bundle validation on PR	Referenced in the CI pipeline definition
CI linting (feature branch)	Lint step runs on feature branches for this bundle
CI linting (main branch)	Lint step runs on main for this bundle
CI unit tests (feature branch)	pytest step runs on feature branches for this bundle
CI unit tests (main branch)	pytest step runs on main for this bundle
Extracted testable functions	.py files with pure functions outside notebooks
Tests/ folder present	Has a Tests/ directory
requirements.txt or pyproject.toml	Has a dependency manifest
Data quality checks	Any DQ tooling configured
Schema enforcement	Explicit schema validation in code or config

3. Findings by Area

For each of the five areas below, describe the current state, identify specific gaps with file/line references, cite relevant official platform documentation (with URLs), and provide concrete recommendations.

Important: Fetch and read the linked documentation pages (not just cite the URLs) to provide specific, evidence-based comparisons between what the repo does and what the platform recommends.

3.1 Monorepo Structure

• How do bundles reference shared code? Trace %run paths and sync.paths usage.
• Is there a mismatch between workspace paths and repo paths?
• Compare against official bundle sharing guidance for the platform.

3.2 Dependency Management

• How are Python dependencies declared and installed? Search for %pip install, requirements.txt, setup.py, pyproject.toml.
• Are versions pinned?
• Compare against official library-dependency guidance for job/bundle definitions.

3.3 Deploy as Code (CI/CD)

• Read the CI pipeline definition end-to-end. Map every step and its scope (which bundles, which branches).
• Check: are quality gates blocking or non-blocking? (Look for patterns like || echo, || true, continue-on-error.)
• Is there a staging environment/target?
• Compare against official CI/CD best practices for the platform.

3.4 Test Automation

Scope: code correctness before deploy — pytest, lint, fixtures, extracted functions. Not data-in-table validation (see §3.5). - For every bundle that has tests: list test files, count test functions, evaluate assertion quality. - Classify tests: smoke test, value test, edge-case test. - Check for shared fixtures (conftest.py), DataFrame assertion libraries (chispa), mocking. - Identify the largest untested bundles by notebook count. - Compare against official unit-testing guidance for notebooks.

3.5 Data Quality Testing

Scope: data correctness after load — expectations, monitoring, post-pipeline checks. Not unit/integration tests of Python logic (see §3.4). - Search for any data quality tooling. - Note which approach is feasible given the current architecture (standard notebooks vs declarative pipelines). - Compare against official pipeline expectations and data-quality monitoring docs.

4. Recent Commit Activity

Use git log to examine recent commits (last 3 months) to any bundles that have tests or quality-related changes. For each:

• When was the work done, and by whom?
• Does the commit history suggest structured development or trial-and-error in CI?
• Have any new test files, conftest.py, or quality tooling been added since the last review?
• Has the CI pipeline been modified to extend quality gates to additional bundles?

5. Programme / Epic Alignment

If the user supplies a governing epic or programme ticket, map each stated aim to Done, Partially done, or Not started, with evidence. If none is supplied, ask once or skip this section.

6. Summary Assessment

Produce a maturity table rating each dimension (Monorepo structure, Dependency management, CI/CD, Test automation, Data quality testing) as None / Very Low / Low / Moderate / High, with a priority-to-improve rating.

7. Prioritised Recommendations

List the top 10 recommended next steps in priority order. For each, note whether it's a quick win or requires significant effort, and link to relevant platform docs.

8. Progress Since Last Review

Compare this review's findings against the previous review in the target repo at docs/dataops-quality-review-YYYY-MM.md (if it exists). For each dimension, note what has improved, what has regressed, and what is unchanged. If no previous review exists, skip this section.

9. Reference Documentation

Compile all official doc links cited in the report, plus any programme-referenced resources.

---

Output format: A single markdown document. Use tables for quantitative data. Include code examples for recommendations where helpful. Save the output to docs/dataops-quality-review-YYYY-MM.md in the target repo using the current year and month.

---

Tips for reviewers

• Pinned scope: Keep What this review covers and Test automation vs data quality at the top; do not blur those dimensions.
• Frequency: Run monthly, or after completing a sprint focused on test/quality improvements.
• Diff tracking: Section 8 compares against prior reviews saved in the target repo's docs/ folder.
• Output shape: See the redacted use case for section structure and depth.
• Customising scope: To focus on a specific bundle, add a line like: "Focus this review on the <BundleName> bundle only, but still produce the full report structure."
• Adding new practices: To track a new practice, add it to the table in Section 2 of the prompt.