Field meaning is handled by this skill in a customer-readable, reusable workflow.
Relationships is handled by this skill in a customer-readable, reusable workflow.
SB_database_governor@SB_database_governorSafe Vibe CodingIncluded in bundle10 minutes
What is this?
A database looks simple until screens become records, statuses, permissions, uploaded files, reports, payments, and recovery needs. Database Governor stops the agent from copying screen labels into tables too early. It uses workflow, requirements, and architecture evidence to define the storage model, table and field dictionary, relationships, indexes, migration path, lifecycle states, and data-safety checks before schema mistakes spread into the product.
When this helps
What you get
- Data model review
- Field definitions
- Migration notes
- Implementation handoff
Use it when
- The product starts storing real data such as customers, orders, access rights, files, statuses, history, or reports.
- Fields and tables were created quickly, but you are not sure they match how the business actually works.
- You need the database treated as a product contract before reporting, billing, permissions, or migration becomes painful.
Not the right fit when
- It does not replace a database administrator for high-scale systems. It governs product-level data decisions early.
What this prepares next
Clearer schema -> Less data rework -> Better reporting foundation
Why this is stronger than asking AI once
A quick schema prompt can create tables that look reasonable but miss workflow meaning, field ownership, reporting needs, migration risk, and data safety. Database Governor is stronger because it ties tables, fields, relationships, migrations, and retention decisions back to the product workflow and requirements. The buyer gets a data model that is easier to review before bad storage decisions become expensive. Boundary: It does not replace a database administrator for high-scale systems; it governs product-level data decisions early.
Included interface patterns
Database Intake
Questions workflow, SRS, architecture, scale, query, update/delete, distribution, security, and budget before model selection.
Data demand profile with facts, assumptions, unknowns, and risk level.Table And Field Dictionary
Turns business objects into stable tables, fields, relationships, statuses, indexes, and audit rules.
SRS-linked table and field dictionary.SRS Database Appendix
Preserves DB-ENT, DB-FLD, DB-REL, DB-IDX, DB-MIG, and DB-SAFE entries for future agents.
Database appendix handoff for @SB_srs_governor.Migration And Data Safety
Plans versioned idempotent migrations, backup, recovery, reconciliation, and post-migration checks.
Schema migration and data-safety plan.