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 skills add niels-emmer/myace --skill data-integritygit clone --depth 1 https://github.com/niels-emmer/myaceWrote 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/skills/niels-emmer/myace/data-integrity)<a href="https://agentmods.dev/skills/niels-emmer/myace/data-integrity"><img src="https://agentmods.dev/badge/skills/niels-emmer/myace/data-integrity/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/niels-emmer/myace/data-integrity"><img src="https://agentmods.dev/badge/skills/niels-emmer/myace/data-integrity.svg" alt="Reviewed on agentmods" width="80" 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.00024 | $0.00520 |
| Opus 5 | $0.00012 | $0.00260 |
| Sonnet 5 | $0.00005 | $0.00104 |
| Haiku 4.5 | $0.00002 | $0.00052 |
Grade A, and why
Data Integrity 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 7d 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.
What it actually says
Purpose
Data integrity failures are the most expensive bugs a system can have — they corrupt state that other code, reports, and users depend on, and they're often discovered long after the damage. This skill is a checklist for protecting correctness at the database layer rather than hoping application code gets it right.
When to use it
Whenever a change writes data — new writes, updates, deletes, or batch operations — or when reviewing a change that does. The discipline matters most for multi-step operations where a partial failure would leave inconsistent state.
Checklist
- Use transactions for multi-step writes. If an operation updates several rows or tables, it belongs in a transaction so a failure doesn't leave a half-applied state. Know your database's isolation level and what it actually guarantees.
- Prefer idempotent writes. Design mutating operations so retries are safe: idempotency keys, uniqueness constraints, or naturally idempotent operations (
set status = Xoverincrement counter). A retried request should not double-apply. - Let the DB enforce referential integrity. Foreign keys prevent orphaned rows. If you're deleting a parent, decide explicitly what happens to children (cascade, restrict, nullify) — don't leave it to application code to remember.
- Make delete semantics explicit. Soft-delete vs. hard-delete is a per-entity decision, not a default. If soft-delete, every read path must filter deleted rows; if hard-delete, the data is gone — say so.
- Never silently coerce or truncate. A write that drops data to make a constraint pass (truncating a string, coercing a type, swallowing a uniqueness violation) is hiding a bug, not fixing one.
- Verify under failure. Test what happens when a write fails partway — a transaction that rolls back cleanly is verified code, not assumed code.
Expected output
Writes that are transactional where they span multiple steps, idempotent where retries are possible, protected by DB-level referential integrity, and explicit about delete semantics — with failure paths tested rather than assumed.
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.
- 7d ago First seen · 28 lines · 24 tokens per session scan A 3b4798a734b5
Data Integrity is a skill published in the GitHub repository niels-emmer/myace (1 stars, last pushed 4d ago), licensed MIT. It adds 24 tokens to every session and 520 once invoked, about $0.0001 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-09-03.
Other skills, from other repositories
loom-database-design
Database schema and data model design for relational, NoSQL, time-series, and warehouse systems.
loom-sql-optimization
Analyzes and optimizes SQL queries for performance.
loom-caching
Caching strategies for performance optimization — cache-aside, write-through, write-behind, TTL policies, eviction, and stampede prevention.
loom-search
Full-text search and search engine implementation.
supabase
Configure Supabase for Next.js SaaS: Drizzle + pooler, Google-only Auth, RLS, cost optimization. Use when setting up Supabase, connecting Drizzle, SSR auth, or optimizing costs.
database-testing
Database schema validation, data integrity testing, migration testing, transaction isolation, and query performance. Use when testing data persistence, ensuring referential integrity, or validating database migrations.