Execute qualquer Skill no Manus
com um clique

Execute qualquer Skill no Manus com um clique

dataspoke-ingestion

Estrelas15

Forks1

Atualizado16 de junho de 2026 às 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.

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Executar no Manus

Fonte

selhorys

selhorys/dataspoke-baseline

Abrir repositório GitHub Ver repositórios do creator

Download

Executar no Manus

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Desenvolvedores de softwareInformática e Matemática·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.

Mais deste repositório

mesmo repositório

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.