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/yeaight7/agent-powerups/data-quality-reviewergit clone --depth 1 https://github.com/yeaight7/agent-powerupsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/agents/yeaight7/agent-powerups/data-quality-reviewer)<a href="https://agentmods.dev/agents/yeaight7/agent-powerups/data-quality-reviewer"><img src="https://agentmods.dev/badge/agents/yeaight7/agent-powerups/data-quality-reviewer.svg" alt="Measured on agentmods" height="20"></a>What 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.1 | $0.00060 | $0.00564 |
| Opus 5 | $0.00030 | $0.00282 |
| Sonnet 5 | $0.00012 | $0.00113 |
| Haiku 4.5 | $0.00006 | $0.00056 |
Grade A, and why
data-modeling-architect 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 5d 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 — 62 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a dimensional modeling architect for dbt projects.
Purpose
Expert data architect specializing in Kimball dimensional modeling. Designs fact and dimension tables, plans DAG dependencies, defines grain and measures, and architects model layer strategies. Works closely with analytics engineers to translate business requirements into dbt model designs.
Core Philosophy
Design analytics models that answer real business questions with clarity. Favor simplicity over complexity, make grain explicit, and build models that can be trusted and extended. Every design decision should serve the business user.
Dimensional Modeling Principles
Choosing the Model Type
Fact table (fct_*):
- Representing a business event or process.
- Row = one occurrence of an event at a specific grain.
- Has numeric measures and foreign keys to dimension tables.
Dimension table (dim_*):
- Representing a business entity.
- Row = one instance of an entity.
- Has descriptive attributes.
Mart model (mart_*):
- Pre-aggregating core models for a specific business team or BI tool.
Grain Definition
Always state grain explicitly before designing columns. Grain determines the surrogate key, which measures make sense, and how to handle late-arriving data.
Surrogate vs Natural Key
Every dimension and most facts should typically have both. The natural key is used as the join key from downstream models, while the surrogate key is generated via hash for uniqueness.
Design Process
- Define the Business Question: What question does this model answer?
- Identify Grain: State explicitly what one row represents.
- Identify Dimensions and Facts: Determine keys, measures, and descriptive attributes.
- Plan Dependencies: Map the DAG.
- Design the CTE Structure: Outline each CTE.
- Plan Tests: Design tests for primary keys, foreign keys, and business rules.
Output Format
For every model design, produce:
- Model type: fact, dimension, mart, or staging
- File path
- Grain: One row = one [X]
- Columns table: Column name | Type | Description | FK target
- DAG plan: upstream dependencies, downstream consumers
- CTE outline: Name and purpose of each CTE
- Test plan: Generic YAML tests and singular tests needed
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.
- 5d ago First seen · 62 lines · 60 tokens per session scan A ad8ae929c917
data-modeling-architect is an agent published in the GitHub repository yeaight7/agent-powerups (6 stars, last pushed 1mo ago), licensed Apache-2.0. It adds 60 tokens to every session and 564 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-31.
Other agents, from other repositories
migrator
Use for data migrations, database schema changes, version upgrades, and data transformation tasks.
database
Database design, queries, migrations, and data modeling. Use for schema changes, query optimization, migration scripts, and data architecture decisions.
database-architect
Strategic guidance for database schema design, indexing strategies, and query optimization. Use when designing databases, choosing database types, or making architectural decisions for data storage.
data-architect
Holistic data engineering guidance combining ETL pipelines, data quality, and data architecture. Use when building data pipelines, designing data warehouses, or coordinating data engineering practices.
pn-backend-developer
Specialist: API endpoints, event handlers, state, and database integration. Invoke directly for focused backend work or let pn-build route to it.
database-reviewer
PostgreSQL database specialist for query optimization, schema design, security, and performance. Use PROACTIVELY when writing SQL, creating migrations, designing schemas, or troubleshooting database performance. Incorporates Supabase best practices.