Our review

Validates Unity ECS components, buffer elements, or tags for compliance with project conventions including naming, struct purity, minimal fields, and duplication avoidance.

Strengths

Ensures consistent naming and structure across ECS component codebase.
Automatically detects duplication with existing components to prevent data overlap.
Checks for common pitfalls like mixing business logic into data containers.
Provides clear pass/fail/warn results and actionable recommendations.

Limitations

Only works with Unity ECS components and not general C# classes.
Relies on file glob patterns that assume a specific project structure.
Cannot verify runtime correctness or performance implications.

When to use it

Use after creating or modifying any ECS component to ensure it adheres to team conventions before committing.

When not to use it

Do not use for non-ECS code, or when you are intentionally deviating from conventions for a specific reason.

name: validate-component description: > Validate an ECS component, buffer element, or tag follows project conventions including naming, struct purity, minimal fields, and no duplication with existing components. AUTO-INVOKE when: (1) a new or modified component file was just written, (2) after /new-ecs-component as a mandatory post-creation check, (3) the user asks "is this component correct?", "does this component follow conventions?", (4) reviewing a PR/diff that includes component changes. Also invoke when you're about to add fields to an existing component — check duplication first. disable-model-invocation: false allowed-tools: Read, Grep, Glob

Validate Component — ECS Component Compliance Review

Usage

/validate-component <ComponentName or file path>

If no argument is given, validate all new/modified component files in the current git diff.

Validation checklist

1. Naming Convention

Verify correct naming based on interface:

| Interface | Naming Pattern | File Pattern | Example | |-----------|---------------|--------------|---------| | IComponentData | {Name}Component or descriptive name | {Name}.Component.cs | SquadMovement.Component.cs | | IBufferElementData | {Name}Element | {Name}Element.cs | InactiveSquadElement.cs | | IEnableableComponent | {Name}Tag or {Name}Component | varies | SquadSwapExecuteTag.cs | | Tag (empty struct) | {Name}Tag | {Name}Tag.cs | IsMovingTag.cs |

2. Struct Purity

Verify:

Component is a struct, not a class
No methods with side effects (pure data only)
No references to MonoBehaviours, GameObjects, or managed types (unless using ICleanupComponentData)
No business logic — components are data containers only

3. No Duplication

Search existing components for overlapping data:

Glob: Assets/Scripts/**/*Component*.cs
Glob: Assets/Scripts/**/*Element*.cs
Glob: Assets/Scripts/**/*Tag*.cs

Check if any existing component already stores the same fields or serves the same purpose. Report overlaps.

4. Minimal Fields

Verify the component:

Has only fields necessary for its purpose
Doesn't combine unrelated data (should be split into separate components)
Uses appropriate types (Entity for references, float3 for positions, etc.)
Uses FixedString instead of string for text data

5. Authoring (if applicable)

If the component has a Baker/Authoring class:

Verify it follows the {Name}Authoring naming pattern
Verify the Baker only adds the component, doesn't contain logic

Output format

## Component Validation: {ComponentName}

**File:** {path}
**Type:** IComponentData / IBufferElementData / Tag / IEnableableComponent
**Fields:** {list of fields}

### Results
| Check | Status | Notes |
|-------|--------|-------|
| Naming | PASS/WARN/FAIL | ... |
| Struct Purity | PASS/WARN/FAIL | ... |
| No Duplication | PASS/WARN/FAIL | ... |
| Minimal Fields | PASS/WARN/FAIL | ... |
| Authoring | PASS/WARN/FAIL/N/A | ... |

### Duplicates Found
| Existing Component | File | Overlapping Fields |
|-------------------|------|--------------------|
| ... | ... | ... |

### Recommendations
- ...

Validate ECS Component

Recommended for