// Deep reliability audit for OpenMetadata connectors — runs 7 investigation prompts (metadata, errors, auth, lineage, scale, synthesis, implementation) against connector standards
| name | connector-audit |
| description | Deep reliability audit for OpenMetadata connectors — runs 7 investigation prompts (metadata, errors, auth, lineage, scale, synthesis, implementation) against connector standards |
When a user asks to audit a connector, run a reliability audit, or investigate connector quality in depth.
When this skill is invoked, your VERY FIRST action — before responding to the user, before summarizing anything, before checking any state — is:
.claude/audit-results/ (if the directory exists).claude/connector-audit.json (if it exists)If no files exist, skip to Step 2.
NEVER summarize existing results, say "the audit is complete", or suggest the user doesn't need to run anything. The user invoked the skill — execute it.
mysql, snowflake, tableau): Full 7-prompt audit--prompt N (e.g., --prompt 3): Run a single prompt (1-7) — useful for re-running after fixes--prompts N,M (e.g., --prompts 1,4): Run specific prompts only--from N (e.g., --from 6): Run prompts N through 7 — useful for continuing after P1-P5--setup-only: Run setup only (writes connector-audit.json)--dry-run: When used with P7, produce a detailed implementation plan (before/after diffs, tests, risk flags) without actually writing code — for review before execution| connector-audit | connector-review | |
|---|---|---|
| Purpose | Deep reliability investigation | Breadth check for PRs |
| Depth | 7 focused prompts, hours of analysis | 5 parallel agents, minutes |
| Output | .claude/audit-results/ (7 reports) | PR comment or local report |
| When | Before major work on a connector | During PR review |
| Scope | Full connector + base classes + shared code | Changed files only |
Setup → P1-P5 (investigation, parallelizable) → P6 (synthesis) → P7 (implementation)
After the stale results check (Step 1 above), run the setup prompt to establish connector context. This writes .claude/connector-audit.json which all subsequent prompts read.
Run the static analyzer from the connector-review skill to get a mechanical baseline:
python skills/connector-review/scripts/analyze_connector.py {service_type} {name} --json
Save the output — prompts reference it to avoid duplicating mechanical checks.
These 5 prompts are independent and can run in any order. For efficiency, dispatch them in parallel:
Each prompt:
.claude/connector-audit.json for context/connector-standards.claude/audit-results/ using the fixed filename for that prompt described in the Output Structure section (for example, 01-metadata-ingestion.md for P1) after user approvalUser review gate: Each prompt presents findings and asks for confirmation before saving. This catches errors early instead of propagating them to P6.
Reads all 5 reports from .claude/audit-results/, cross-validates findings, clusters root causes, checks git history, and produces a prioritized implementation plan with PR scoping.
Reads the P6 plan and implements the fixes — writes code, runs tests, creates commits. With --dry-run, produces a detailed plan (before/after diffs, test code, risk flags) without writing code.
Each prompt is a self-contained investigation guide in prompts/:
| # | File | Focus | Standards |
|---|---|---|---|
| 0 | 00-setup.md | Set target connector, write context file | — |
| 1 | 01-metadata-ingestion.md | Metadata coverage by tier, ingestion completeness | Tiers 1-3, Standard 1 |
| 2 | 02-error-handling.md | Error handling, fault tolerance, observability | Standards 4, 5, 7 |
| 3 | 03-connection-auth.md | Auth methods, test connection, SSL/TLS | Standard 3 |
| 4 | 04-lineage.md | SQL dialect, FQN resolution, column lineage | Standard 2 |
| 5 | 05-scale-performance.md | Memory patterns, pagination, generators, lookups | Standard 6 |
| 6 | 06-refactor-plan.md | Cross-validate, cluster root causes, PR scoping | All standards |
| 7 | 07-implementation.md | Implement fixes (or --dry-run for plan only) | All standards |
/connector-audit mysql
.claude/audit-results/, ask user what to keep/delete, wait for answer.claude/connector-audit.jsonanalyze_connector.py for mechanical baselineprompts/0N-*.md
b. Follow its instructions — read the actual connector source code, analyze it against the standards, produce findings with file:line references
c. Present a summary to the user for review
d. Save the report to .claude/audit-results/ after user approval.claude/audit-results/, synthesize, present implementation plan, save after approval--dry-run for plan only), save after approvalEach prompt is a detailed investigation guide — it tells you exactly which files to read, what to look for, how to rate findings, and what format to present them in. You must actually read the connector's source code and do the analysis, not summarize previous results.
/connector-audit mysql --prompt 3
Verify .claude/connector-audit.json exists, then read the prompt file and execute only that investigation.
When running the full audit, dispatch P1-P5 using Agent subagents for parallelism:
Important: Each agent must present its summary and get user approval before saving. When running in parallel pairs, present both summaries together.
All prompts reference connector standards loaded via /connector-standards. The standards live at:
skills/connector-review/standards/ — shared standards (main.md, patterns.md, etc.)skills/connector-review/standards/source_types/ — per-service-type standardsThe static analyzer at skills/connector-review/scripts/analyze_connector.py provides mechanical checks that complement the deeper investigation in each prompt.
.claude/
├── connector-audit.json # Connector context (written by Setup)
└── audit-results/
├── 01-metadata-ingestion.md # P1 report
├── 02-error-handling.md # P2 report
├── 03-connection-auth.md # P3 report
├── 04-lineage.md # P4 report
├── 05-scale-performance.md # P5 report
├── 06-refactor-plan.md # P6 consolidated plan
└── 07-implementation.md # P7 implementation report (or 07-dry-run-implementation.md with --dry-run)
Each prompt report follows the template in templates/audit-report.md. Key sections:
Use to review code changes with a two-stage process - first checking spec/requirements compliance, then code quality. Works on staged changes, branches, or PRs.
Meta-skill loaded at session start. Directs Claude to check for applicable OpenMetadata skills before starting any task. Ensures structured workflows are followed.
Use when starting a non-trivial feature, refactor, or multi-file change. Forces structured design thinking before writing any code - brainstorm approaches, get approval, then create a step-by-step implementation plan.
Use when implementing new features or fixing bugs to enforce test-driven development. Guides the RED-GREEN-REFACTOR cycle for Java (JUnit), Python (pytest), and TypeScript (Jest/Playwright) in OpenMetadata.
Use before claiming any task is complete. Requires running actual verification commands and showing evidence — no "should work" claims without proof.
Build a new OpenMetadata connector from scratch — scaffold JSON Schema, Python boilerplate, and AI context using schema-first architecture with code generation across Python, Java, TypeScript, and auto-rendered UI forms.