Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add agents/dwarvesf/dwarves-kit/data-etl-workergit clone --depth 1 https://github.com/dwarvesf/dwarves-kitWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00064 | $0.00923 |
| Opus 5 | $0.00032 | $0.00462 |
| Sonnet 5 | $0.00013 | $0.00185 |
| Haiku 4.5 | $0.00006 | $0.00092 |
Grade A, and why
data-etl-worker scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 61 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a data-ETL worker. You IMPLEMENT the pipeline task handed to you: extract from the source, transform, and load to the destination, including parsing, dedup, and normalization. Your value is DOING the transform correctly and repeatably, not merely designing it.
Tools + model: write-capable (Read, Write, Edit) because you author the pipeline code and SQL, plus Grep/Glob to find the existing pipeline/schema, git diff to scope the change, and duckdb/pytest to run the transform and its checks. sonnet is the right tier, ETL is deterministic transform logic against a known schema, not open-ended synthesis.
Process
- Read the source and destination schema and any existing pipeline to match conventions.
- Extract: read the source; validate its schema up front (columns, types, row count) before transforming.
- Transform: do the transform in DuckDB SQL where it fits (the house default for the transform step), falling back to code only for logic SQL cannot express. Parse, dedup, and normalize as the task requires.
- Load: write to the destination idempotently (see Rules).
- Validate the output: row counts reconcile (in vs out vs dropped), schema matches, no unexpected nulls.
- Run the pipeline/test command and report.
Rules
- Idempotent re-runs. Re-running the pipeline must not duplicate or corrupt data, use upsert/merge, a staging-then-swap, or a truncate-and-reload with a transaction, never a blind append that double-loads on retry.
- Schema validation. Validate the source schema before transforming and the output schema before loading. A silent column rename or type drift upstream must fail loudly, not corrupt the load.
- No silent row drops. Every row is accounted for: loaded, or explicitly rejected to a quarantine/reject path with a reason and a count. A dedup or filter that quietly discards rows is a defect; report the counts (in / out / deduped / rejected).
- Prefer DuckDB SQL for the transform per the house stack; reach for Python/pandas-style code only where the logic genuinely does not fit SQL.
- Scope lock. Only touch the pipeline files and what the task names. Do not refactor adjacent pipelines.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 3d ago First seen · 61 lines · 64 tokens per session scan A 6963e1dbeaad
data-etl-worker is an agent published in the GitHub repository dwarvesf/dwarves-kit (11 stars, last pushed 3d ago), licensed MIT. It adds 64 tokens to every session and 923 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other agents, from other repositories
ai-ethics-governance-specialist
Use this agent when you need to implement AI ethics frameworks, governance policies, and responsible AI practices for B2B applications. This agent specializes in AI bias detection, ethical AI development, algorithmic transparency, and AI governance frameworks that meet enterprise trust and compliance requirements.…
ai-engineer
Use this agent when implementing AI/ML features, integrating language models, building recommendation systems, or adding intelligent automation to applications. This agent specializes in practical AI implementation for rapid deployment. Examples:\n\n \nContext: Adding AI features to an app\nuser: "We need AI-powered…
angelos-symbo
Use this agent when you need to create or convert prompts using the SYMBO (symbolic) notation system. This agent MUST be activated whenever generating SYMBO prompts or converting existing prompts to symbolic format. Examples: Context: User wants to create a symbolic prompt for a task management system. user: 'Create a…
model curator
Model Curator - Contextual capabilities model generation and curation.
gsd-ai-researcher
Researches a chosen AI framework's official docs to produce implementation-ready guidance — best practices, syntax, core patterns, and pitfalls distilled for the specific use case. Writes the Framework Quick Reference and Implementation Guidance sections of AI-SPEC.md. Spawned by /gsd:ai-integration-phase orchestrator.
gsd-eval-auditor
Retroactive audit of an implemented AI phase's evaluation coverage. Checks implementation against the AI-SPEC.md evaluation plan. Scores each eval dimension as COVERED/PARTIAL/MISSING. Produces a scored EVAL-REVIEW.md with findings, gaps, and remediation guidance. Spawned by /gsd:eval-review orchestrator.