What problem does it solve?
Frontend work in the dotCMS core-web Nx workspace follows repository-specific Angular conventions that differ from generic upstream Angular guidance, and applying stock Angular CLI advice (ng commands, standalone flags, Karma, @ngneat/spectator) produces code that violates project standards.
Core Features & Use Cases
- Repository-Specific Rules: Enforces Nx/pnpm workflows, Jest 30 with @openng/spectator, three-file component structure, and Material Symbols icons instead of generic Angular defaults.
- Precedence Over Upstream Guidance: Overrides the vendored angular-developer skill wherever generic Angular advice conflicts with dotCMS conventions.
- Review Checklist: Provides a pre-completion checklist covering change detection, component states (loading/empty/error/loaded), subscription teardown, and test verification.
- Use Case: When writing or reviewing a new component in core-web, the skill ensures you scaffold with Nx generators, use signal-based naming conventions ($ prefix for signals, $ suffix for observables), and test with spectator.setInput() and byTestId selectors.
Quick Start
Ask the assistant to create a new Angular component in core-web following the dotCMS standards and verify it with pnpm nx test and lint.