Skip to content
Back to skills

Analyzing Great Expectations

ASecurity

Use when working with Great Expectations — great Expectations data quality framework analysis. Covers expectation suite management, validation result review, data docs generation, checkpoint execution, datasource configuration, and batch analysis. Use when reviewing data quality results, managing expectation suites, investigating validation failures, or auditing data quality configurations.

  • 6 stars
  • 0 votes
  • 0 copies
  • 4 views
  • Added September 8, 2026
toolspythonbashgitapibackendsecuritydocumentation

Works with

  • cli
  • api

Security analysis

A100/100

Scanned September 8, 2026

npx -y skills add cloudthinker-ai/CloudSkills --skill analyzing-great-expectations --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Analyzing Great Expectations?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Analyzing Great Expectations
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/cloudthinker-ai-analyzing-great-expectations/badge)](https://www.skillsdirectory.com/skills/cloudthinker-ai-analyzing-great-expectations)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: analyzing-great-expectations
description: |
  Use when working with Great Expectations — great Expectations data quality
  framework analysis. Covers expectation suite management, validation result
  review, data docs generation, checkpoint execution, datasource configuration,
  and batch analysis. Use when reviewing data quality results, managing
  expectation suites, investigating validation failures, or auditing data
  quality configurations.
connection_type: great_expectations
preload: false
---

# Great Expectations Analysis Skill

Analyze and manage Great Expectations data quality suites, validations, and checkpoints.

## MANDATORY: Discovery-First Pattern

**Always discover project structure and available suites before querying specific validation results.**

### Phase 1: Discovery

```bash
#!/bin/bash

GE_DIR="${GE_PROJECT_DIR:-.}"

echo "=== Great Expectations Project Structure ==="
ls -la "${GE_DIR}/great_expectations/" 2>/dev/null || echo "No GE directory found at ${GE_DIR}"

echo ""
echo "=== Expectation Suites ==="
ls "${GE_DIR}/great_expectations/expectations/" 2>/dev/null | head -20

echo ""
echo "=== Checkpoints ==="
ls "${GE_DIR}/great_expectations/checkpoints/" 2>/dev/null | head -20

echo ""
echo "=== Datasources (from config) ==="
python3 -c "
import yaml
with open('${GE_DIR}/great_expectations/great_expectations.yml') as f:
    config = yaml.safe_load(f)
for name, ds in config.get('datasources', {}).items():
    print(f'{name}\t{ds.get(\"class_name\", \"?\")}\t{ds.get(\"execution_engine\", {}).get(\"class_name\", \"?\")}')
" 2>/dev/null | column -t

echo ""
echo "=== Validation Results (recent) ==="
ls -lt "${GE_DIR}/great_expectations/uncommitted/validations/" 2>/dev/null | head -10
```

## Core Helper Functions

```bash
#!/bin/bash

GE_DIR="${GE_PROJECT_DIR:-.}"
GE_BASE="${GE_DIR}/great_expectations"

# Run GE CLI command
ge_cmd() {
    cd "${GE_DIR}" && great_expectations "$@" 2>/dev/null
}

# Parse validation result JSON
ge_parse_validation() {
    local result_file="$1"
    jq '{
        suite: .meta.expectation_suite_name,
        success: .success,
        evaluated: (.results | length),
        passed: ([.results[] | select(.success == true)] | length),
        failed: ([.results[] | select(.success == false)] | length),
        run_time: .meta.run_id.run_time
    }' "$result_file"
}

# List all expectation suites
ge_list_suites() {
    find "${GE_BASE}/expectations" -name "*.json" -type f 2>/dev/null | \
        sed "s|${GE_BASE}/expectations/||;s|\.json$||;s|/|.|g"
}
```

## Output Rules
- **TOKEN EFFICIENCY**: Target ≤50 lines per output
- Parse JSON validation results with jq — never dump full expectation configs
- Summarize pass/fail counts, not individual expectation details

## Common Operations

### Expectation Suite Analysis

```bash
#!/bin/bash
echo "=== All Expectation Suites ==="
ge_list_suites | while read suite; do
    SUITE_FILE="${GE_BASE}/expectations/$(echo $suite | tr '.' '/').json"
    COUNT=$(jq '.expectations | length' "$SUITE_FILE" 2>/dev/null || echo 0)
    echo -e "${suite}\t${COUNT} expectations"
done | column -t

echo ""
echo "=== Suite Detail ==="
SUITE="${1:-}"
if [ -n "$SUITE" ]; then
    SUITE_FILE="${GE_BASE}/expectations/$(echo $SUITE | tr '.' '/').json"
    jq -r '.expectations[] | "\(.expectation_type)\t\(.kwargs | to_entries | map("\(.key)=\(.value)") | join(", ") | .[0:60])"' \
        "$SUITE_FILE" | column -t | head -20
fi
```

### Validation Results Review

```bash
#!/bin/bash
echo "=== Recent Validation Results ==="
find "${GE_BASE}/uncommitted/validations" -name "*.json" -type f 2>/dev/null | \
    sort -r | head -10 | while read vfile; do
    jq -r '"Suite: \(.meta.expectation_suite_name)\tSuccess: \(.success)\tPassed: \([.results[] | select(.success)] | length)/\(.results | length)\tTime: \(.meta.run_id.run_time[0:16] // "?")"' "$vfile" 2>/dev/null
done | column -t

echo ""
echo "=== Failed Validations ==="
find "${GE_BASE}/uncommitted/validations" -name "*.json" -type f 2>/dev/null | \
    sort -r | head -20 | while read vfile; do
    FAILED=$(jq 'select(.success == false) | .meta.expectation_suite_name' "$vfile" 2>/dev/null)
    if [ -n "$FAILED" ]; then
        jq -r '"\(.meta.expectation_suite_name)\t\(.meta.run_id.run_time[0:16] // "?")\t\([.results[] | select(.success == false)] | length) failed"' "$vfile"
    fi
done | column -t
```

### Failed Expectation Details

```bash
#!/bin/bash
VALIDATION_FILE="${1:?Validation result file path required}"

echo "=== Validation Summary ==="
ge_parse_validation "$VALIDATION_FILE"

echo ""
echo "=== Failed Expectations ==="
jq -r '
    .results[] | select(.success == false) |
    "\(.expectation_config.expectation_type)\t\(.expectation_config.kwargs.column // "table-level")\tObserved: \(.result.observed_value // "N/A")"
' "$VALIDATION_FILE" | column -t | head -20

echo ""
echo "=== Unexpected Values (sample) ==="
jq -r '
    .results[] | select(.success == false) |
    select(.result.partial_unexpected_list != null) |
    "\(.expectation_config.kwargs.column): \(.result.partial_unexpected_list[:5] | join(", "))"
' "$VALIDATION_FILE" | head -10
```

### Checkpoint Execution

```bash
#!/bin/bash
CHECKPOINT="${1:?Checkpoint name required}"
DRY_RUN="${2:-true}"

if [ "$DRY_RUN" = "true" ]; then
    echo "=== Checkpoint Config: $CHECKPOINT ==="
    CKPT_FILE="${GE_BASE}/checkpoints/${CHECKPOINT}.yml"
    python3 -c "
import yaml
with open('${CKPT_FILE}') as f:
    config = yaml.safe_load(f)
print(f'Class: {config.get(\"class_name\", \"?\")}')
for vc in config.get('validations', []):
    print(f'  Suite: {vc.get(\"expectation_suite_name\", \"?\")}\tBatch: {vc.get(\"batch_request\", {}).get(\"datasource_name\", \"?\")}')
" 2>/dev/null
    echo ""
    echo "To execute, call with dry_run=false"
else
    echo "=== Running Checkpoint: $CHECKPOINT ==="
    cd "${GE_DIR}" && great_expectations checkpoint run "$CHECKPOINT" 2>&1 | tail -20
fi
```

### Data Docs and Documentation

```bash
#!/bin/bash
echo "=== Data Docs Sites ==="
python3 -c "
import yaml
with open('${GE_BASE}/great_expectations.yml') as f:
    config = yaml.safe_load(f)
for name, site in config.get('data_docs_sites', {}).items():
    store = site.get('store_backend', {})
    print(f'{name}\t{store.get(\"class_name\", \"?\")}\t{store.get(\"base_directory\", store.get(\"bucket\", \"?\"))}')
" 2>/dev/null | column -t

echo ""
echo "=== Build Data Docs ==="
echo "Run: great_expectations docs build --no-view"

echo ""
echo "=== Expectation Coverage ==="
ge_list_suites | while read suite; do
    SUITE_FILE="${GE_BASE}/expectations/$(echo $suite | tr '.' '/').json"
    TYPES=$(jq -r '[.expectations[].expectation_type] | unique | join(", ")' "$SUITE_FILE" 2>/dev/null)
    echo -e "${suite}\t${TYPES}"
done | column -t | head -15
```

## Output Format

Present results as a structured report:
```
Analyzing Great Expectations Report
═══════════════════════════════════
Resources discovered: [count]

Resource       Status    Key Metric    Issues
──────────────────────────────────────────────
[name]         [ok/warn] [value]       [findings]

Summary: [total] resources | [ok] healthy | [warn] warnings | [crit] critical
Action Items: [list of prioritized findings]
```

Target ≤50 lines of output. Use tables for multi-resource comparisons.

## Anti-Hallucination Rules

1. **NEVER assume resource names** — always discover via CLI/API in Phase 1 before referencing in Phase 2.
2. **NEVER fabricate metric names or dimensions** — verify against the service documentation or `--help` output.
3. **NEVER mix CLI commands between service versions** — confirm which version/API you are targeting.
4. **ALWAYS use the discovery → verify → analyze chain** — every resource referenced must have been discovered first.
5. **ALWAYS handle empty results gracefully** — an empty response is valid data, not an error to retry.

## Counter-Rationalizations

| Shortcut | Counter | Why |
|----------|---------|-----|
| "I'll skip discovery and check known resources" | Always run Phase 1 discovery first | Resource names change, new resources appear — assumed names cause errors |
| "The user only asked for a quick check" | Follow the full discovery → analysis flow | Quick checks miss critical issues; structured analysis catches silent failures |
| "Default configuration is probably fine" | Audit configuration explicitly | Defaults often leave logging, security, and optimization features disabled |
| "Metrics aren't needed for this" | Always check relevant metrics when available | API/CLI responses show current state; metrics reveal trends and intermittent issues |
| "I don't have access to that" | Try the command and report the actual error | Assumed permission failures prevent useful investigation; actual errors are informative |

## Common Pitfalls

- **Project root**: GE expects to be run from the project root containing `great_expectations/` directory
- **Suite naming**: Suite names use dots as separators that map to directory structure — `my_suite.orders` maps to `expectations/my_suite/orders.json`
- **Validation storage**: Results in `uncommitted/validations/` are gitignored by default — use a configured validations store for persistence
- **Config versions**: GE has had major config format changes (v2 vs v3) — check `config_version` in `great_expectations.yml`
- **Batch request**: V3 API uses batch requests with datasource/data_connector/data_asset — all three must match
- **Runtime vs stored**: Expectations can be created at runtime (not persisted) — only suites saved to disk appear in file listing
- **Checkpoint vs suite**: Checkpoints orchestrate validation runs against specific data batches — suites define the rules only
- **Data docs staleness**: Data docs are static HTML and must be rebuilt after new validations — they don't auto-update
- **Cloud vs OSS**: Great Expectations Cloud has its own API — OSS relies on file-based configuration and CLI

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…