angular-spa

Angular/Nx SPA Skill

Required workflow

1. Read AGENTS.md, applicable scoped AGENTS.md files, and this skill before editing.
2. Inspect package.json, project.json, nx.json, and relevant compiler/lint configuration to establish installed Angular/Nx versions, project type, available targets, and constraints. Do not apply a newer Angular convention merely because it exists.
3. Identify task type and read the supporting standards below that apply. Read all applicable files before implementation, not after it.
4. Inspect nearby implementation, tests, registrations, and equivalent patterns. Preserve observable behavior unless explicitly changing it.
5. Capture git status --short; never overwrite unrelated dirty work.
6. Identify focused and broader validation before modifying files.
7. Implement the smallest coherent change, then treat it as a draft: execute the self-review, correct issues, and rerun validation.

Current repository constraints

• Angular and Nx versions must be read from package.json for every task. This skill was calibrated against Angular 21.2 and Nx 22.7, but it is not a license to migrate.
• Preserve the current NgModule bootstrap, module routing, and NGXS architecture unless explicitly authorized otherwise.
• This is currently one type:app Nx project, not a library workspace. The Nx taxonomy below is a guardrail for future authorized restructuring, not permission to create libraries or tags.
• Use Jasmine, Karma, Angular TestBed, strict TypeScript, strict templates, Angular Material/CDK, RxJS, NGXS, dynamic-mapper, Sentry, and OpenTelemetry consistently with nearby code.

Read the applicable supporting standards

• Always: architecture, TypeScript, and review and validation.
• Components, directives, pipes, templates, forms, or styles: components and templates.
• NGXS, signals, RxJS, APIs, providers, mappings, or errors: state, RxJS, and data access.
• Tests or changed behavior: testing.
• User input, DOM, auth/permissions, telemetry, charts, performance, or user-facing UI: security, accessibility, and performance.

Non-negotiable decisions

• Order decisions by correctness, security, data integrity, behavior preservation, simplicity, readability, maintainability, testability, accessibility, then measured performance.
• Apply KISS, YAGNI, DRY, SOLID, high cohesion, low coupling, composition over inheritance, and the Law of Demeter pragmatically. Introduce an abstraction only for an observed present problem.
• Keep clear ownership. Do not use shared as a dumping ground, deep-import another library’s internals, introduce a competing state library, inject HttpClient into a component, or bypass established mapping/error/telemetry boundaries.
• Keep the scope narrow. Do not perform standalone, zoneless, signals, state-library, or folder migrations without explicit authorization.
• Never hide a problem with any, @ts-ignore, @ts-expect-error, a broad lint disable, --force, --legacy-peer-deps, test deletion/skipping, weakened strict settings, commented-out old code, or a placeholder.
• Quantitative limits are design signals, not targets to game. Record a narrow exception with exact path, threshold, reason, why decomposition is worse, and removal/review condition.

Task-type rules

Use the pre-change checklist and self-review checklist. Use prompt templates as task starters, never as authority over this skill.