mcpField
D
data-quality-observability-review

data-quality-observability-review

github.com/sylphxaiData & databases142 installsUpdated today
Repository

About data-quality-observability-review

Data Quality Observability Review is a skill for turning data quality and observability questions into an actionable plan. It organizes checks, monitoring, alerting, ownership, and recovery around the datasets and decisions at stake.

Key features

  1. 01Classify data quality checks
  2. 02Define monitors and alert thresholds
  3. 03Assign owners and alert routing
  4. 04Plan backfills and incident communications
  5. 05Produce quality maps and decision tables

Use cases

  1. 01Assess freshness and completeness risks
  2. 02Set alerts for schema drift and anomalies
  3. 03Plan recovery for faulty datasets
  4. 04Define ownership for critical data checks

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/sylphxai/skills --skill data-quality-observability-review

After installing, type/data-quality-observability-reviewin Claude Code to confirm it loaded.

Bundled filesagents/openai.yamlreferences/data-quality-observability-patterns.md

Details

From the project README

Data Quality Observability Review

Use this skill to convert a data quality, freshness, completeness, schema drift, lineage, alerting, and metric trust question into a concrete artifact with owners, gates, metrics, and recovery paths.

Workflow

  1. Identify critical datasets, decisions they drive, owners, data producers, consumers, SLAs, freshness needs, and blast radius of wrong data.
  2. Read references/data-quality-observability-patterns.md.
  3. Classify quality checks: schema, freshness, volume, uniqueness, referential integrity, distribution, reconciliation, privacy, and semantic metric checks.
  4. Define monitors, alert thresholds, owner routing, backfill policy, dashboard trust states, incident comms, and data contract changes.
  5. Produce quality map, state machine, decision table, event schema, alert policy, and backfill checklist.

When not to use

  • Do not use for generic advice the base model already handles without this skill's specific artifact contract.

Guardrails

  • Do not treat a dashboard as trusted if upstream freshness, schema, and reconciliation are unowned.
  • Do not alert every anomaly without severity, owner, and user-facing decision impact.
  • Do not backfill customer, billing, or AI training data without idempotency and before/after reconciliation.
  • Do not expose private data in quality logs, sample rows, or incident screenshots.

Output format

Data context:
Dataset / decision / SLA / blast radius:

Quality observability plan:
| Area | Decision | Evidence | Risk | Owner |
| --- | --- | --- | --- | --- |

Checks and owners:
- <item> -> <policy, metric, edge case, support note>

Backfill and incident response:
- <trigger> -> <action, communication, owner>

Comments

Markdown supported