dataspoke-baseline

Reference and coding guide for DataHub integration in backend development. Use when implementing or debugging code that touches DataHub — entities (datasets, dashboards, charts), aspects (ownership, tags, domains, glossary terms, structured properties), lineage, assertions, URNs, ingestion/emission, GraphQL, REST, or the acryl-datahub Python SDK. Also answers data-modeling questions and helps choose native DataHub features vs custom extensions. Trigger this skill whenever a task involves DataHub metadata, lineage, ingestion, or any DataHub API surface, even without explicit mention of "API".

Drive the helm-charts/bin/ install/uninstall/build/health scripts for both dev and prod profiles — configure, install, reinstall, uninstall, health-check, and rebuild-the-API / rebuild-the-frontend. The dev profile installs umbrella chart + peripherals (nginx-ingress, DataHub, Langfuse, dummy data, dev-lock) and auto-seeds peripheral connection config via the admin API. The prod profile installs the umbrella chart only; operator wires peripherals via /api/v1/admin/peripherals/*.

Walk a single api-wired UC scenario through the browser UI manually: for each step in the source test file, print the UI gesture (page + action), ask you to perform it and report what you observed, then independently probe the backend (REST read-back, DB rows, DataHub aspects, k8s secrets) to confirm the side effect fired. The human-driven sibling of the automated `tests/e2e/` use-case group — same scenarios, with a human at the browser. Optional argument `scope` selects the case (free-form: "UC1", "UC1 Case 2", "passive kafka", filename fragment, etc.).

Bidirectional sync between DataSpoke specs and implementation. Accepts a preset scope (prauto, ai-scaffold, k8s-deploy, helm-charts, api, ref, backend, frontend, all) or a free-form description of an area (e.g., "recently developed backend ingestion secret resolution"). Audits the scope, reports the gaps, asks the user which direction to resolve each gap (spec→impl, impl→spec, or leave-as-flagged), then applies the chosen edits. Trigger when specs and code may have drifted apart and the user wants them reconciled.

Download AI reference materials (external source code for AI assistant reference). Offers individual or all references.

Author timeless specification documents under spec/ (top-level or spec/feature/<FEATURE>.md) following the project hierarchy, naming conventions, and templates. Use when the user asks to write, design, or document a DataSpoke feature, component, or architectural decision as a reference spec. Do NOT use for implementation plans — those live in GitHub issues/PRs and are produced by native Plan mode or PRauto.

Connect this plugin to a deployed DataSpoke and verify access. Use to point Claude at a DataSpoke deployment (API base URL + dsk_ API token), mint a token from email/password, or check who you are and what role you hold. Prerequisite for every other dataspoke-* skill — run this first, or when calls start returning 401.

Manage DataSpoke validation (UC2) and author validation routines into your own data pipeline. Use to register/edit a dataset's validation slot, post or query results, browse the cross-dataset list — and, the flagship capability, to generate a validation routine (compute metrics, fetch baseline, forecast, decide score, POST result) into the engineer's pipeline script. Triggers on "add a validation routine", "validate table X", "register validation metrics".

Manage the Kubernetes development cluster — health checks, continuous monitoring, kubectl/helm operations, and troubleshooting.

Walk a single api-wired UC scenario manually: read the source test file, print each REST request, ask for approval, fire it, print the response, and probe side effects (DB rows, DataHub aspects, k8s secrets). Optional argument `scope` selects the case (free-form: "UC1", "UC1 Case 2", "passive kafka", filename fragment, etc.).

Answer questions about DataSpoke Governance metrics (UC5) on a deployed instance and make read calls against its public API. Stub — knows the route prefix and points at the deployment's live OpenAPI reference; not yet a full metric-authoring workflow. Use for "what does governance expose" or basic reads.

Manage DataSpoke ingestion sources (UC1) on a deployed instance — list and inspect sources, create or edit ACTIVE_CUSTOM_MANAGED and PASSIVE sources, trigger dry-run and real extractor runs, and review run history, emitted datasets, and the unmanaged bucket. Use for any "register/check ingestion" or "is this dataset ingested" question. Answers questions and, on request, writes and fires the API calls.

Answer questions about DataSpoke Metadata Generation (UC4) on a deployed instance and make read calls against its public API. Stub — knows the route prefix and points at the deployment's live OpenAPI reference; not yet a full authoring/review workflow. Use for "what does metagen expose" or basic reads.

Answer questions about DataSpoke Ontology Generation (UC3) on a deployed instance and make read calls against its public API. Stub — knows the route prefix and points at the deployment's live OpenAPI reference; not yet a full authoring workflow. Use for "what does ontogen expose" or basic reads.

Propagate spec changes to sibling/parent specs and harness docs. Use when a spec is created, modified, or deleted and dependent documents need updating — including updating references in ARCHITECTURE.md, README.md, CLAUDE.md, or USE_CASE; adding new specs to feature mapping tables; fixing cross-references between related specs; or removing dead links. Invoke this skill whenever you need to "update parent/sibling spec references", "keep specs consistent", or "propagate changes up/down the spec hierarchy", even without an explicit user request.

Test-run the prauto heartbeat script and monitor its progress. Diagnoses and fixes script errors on failure.

Audit and trim bloated specs, AI scaffold docs, and READMEs. Removes implementation details (code blocks, directory trees, method signatures), eliminates duplication across document tiers, and ensures each document stays at its appropriate abstraction level. Use when documents have grown fat from development iterations and need trimming back to architecture, decisions, and constraints.

Analyze spec documents to find unimplemented components, write ordered issue tickets as markdown files in issues/, revise existing issue files against current specs and implementation, and optionally register them to GitHub with the prauto:ready label. Use when the user wants to bulk-create implementation issues from specs, or revise existing issues.

Query GitHub to display prauto-managed issues and PRs across lifecycle labels (ready, wip, plan-review, review, done, failed) and predict the next heartbeat action. Use when the user asks about prauto work status, backlog, specific issue pickup, failed jobs, PR approval/merge readiness, reviewer feedback, quota-pause state, or wants a status dashboard.