菜单
Runs a unified source→(ontological transform)→sink ETL flow over the KG hub — pull any connector in and/or load a write-back SoR, graph store, or engine SQL table out, with lineage. Use for cross-system data movement — "ETL servicenow into stardog", "list ETL sources/sinks", "show ETL lineage".
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Turns the manual "validate a fleet package/skill, run its tests, delegate a grounded task to it, hunt for known bug-classes, and feed findings back into the KG" process into a SELF-HOSTED, delegation-ready capability the local LLM runs against ANY target — a fleet agent under agent-packages/agents/*, the agent-utilities package itself, or a universal-skill / agent-utilities skill. Composes existing primitives (graph_orchestrate execute_agent, graph_write, graph_feedback, pytest via the tier4 pattern, deterministic structural/bug-class scans) rather than re-implementing them. Use when asked to "validate <target>", "test this agent/skill end to end", "bug-hunt the fleet", "run ecosystem validation", or to set up continuous automated fleet validation via the loop engine or the scheduler.
Evolve the agent-utilities repository by implementing the latest research concepts against it. Orchestrates research-scanner → kg-ingest → comparative-analysis → SDD implementer into a unified pipeline. Queries the KG for hot topics, finds relevant papers, ingests them, runs comparative analysis, and generates SDD plans with constitution-mandated artifact requirements baked in. Can run as a background daemon (every 60 minutes) via the KG engine's evolution cycle. Triggers on "evolve agent-utilities", "run evolution pipeline", "find and implement research", "research-driven development", "auto-evolve", "evolution scan". Also includes AST-based wiring sweep for concept traceability, dead code detection, and import graph analysis. Triggers on "wiring sweep", "concept audit", "dead code analysis", "traceability check", "code health".
Runs UQL — the epistemic-graph engine's native cross-modal Unified Query Language — a single pipelined text query that composes graph traversal, vector/ANN ranking, BM25 text search, relational (DataFusion) filtering, bi-temporal AS-OF/WINDOW, OWL reasoning, federation, and epistemic belief/evidence ops over ONE snapshot with no impedance mismatch between modalities. Use when a question spans more than one modality in one breath — "find docs about X, then rank by similarity to this vector, then only the ones live as of last month", "traverse citations then diversify the top results", "what supports this claim, discounted by our confidence at the time" — or whenever you'd otherwise chain several separate Cypher/SQL/vector calls by hand.
Tamper-evident audit ledger (G23): verifies the engine's hash-chained durable-mutation audit log and reconstructs "what happened to entity X" from the KG's own :ToolCall provenance. Use for "verify the audit chain", "is our audit log tamper-evident", "has anything mutated entity X and in what order", "reverse-index the tool calls that touched this node".
Compliance posture rollup + redacted bulk export — joins the tamper-evident hash-chained audit ledger with governance node counts (Control/Policy/Risk/ ComplianceRequirement/ComplianceGate/Regulation/Assessment/Incident/Finding/... already ingested from CISO Assistant + the TRM portfolio-intelligence engine) into one auditor-facing view, and bulk-exports a redacted subgraph via the engine's own disclosure_level (Full/Skeleton/ExistenceOnly) redaction. Use for "what's our compliance posture", "is the audit chain intact", "export these controls redacted for an auditor", "how many open compliance gaps do we have".
Answers a question and returns its full epistemic justification, not just the row — calibrated confidence + provenance/evidence refs + bitemporal valid/tx time (the KnowledgeBatch "currency upgrade"), the belief's justification tree (Asserted / DerivedSupport / DerivedContradiction / BayesianUpdate), the acceptance capstone (believed? since when? on what evidence? what would flip it?), a bitemporal what-changed diff between two transaction times, and — when policy hid something — which rows were denied and why. Use when an answer alone isn't enough — "why do we believe this", "how confident are we and why", "what would invalidate this", "what changed between these two points in time", "why was this row filtered out".
| name | kg-etl |
| skill_type | skill |
| description | Runs a unified source→(ontological transform)→sink ETL flow over the KG hub — pull any connector in and/or load a write-back SoR, graph store, or engine SQL table out, with lineage. Use for cross-system data movement — "ETL servicenow into stardog", "list ETL sources/sinks", "show ETL lineage". |
| license | MIT |
| tags | ["graph-os","ingestion","etl"] |
| tier | core |
| metadata | {"author":"Genius","version":"0.1.0"} |
Condensed intent-surface note (Seam 8). Under the default intent surface (
MCP_TOOL_MODE=intent),graph_etlis held back from the default tool list (nothing removed — REST +_execute_toolstill reach it exactly as documented below). Two ways to use this skill unchanged: (1)load_tools(tools=["graph_etl"])once per session (as below), then proceed exactly as documented; or (2) call thewriteintent verb with the same natural-language request — the resolver routes tograph_etlfor you and returns the result plus a routing justification. SetMCP_TOOL_MODE=condensed/verbose/bothto expose the granular tools eagerly instead.
graph_etl (CONCEPT:AU-KG.ontology.one-source) composes ingestion + write-back + graph-store machinery. action='run': pull source into the KG (any registered ingestion source; mode delta|full|reconcile) and/or load sink from the KG — sink is a write-back SoR (dry-run + approval, pass ops_json), a graph store (stardog/neo4j/age/jena_fuseki or a registered connection), or the native engine SQL table (sink='table'). action='list' shows sources/sinks/backends; action='lineage' shows recorded runs (AU-KG.ontology.kg-3).
load_tools(tools=["graph_etl"]), then graph_etl(action="list").POST /graph/etl with {"action": "run", "source": "servicenow", "sink": "stardog", "mode": "delta"}.graph_etl(action="run", source="leanix", sink="table", ops_json='{"table":"apps","replace":true}')
If graph-os is reachable, offload composite multi-step work via graph_orchestrate (execute_agent / execute_workflow) instead of hand-running the steps — let the local LLM + Loop engine do it, and resolve only the exceptions.