Phase 2 / Ep 09: Automating Data Model Schema Design

Now that we've decided on Prisma + PostgreSQL in the previous step, the remaining grunt work—writing the User, TimeBlockTask, CalendarEvent models and their relations into schema.prisma—shouldn't be done manually by a human.

But before we let the Agent handle this risky task, we must establish a workflow, or a pipeline, to prevent it from crashing the database.

1. Establish the Business Workflow: database-migration.md

In our magic directory, .agents/workflows/, create a new file named database-migration.md:

---
description: Standardized process for database schema changes and synchronization
---
When you receive instructions to modify or create database entities, please execute the following steps:
// turbo-all

1. Consult `docs/PRD_System_Design.md` and `docs/findings.md` to ensure field names align with the business context (do not create arbitrary abbreviations).
2. Add or modify the corresponding Model definitions in `prisma/schema.prisma` (create the file if it doesn't exist). All table names must be mapped using lowerCamelCase.
3. For any table related to a third-party service (especially Google Calendar events), you must reserve `providerId` and `providerSyncToken` fields to handle upstream bidirectional cursor issues!
4. After modifying the file, run `npx prisma format` and `npx prisma validate` to confirm there are no errors.

2. Generating Entities Under Automated Command

With the above guardrails in place, you now only need to give a very simple command:

"Run the Database Migration workflow to create the necessary local business tables for our T-Block."

The Agent will automatically begin its work:

1. It triggers Using-Superpowers, detects the specific workflow, and is forced to read it.
2. It extracts information from the previous PRD and discovers that the user needs draggable time blocks (requiring an order field) and calendar integration (requiring a googleEventId field).
3. It modifies schema.prisma and adds detailed comments for you.
4. It runs the validation commands in its underlying terminal, finds no errors, and then reports back to you: "Design complete."

You see, it even proactively predicted and prevented potential database relation errors. This is because we've embedded our accumulated engineering experience into the workflow as a layer of armor. Every execution effortlessly builds upon the shoulders of best practices