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 skills/vindm/dotclaude/datanpx skills add vindm/dotclaude --skill datagit clone --depth 1 https://github.com/vindm/dotclaudeWhat 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.00100 | $0.03597 |
| Opus 5 | $0.00050 | $0.01799 |
| Sonnet 5 | $0.00020 | $0.00719 |
| Haiku 4.5 | $0.00010 | $0.00360 |
Grade A, and why
data 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 yesterday.
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 — 198 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/dotclaude:data — database + persistent-state discipline kit
You are setting up the data layer's audit + safety discipline. The output is a .claude/ subset focused on what code review and tests can't catch: latent corruption / drift / orphans in the actual data, migration safety, query cost, and access-policy correctness.
The data-auditor agent runs the five-category integrity sweep; the migration-create skill enforces the four-step migration workflow; the query-discipline rule prevents the unbounded-MCP-DB-read class of token waste.
Phase 1 — Read the project's data shape
Before any question:
-
DB platform + ORM / framework — read whichever exists:
cat package.json 2>/dev/null | grep -E "supabase|prisma|drizzle|knex|sequelize|typeorm|mongodb|mongoose|sqlite|pg|mysql" cat Cargo.toml 2>/dev/null | grep -E "sqlx|diesel|sea-orm|tokio-postgres" cat pyproject.toml 2>/dev/null | grep -E "alembic|sqlalchemy|django|asyncpg|psycopg|pymongo" cat go.mod 2>/dev/null | grep -E "gorm|sqlx|ent|mongo-go-driver" -
Migration directory — find it:
ls migrations/ db/migrations/ supabase/migrations/ alembic/versions/ 2>/dev/null find . -path ./node_modules -prune -o \( -name "*.sql" -o -name "*migration*" \) -print 2>/dev/null | head -20Note the convention: how migrations are named, whether they include UP + DOWN, whether they include access-policy blocks alongside DDL.
-
Schema files — find canonical schema sources:
ls schema.sql schema.prisma drizzle/schema.* 2>/dev/null find . -name "*.types.ts" -path "*db*" -o -name "database.types.ts" 2>/dev/null | head -
Access-control signal — does the project use RLS / equivalent?
# Postgres RLS grep -rn "row level security\|enable rls\|create policy" migrations/ db/ supabase/ 2>/dev/null | head # Application-layer auth grep -rn "tenant_id\|workspace_id\|owner_id" --include="*.ts" lib/ src/ 2>/dev/null | head
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- yesterday First seen · 198 lines · 100 tokens per session scan A 95a808ed3a51
data is a skill published in the GitHub repository vindm/dotclaude (1 stars, last pushed 4d ago), licensed MIT. It adds 100 tokens to every session and 3,597 once invoked, about $0.0005 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 skills, from other repositories
skill-creator
Guide for creating effective skills. This skill should be used when users want to create a new skill (or update an existing skill) that extends Claude's capabilities with specialized knowledge, workflows, or tool integrations.
deepinit
Deep codebase initialization with hierarchical AGENTS.md documentation.
agent-management
Create, manage, and orchestrate AI agents using the AI Maestro CLI. Use when the user asks to "create agent", "list agents", "delete agent", "hibernate agent", "wake agent", "install plugin", "show agent", "restart agent", or any agent lifecycle management task.
claude-md-review
Audit a CLAUDE.md file for the patterns that actually degrade Claude Code's output — vagueness, unnamed files, stale facts, and bloat. Use when asked to review, audit, improve, shrink, or fix a CLAUDE.md, and when a project's results feel inconsistent or Claude keeps rediscovering the same context.
Skill Development
This skill should be used when the user wants to "create a skill", "add a skill to plugin", "write a new skill", "improve skill description", "organize skill content", or needs guidance on skill structure, progressive disclosure, or skill development best practices for Claude Code plugins.
Plugin Structure
This skill should be used when the user asks to "create a plugin", "scaffold a plugin", "understand plugin structure", "organize plugin components", "set up plugin.json", "use ${CLAUDEPLUGINROOT}", "add commands/agents/skills/hooks", "configure auto-discovery", or needs guidance on plugin directory layout, manifest…