From sentinel
Use when designing components, systems, or entity structures for jecs in Roblox. Use when deciding if data should be one component or multiple, when archetype transitions seem expensive, or when choosing entity members vs relationships.
npx claudepluginhub christopher-buss/skills --plugin sentinelThis skill uses the workspace's default tool permissions.
Design guidance for jecs in Roblox.
Creates isolated Git worktrees for feature branches with prioritized directory selection, gitignore safety checks, auto project setup for Node/Python/Rust/Go, and baseline verification.
Executes implementation plans in current session by dispatching fresh subagents per independent task, with two-stage reviews: spec compliance then code quality.
Dispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.
Design guidance for jecs in Roblox.
Think of ECS as a columnar database:
| Database | ECS |
|---|---|
| Table | Archetype (unique component combination) |
| Column | Component type |
| Row | Entity |
| Query | System iteration |
Design question: "Would I create a separate database column for this?"
| Topic | Description | Reference |
|---|---|---|
| Database Model | ECS as columnar database, normalization, fragmentation | core-database-model |
| Query Design | Multi-entity queries, constraint decomposition, traversal | core-query-design |
| Topic | Description | Reference |
|---|---|---|
| Component Design | Granularity decisions, when to split/combine, tags vs data | best-practices-components |
| System Design | Single responsibility, avoiding work, ordering, data flow | best-practices-systems |
| Entity Design | When to create entities, lazy creation, scaling patterns | best-practices-entities |
| Question | Answer |
|---|---|
| Should this be an entity? | Only if it needs per-instance state that changes over time |
| Split or combine? | "Is there a system that needs A but not B?" |
| Tag or data component? | Tags for stable classification (free to add/remove), data for state |
| Relationship or entity ref? | Relationship if reverse lookup needed, entity member otherwise |
| Is fragmentation bad? | Only if thousands of archetypes AND you query broadly |
| When does DOD matter? | Thousands of entities, per-frame, CPU-bound |
| Mistake | Why it's bad | Fix |
|---|---|---|
| Monolithic components | Cache waste, tight coupling | Split by access pattern |
| Over-atomic components | Query complexity, invalid states | Combine semantic units |
| Frequent add/remove on large entities | Copies all component data | Mutate data component instead |
| Relationships for every link | Fragmentation without benefit | Use entity members for forward-only |
| Cached query inside system | Creates new cache every frame | Create cached queries at module scope |
.cached() inside a system