Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

dataspoke-ingestion

Étoiles15

Forks1

Mis à jour16 juin 2026 à 15:03

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.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

selhorys

selhorys/dataspoke-baseline

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Développeurs de logicielsProfessions informatiques et mathématiques·SOC 15-1252

SKILL.md

readonly

name	dataspoke-ingestion
description	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.
argument-hint	[question or action]
allowed-tools	Read, Bash(dataspoke-api *), AskUserQuestion

Purpose

Drive Ingestion Control (UC1) through the public API. Acts as a question-answerer about how ingestion works and, when the user asks, an API writer/launcher. Every call goes through dataspoke-api; if it reports no access, send the user to /dataspoke:dataspoke-access first.

Source modes

DATAHUB_MANAGED — synced from DataHub; read-only here (cannot be authored/edited).
ACTIVE_CUSTOM_MANAGED — DataSpoke-owned extractor with a recipe + schedule; runnable.
PASSIVE — an external ingestor with a declared scope; observed, not run by DataSpoke.

Capabilities → routes

Intent	Call
List sources (optionally `?mode=…`)	`dataspoke-api GET /spoke/ingestion/sources`
Inspect one source	`dataspoke-api GET /spoke/ingestion/sources/{id}`
Create a source	`dataspoke-api POST /spoke/ingestion/sources '<json>'`
Replace / update	`dataspoke-api PUT
Delete a source	`dataspoke-api DELETE /spoke/ingestion/sources/{id}`
Dry-run (connection check, no writes)	`dataspoke-api POST '/spoke/ingestion/sources/{id}/method/run?dry_run=true' '{}'`
Real run	`dataspoke-api POST /spoke/ingestion/sources/{id}/method/run '{}'`
Run / event history	`dataspoke-api GET /spoke/ingestion/sources/{id}/event`
Datasets covered by a source	`dataspoke-api GET /spoke/ingestion/sources/{id}/datasets`
Datasets covered by no source	`dataspoke-api GET /spoke/ingestion/unmanaged`
Available credential refs (Editor+)	`dataspoke-api GET /spoke/ingestion/secrets`
Reverse lookup for a dataset	`dataspoke-api GET /spoke/common/data/{urn}/attr/ingestion`

Operating rules

Always dry-run before a real run on ACTIVE_CUSTOM_MANAGED sources, and show the user the dry-run result before firing the real run.
Confirm before any write (create/update/delete/run): restate the source name, mode, and schedule, and get explicit agreement.
Recipes reference credentials as ${secret_name__key} placeholders — never inline a plaintext secret. Discover available refs with GET /spoke/ingestion/secrets.
Surface conflict codes (409 INGESTION_SOURCE_READONLY, 409 INGESTION_RUNNING, 409 INGESTION_RUN_NOT_APPLICABLE) and 403 READ_ONLY_ROLE verbatim — do not work around them.
After a real run, poll …/event (and …/datasets) to confirm completion and emitted datasets; newly ingested datasets can lag a couple of minutes in DataHub search.

Plus depuis ce dépôt

même dépôt

datahub-api

selhorys/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".

2026-07-2115

k8s-deploy

selhorys/dataspoke-baseline

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/*.

2026-07-2115

test-manual-ui

selhorys/dataspoke-baseline

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.).

2026-06-3015

spec-sync-with-impl

selhorys/dataspoke-baseline

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.

2026-06-2815

ref-setup

selhorys/dataspoke-baseline

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

2026-06-2715

spec-write

selhorys/dataspoke-baseline

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.

2026-06-2615

name	dataspoke-ingestion
description	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.
argument-hint	[question or action]
allowed-tools	Read, Bash(dataspoke-api *), AskUserQuestion

Purpose

Source modes

DATAHUB_MANAGED — synced from DataHub; read-only here (cannot be authored/edited).
ACTIVE_CUSTOM_MANAGED — DataSpoke-owned extractor with a recipe + schedule; runnable.
PASSIVE — an external ingestor with a declared scope; observed, not run by DataSpoke.

Capabilities → routes

Intent	Call
List sources (optionally `?mode=…`)	`dataspoke-api GET /spoke/ingestion/sources`
Inspect one source	`dataspoke-api GET /spoke/ingestion/sources/{id}`
Create a source	`dataspoke-api POST /spoke/ingestion/sources '<json>'`
Replace / update	`dataspoke-api PUT
Delete a source	`dataspoke-api DELETE /spoke/ingestion/sources/{id}`
Dry-run (connection check, no writes)	`dataspoke-api POST '/spoke/ingestion/sources/{id}/method/run?dry_run=true' '{}'`
Real run	`dataspoke-api POST /spoke/ingestion/sources/{id}/method/run '{}'`
Run / event history	`dataspoke-api GET /spoke/ingestion/sources/{id}/event`
Datasets covered by a source	`dataspoke-api GET /spoke/ingestion/sources/{id}/datasets`
Datasets covered by no source	`dataspoke-api GET /spoke/ingestion/unmanaged`
Available credential refs (Editor+)	`dataspoke-api GET /spoke/ingestion/secrets`
Reverse lookup for a dataset	`dataspoke-api GET /spoke/common/data/{urn}/attr/ingestion`

Operating rules

Always dry-run before a real run on ACTIVE_CUSTOM_MANAGED sources, and show the user the dry-run result before firing the real run.
Confirm before any write (create/update/delete/run): restate the source name, mode, and schedule, and get explicit agreement.
Recipes reference credentials as ${secret_name__key} placeholders — never inline a plaintext secret. Discover available refs with GET /spoke/ingestion/secrets.
Surface conflict codes (409 INGESTION_SOURCE_READONLY, 409 INGESTION_RUNNING, 409 INGESTION_RUN_NOT_APPLICABLE) and 403 READ_ONLY_ROLE verbatim — do not work around them.
After a real run, poll …/event (and …/datasets) to confirm completion and emitted datasets; newly ingested datasets can lag a couple of minutes in DataHub search.