ent-schema-generator
Ent Schema Generator
Overview
Transform requirement inputs into implementation-ready database schema plans for sphere-layout Go projects using Ent ORM. This skill focuses on decisions directly actionable in Ent schema code and downstream integration layers.
This skill is repository-specific — always prefer local scaffold conventions over generic patterns unless explicitly requested.
When to Use
Use this skill when the user mentions:
- Database schema, Ent schema, entity design, or table structure
- Adding new data models, fields, or relationships
- Database migration, schema evolution, or index planning
- Proto bindings, entpb generation, or bind/render integration
- Any prompt describing business data requirements that need database persistence
Required Reading
Always read these files in order before generating schema plans:
- references/best-practices.md — Decision rules for schema design
- references/output-template.md — Required output format
Reference these when needed:
- references/ent-schema-examples.md — Code patterns with entproto annotations
- references/go-ent-service-patterns.md — DAO/service patterns
Workflow
Follow this sequence for each schema task:
Phase 1: Analysis
- Gather evidence from prompt/docs/proto/schema/service/dao/render
- Extract candidate entities and lifecycle states
- Identify key business requirements and constraints
Phase 2: Design Decisions
- Design field-level policies (Optional/Nillable/Unique/Immutable/Default)
- Decide ID strategy — generator-managed by default
- Decide relation strategy: relation-entity > array > join table > JSON fallback
- Build query-driven index plan from list/filter/sort paths
- Plan Go implementation (weak relation IDs, batch IDIn, chunking)
Phase 3: EntProto Compliance (REQUIRED)
- Add entproto annotations to ALL schemas:
- Schema:
entproto.Message()inAnnotations()method - Fields:
entproto.Field(n)with sequential numbers (ID=1) - Enums:
entproto.Field(n)+entproto.Enum(map[string]int32{...})with values starting from 1
- Schema:
- Verify enum values always start from 1 (0 is reserved)
Phase 4: Integration
- Map to bind registration, WithIgnoreFields, render/dao/service
- Document post-change commands and validation steps
Phase 5: Output
- Produce final brief using references/output-template.md
Critical Requirements
EntProto Annotation Rules
ALL schemas MUST include entproto annotations — this is not optional:
| Component | Required Annotation |
|---|---|
| Schema | entproto.Message() in Annotations() |
| Primary Key Field | entproto.Field(1) |
| Regular Fields | entproto.Field(n) (sequential) |
| Enum Fields | entproto.Field(n) + entproto.Enum(map[string]int32{...}) |
| Enum Values | Must start from 1 (0 reserved) |
Import: "entgo.io/contrib/entproto"
Integration Completeness
Task is incomplete without addressing:
- Bind registration — New entities must be added to
cmd/tools/bind/main.go#createFilesConf - WithIgnoreFields — Review for timestamps and sensitive fields
- Post-generation commands — Always include:
make gen/proto go test ./... - Generation diff checklist — Verify entpb/proto/bind/map changes are consumed
Output Requirements
Use references/output-template.md as the exact output format:
- Keep all 11 sections in order
- Mark assumptions explicitly as "Assumption:"
- Add "Blocking Notes:" under any section with incomplete validation
Common Pitfalls
- Don't stop at schema-only output when integration is affected
- Don't skip
WithIgnoreFieldsreview for sensitive fields - Don't use Optional/Nillable for entproto — prefer zero-value defaults
- Don't start enum values from 0
- Don't forget to register new entities in bind config
More from go-sphere/skills
proto-service-generator
Generate or complete Go service implementations from protobuf-generated HTTP interfaces in go-sphere scaffold projects. Use when you need to create `internal/service/<module>/*.go` files, add missing method implementations to existing services, or generate compilable stubs for new proto endpoints. Trigger for: service implementation, proto handler, append-only update, interface assertion, CRUD via Ent, stub method generation.
18project-intake
Organize scattered project inputs and generate standardized intake documents. Use when users mention project kickoff, requirement initialization, PRD preparation, input organization, requirement gathering, or turning prototypes/demos/drafts into structured documents. Apply to new feature development, project initialization, requirement clarification, and similar scenarios. Always complete intake before writing PRD or any detailed design.
6prd
Generate high-quality Product Requirements Documents (PRDs) following go-sphere development workflow. Use when: user wants to create a PRD, document requirements, plan a feature, or translate business ideas into product specs. Required for the PRD solidification phase in AI Agent collaboration development.
5spec-diff-pipeline
Analyze a changed SPEC or other technical specification from git diff or two version files (v0, v1) and automatically produce downstream planning artifacts such as spec delta, impact map, API/proto delta, schema delta, surface-specific impact reports, task plan, and open questions. Use whenever the user has modified SPEC.md or another design/spec file and wants an AI-run pipeline that reads the diff (either from git or by comparing two version files), traces downstream impact, and prepares implementation-planning markdown outputs for whatever affected surfaces exist in the repo, even if they only say things like 根据 spec diff 分析影响, 刷新 proto/schema 规划, 生成 impact map, 拆 implementation tasks, 分析哪些端受影响, or 对比 v0 v1 版本差异.
4proto-service-skeleton
Generate or complete `internal/service/<module>/*.go` service implementation skeletons from generated `api/<module>/v1/*.sphere.pb.go` HTTP interfaces in this repository. Use when proto and generated API files already exist and you need per-service files, interface assertion checks, safe append-only updates, simple CRUD direct Ent implementation, and fallback stub methods for unknown business logic.
1