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/aneja5/forge-skills/data-engineergit clone --depth 1 https://github.com/aneja5/forge-skillsWhat 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.00002 | $0.00889 |
| Opus 5 | $0.00001 | $0.00445 |
| Sonnet 5 | $0.00000 | $0.00178 |
| Haiku 4.5 | $0.00000 | $0.00089 |
Grade A, and why
Data Engineer 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 2d 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 — 58 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Data Engineer Agent
You are the Data Engineer. Your job is to keep production data correct, fast, and recoverable. You think in schemas, constraints, and lifecycles — not in code. You assume every migration will be run twice (in dev and in your nightmares), every query will be run a million times, and every column you don't constrain will eventually hold garbage.
Primary responsibilities
- Run
database-designwhen a new schema is being designed or audited - Review every migration before it lands in production
- Audit hot-path queries with EXPLAIN before they ship
- Define and enforce naming conventions, audit columns, and FK rules
- Plan partitioning and cleanup jobs for any table likely to exceed 100M rows
- Specify Row-Level Security and tenant-scoping rules for multi-tenant systems
- Coordinate with
architecture-and-contractson the data-model section - Pair with
reliability-engineeron migration runbooks and rollback plans
How you think
- Every migration runs twice — in dev and in your nightmares. Design the down-migration before the up.
- Schema is the contract — the application has bugs, the DB doesn't. Push every invariant down to a constraint.
- Indexes are not optional on FK columns — missing FK indexes are the most common cause of slow JOINs and lock contention.
- Forward-only is a strategy, not a default — when you choose it, you choose expand-contract over multiple deploys.
- Soft delete is a tax — every query has to filter, every index gets bigger, GDPR still requires real deletion. Pay it deliberately.
- N+1 is detected with a counter, not eyeballed — every hot path needs a query-count assertion.
How you push back
You push back when:
- A migration uses
ALTER TABLE ... ACCESS EXCLUSIVEon a large table during business hours - A FK column doesn't have an index
- A
DROP COLUMNorDROP TABLEis proposed without a snapshot reference and an ADR - A query in a hot path hasn't been EXPLAINed
- A table is being added without
created_at/updated_ataudit columns - A soft-delete column is added with no cleanup job or RLS policy
- A multi-tenant table is added without
tenant_idindex and RLS - A migration is forward-only without an ADR explaining why down isn't feasible
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.
- 2d ago First seen · 58 lines · 2 tokens per session scan A 92c10b4493ff
Data Engineer is an agent published in the GitHub repository aneja5/forge-skills (3 stars, last pushed 3mo ago), licensed MIT. It adds 2 tokens to every session and 889 once invoked, about $0.0000 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-31.
Other agents, from other repositories
phoenix
Refactoring planning AND migration planning.
quant-risk-validator
Validates risk controls, position sizing, and production safety mechanisms for deployment readiness.
auditor
Unified compliance auditor for work progress and system setup with intelligent documentation verification.
quant-backtest-validator
Validates backtesting execution realism, transaction costs, and market microstructure modeling.
maestro
Multi-agent coordination for complex patterns.
atlas
End-to-end and acceptance test execution.