aurora-schema_skill

Overview

This skill analyzes and edits Aurora YAML schema files (*.aurora.yaml) to ensure structural correctness and domain-driven design semantics. It validates module descriptions, mandatory audit fields, field naming, relationships, and type usage. Use it to improve schema clarity, consistency, and downstream code generation quality.

How this skill works

The skill parses Aurora YAML modules and runs a checklist: it ensures a module description appears before aggregateProperties, verifies mandatory fields (rowId, createdAt, updatedAt, deletedAt) and required ordering, and checks every field has a WHY-focused description. It flags id fields with invalid properties (like length), duplicate relationship definitions, inconsistent cross-module names, enum documentation gaps, and index name length issues.

When to use it

• When creating or reviewing any *.aurora.yaml schema files
• When adding, renaming, or removing fields in a module
• When validating relationships or foreign key semantics across modules
• When enforcing DDD-style module descriptions and field ordering
• Before running aurora CLI generation or committing schema changes

Best practices

• Always include a module description before aggregateProperties describing contents, purpose, and relations
• Keep mandatory fields and order: id → rowId → ... → createdAt → updatedAt → deletedAt
• Write every field description to explain WHY the field exists and how it is used, not just what it is
• Use camelCase for field names and boolean prefixes (is*, has*, can*); use *At for timestamps and *Id for foreign keys
• Never add length to fields of type id; avoid duplicating FK and relationship fields in the same module
• Use indexName to shorten PostgreSQL index names to under 63 characters

Example use cases

• Detect missing module description and inject a suggested description template before aggregateProperties
• Find id fields that wrongly include a length property and produce a safe edit removing length
• Analyze field descriptions and suggest WHY-focused rewrites for weak or missing descriptions
• Validate relationship definitions across modules and flag duplicate FK/navigation properties
• Check index names and suggest abbreviated indexName values to meet PostgreSQL limits