{"owner":"Ismaestro","repo":"angular-example-app","hasSkills":true,"totalSkillsCount":1,"totalTokensCount":2152,"categories":["anthropic-skill"],"hasMcp":false,"mcpConfig":null,"found":[".aiassistant/rules/Global.md"],"skills":{".aiassistant/rules/Global.md":"---\napply: always\n---\n\n# Global Rules\n\n## Code Style & Architecture Rules\n\n### TypeScript\n\n- Avoid `any`.\n- Explicitly type **parameters** and relevant data structures.\n- Return types are NOT required, but add them when they improve clarity.\n- **Dependency Injection:** Use the `inject()` function exclusively. Constructor-based injection is forbidden.\n- **Modern Angular Patterns:**\n  - Use **Signals** for local and shared state management.\n  - Use `linkedSignal` for derived state when necessary.\n  - **Effects** (`effect`) must be declared as class properties (`readonly myEffect = effect(...)`) to ensure proper lifecycle management. Avoid calling `effect()` inside constructors.\n  - Mandatory use of `ChangeDetectionStrategy.OnPush` in all components.\n  - Follow **Zoneless** principles; avoid `NgZone` and rely on Signals for change detection.\n\n### General Code Quality\n\n- **Single Responsibility:** Each file, class, and function should do one thing and do it well.\n- **DRY (Don't Repeat Yourself):** Extract repeated code into shared utilities, services, or helper functions.\n- **Error handling:** Always handle errors in async operations (HTTP calls, promises). Never swallow errors silently — at minimum, log them.\n- **Naming conventions:** Use descriptive names without ambiguous abbreviations (avoid `req`, `res`, `err`). Verbs for functions (`getUser`, `handleClick`), nouns for variables (`userList`, `isVisible`).\n- **File Naming & Structure:**\n  - Types: `*.types.ts`\n  - Enums: `*.enums.ts`\n  - Constantes: `*.constants.ts`\n  - Fixtures de test: `*.fixtures.ts`\n  - Desacoplamiento: Extraer definiciones de interfaces y constantes de los archivos de servicios y componentes hacia sus archivos específicos.\n- **Immutability:** Prefer `const` over `let`. Avoid mutating state directly — use spread, `map`, `filter` instead of `push`, `splice`, or direct property assignment.\n- **Early returns:** Use guard clauses to reduce nesting and improve readability.\n- **Pure functions:** Prefer functions without side effects when possible. Isolate side effects at the edges (services, lifecycle hooks).\n- **Avoid magic strings/numbers:** Extract literal values into named constants with descriptive names. Improves maintainability and searchability.\n- **Fail fast:** Validate inputs at the beginning of functions. Do not let invalid data propagate deep into the execution flow.\n- **Small, atomic commits:** Each commit should be self-contained and represent a single responsibility or logical change.\n- **No complex logic in templates:** Move complex expressions (multiple operators, calculations, chained conditions) out of HTML templates into computed signals or component methods.\n- **Consistent return types:** A function should not return `null` sometimes, `undefined` other times, and the actual value in other cases. Be consistent with absence representation.\n- **Avoid nested subscriptions/callbacks:** Use RxJS composition operators (`switchMap`, `mergeMap`, `concatMap`) instead of nested `subscribe()` calls. Same applies to nested `.then()` chains — prefer `async/await`.\n- **Limit side effect scope:** If a function has side effects, they should only affect what is strictly necessary. Do not use a function to silently modify unrelated state.\n- **Prefer composition over inheritance:** Use composition (service injection, utility functions) over deep inheritance chains. Favor small, focused, reusable pieces.\n- **Keep conditionals positive:** Prefer positive conditions (`if (isVisible)`) over double negations or inverted logic (`if (!isNotHidden)`). Improves readability.\n- **One abstraction level per function:** Each function should operate at a single level of abstraction. Do not mix high-level orchestration with low-level details (parsing, formatting) in the same function.\n- **Avoid boolean parameters:** Functions with a `boolean` parameter often do two things. Prefer two descriptive named functions, or use a literal/enum type parameter.\n- **Explicit over implicit:** Prefer explicit, readable code over \"clever\" code. When choosing between brevity and clarity, choose clarity.\n- **Dependency direction:** Dependencies must flow inward: `features → shared → core`. Never the reverse. Core must not import from features or shared.\n- **Encapsulate conditionals:** Extract complex conditions into descriptive named variables or functions (`const isEligible = age >= 18 && hasConsent`) instead of inlining them in `if` statements.\n- **Prefer typed objects over long parameter lists:** When passing complex data to a function, use a typed object parameter instead of multiple positional parameters.\n- **Observables: always unsubscribe:** Every manual Observable subscription in components must be cleaned up in `ngOnDestroy` or via `takeUntilDestroyed()` / `DestroyRef`. Prefer `toSignal()` or the `async` pipe to avoid manual subscriptions altogether.\n- **Defensive data access:** Use optional chaining (`?.`) and nullish coalescing (`??`) when accessing properties that may not exist. Never assume API data is always complete.\n- No empty functions. If a function must exist without implementation, add: `// Empty`\n\n### Components\n\n- Components must contain **only the logic strictly necessary for the view**.\n- Keep components: simple, predictable, and easy to test.\n- Extract cross-cutting logic into **independent services** (scroll, state management, complex calculations, date formatting, etc.).\n- **`protected` for template-only members:** Use `protected` on class members that are only accessed from the component's template. Public members define a public API accessible via DI and queries — do not expose template-only members as public.\n- **`readonly` for Angular-initialized properties:** Mark `input()`, `output()`, `model()`, `viewChild()`, `viewChildren()`, `contentChild()`, and `contentChildren()` as `readonly`.\n- **Group Angular properties first:** In components/directives, group Angular-specific properties (injected dependencies, inputs, outputs, queries) at the top of the class, before any methods.\n- **Event handler naming:** Name event handlers for the action they perform (`saveUserData()`), not for the triggering event (`handleClick()`, `onSubmit()`).\n\n### HTML & Accessibility\n\n- Use **semantically correct** HTML.\n- Respect accessibility: proper use of tags, correct heading hierarchy, accessible attributes when needed.\n- Animations, transitions, and auto-scroll must respect `prefers-reduced-motion`.\n- **Prefer `[class]`/`[style]` bindings over `ngClass`/`ngStyle`:** Built-in class and style bindings are more performant and align with standard HTML. Avoid `NgClass` and `NgStyle` directives.\n\n### SCSS / Styling\n\n- Use **SASS (SCSS)** — no plain CSS if SASS can solve it.\n- Use **BEM** naming methodology.\n- **Mobile first:** default styles are mobile; use breakpoint mixins for desktop adaptations.\n- Never hardcode colors, typography, spacing, or z-index if a design system variable exists.\n- Transitions/animations must respect `prefers-reduced-motion` and provide a no-motion alternative.\n- Keep styles: readable, predictable, grouped by BEM block.\n- Avoid deep selectors or selectors dependent on HTML structure.\n\n## Unit Test Guidelines\n\n- **Behavior over implementation:** Tests should primarily verify observable behavior (DOM changes, emitted values, CSS classes, visible state). Implementation assertions (e.g., `expect(service.method).toHaveBeenCalledWith(...)`) are acceptable when they add real value, but the default approach should always be behavior-first.\n- **Coverage Thresholds:** Mandatory minimum coverage:\n  - Statements: 97%\n  - Branches: 93%\n  - Functions: 96%\n  - Lines: 97%\n- **Branch coverage:** All branches of the file or new functionality under test must be covered (if/else, switch cases, early returns, error paths, edge cases).\n- **Mock external dependencies:** Components and services that are NOT the subject of the test must be mocked/stubbed. Only test the unit in isolation.\n- **Environment & Mocks:**\n  - Use **Vitest** as the test runner.\n  - Implement global mocks for `ResizeObserver` and `IntersectionObserver` when needed.\n  - Tests must fail on unexpected `console.error` or `console.warn` (using spies in setup).\n- **Cleanup:** Reset mocks, spies, and any shared state before and after each test (`beforeEach`/`afterEach`) to ensure test isolation and prevent side effects between tests.\n\n## Infrastructure & Quality\n\n- **ESLint:** Strict adherence to rules. No `any`, no forbidden abbreviations, and strict void return types. Do not disable rules; fix the code.\n- **Husky Hooks:**\n  - `commit-msg`: Validates conventional commits.\n  - `pre-commit`: Runs `lint-staged` (ESLint, Prettier, Stylelint).\n  - `pre-push`: Runs full lint and tests with coverage.\n- **Path Aliases:** Use `~core/*`, `~shared/*`, and `~features/*` for imports.\n\n## Communication\n\n- Always respond in **Spanish** (español).\n- Be cordial and give encouragement when it makes sense, naturally and not forced.\n\n## Analytics\n\n- When working on a new feature, proactively suggest which analytics events should be added (page views, CTA clicks, user interactions, conversions, relevant errors, scroll depth, time on page, etc.).\n- When creating analytics events, do NOT include `page_url` or the logged-in user ID in the payload — the analytics library injects those automatically.\n\n## Commits\n\n- Use **Conventional Commits** format: `type(scope): subject`\n- Subject always lower-case, no trailing period.\n- Body and footer must be empty.\n- Check the project's commitlint config for allowed types and scopes.\n\n## Testing\n\n- Run tests with `npm test` (no additional flags).\n\n## Project Documentation\n\n- After each modification, evaluate if the change affects the project's `AGENTS.md` file. If so, suggest or apply the corresponding update. Examples: new features, new services/components/directives/pipes, dependency version changes, folder structure changes, new routes, ESLint/commitlint config changes, npm script changes, etc.\n"},"files":{".aiassistant/rules/Global.md":"---\napply: always\n---\n\n# Global Rules\n\n## Code Style & Architecture Rules\n\n### TypeScript\n\n- Avoid `any`.\n- Explicitly type **parameters** and relevant data structures.\n- Return types are NOT required, but add them when they improve clarity.\n- **Dependency Injection:** Use the `inject()` function exclusively. Constructor-based injection is forbidden.\n- **Modern Angular Patterns:**\n  - Use **Signals** for local and shared state management.\n  - Use `linkedSignal` for derived state when necessary.\n  - **Effects** (`effect`) must be declared as class properties (`readonly myEffect = effect(...)`) to ensure proper lifecycle management. Avoid calling `effect()` inside constructors.\n  - Mandatory use of `ChangeDetectionStrategy.OnPush` in all components.\n  - Follow **Zoneless** principles; avoid `NgZone` and rely on Signals for change detection.\n\n### General Code Quality\n\n- **Single Responsibility:** Each file, class, and function should do one thing and do it well.\n- **DRY (Don't Repeat Yourself):** Extract repeated code into shared utilities, services, or helper functions.\n- **Error handling:** Always handle errors in async operations (HTTP calls, promises). Never swallow errors silently — at minimum, log them.\n- **Naming conventions:** Use descriptive names without ambiguous abbreviations (avoid `req`, `res`, `err`). Verbs for functions (`getUser`, `handleClick`), nouns for variables (`userList`, `isVisible`).\n- **File Naming & Structure:**\n  - Types: `*.types.ts`\n  - Enums: `*.enums.ts`\n  - Constantes: `*.constants.ts`\n  - Fixtures de test: `*.fixtures.ts`\n  - Desacoplamiento: Extraer definiciones de interfaces y constantes de los archivos de servicios y componentes hacia sus archivos específicos.\n- **Immutability:** Prefer `const` over `let`. Avoid mutating state directly — use spread, `map`, `filter` instead of `push`, `splice`, or direct property assignment.\n- **Early returns:** Use guard clauses to reduce nesting and improve readability.\n- **Pure functions:** Prefer functions without side effects when possible. Isolate side effects at the edges (services, lifecycle hooks).\n- **Avoid magic strings/numbers:** Extract literal values into named constants with descriptive names. Improves maintainability and searchability.\n- **Fail fast:** Validate inputs at the beginning of functions. Do not let invalid data propagate deep into the execution flow.\n- **Small, atomic commits:** Each commit should be self-contained and represent a single responsibility or logical change.\n- **No complex logic in templates:** Move complex expressions (multiple operators, calculations, chained conditions) out of HTML templates into computed signals or component methods.\n- **Consistent return types:** A function should not return `null` sometimes, `undefined` other times, and the actual value in other cases. Be consistent with absence representation.\n- **Avoid nested subscriptions/callbacks:** Use RxJS composition operators (`switchMap`, `mergeMap`, `concatMap`) instead of nested `subscribe()` calls. Same applies to nested `.then()` chains — prefer `async/await`.\n- **Limit side effect scope:** If a function has side effects, they should only affect what is strictly necessary. Do not use a function to silently modify unrelated state.\n- **Prefer composition over inheritance:** Use composition (service injection, utility functions) over deep inheritance chains. Favor small, focused, reusable pieces.\n- **Keep conditionals positive:** Prefer positive conditions (`if (isVisible)`) over double negations or inverted logic (`if (!isNotHidden)`). Improves readability.\n- **One abstraction level per function:** Each function should operate at a single level of abstraction. Do not mix high-level orchestration with low-level details (parsing, formatting) in the same function.\n- **Avoid boolean parameters:** Functions with a `boolean` parameter often do two things. Prefer two descriptive named functions, or use a literal/enum type parameter.\n- **Explicit over implicit:** Prefer explicit, readable code over \"clever\" code. When choosing between brevity and clarity, choose clarity.\n- **Dependency direction:** Dependencies must flow inward: `features → shared → core`. Never the reverse. Core must not import from features or shared.\n- **Encapsulate conditionals:** Extract complex conditions into descriptive named variables or functions (`const isEligible = age >= 18 && hasConsent`) instead of inlining them in `if` statements.\n- **Prefer typed objects over long parameter lists:** When passing complex data to a function, use a typed object parameter instead of multiple positional parameters.\n- **Observables: always unsubscribe:** Every manual Observable subscription in components must be cleaned up in `ngOnDestroy` or via `takeUntilDestroyed()` / `DestroyRef`. Prefer `toSignal()` or the `async` pipe to avoid manual subscriptions altogether.\n- **Defensive data access:** Use optional chaining (`?.`) and nullish coalescing (`??`) when accessing properties that may not exist. Never assume API data is always complete.\n- No empty functions. If a function must exist without implementation, add: `// Empty`\n\n### Components\n\n- Components must contain **only the logic strictly necessary for the view**.\n- Keep components: simple, predictable, and easy to test.\n- Extract cross-cutting logic into **independent services** (scroll, state management, complex calculations, date formatting, etc.).\n- **`protected` for template-only members:** Use `protected` on class members that are only accessed from the component's template. Public members define a public API accessible via DI and queries — do not expose template-only members as public.\n- **`readonly` for Angular-initialized properties:** Mark `input()`, `output()`, `model()`, `viewChild()`, `viewChildren()`, `contentChild()`, and `contentChildren()` as `readonly`.\n- **Group Angular properties first:** In components/directives, group Angular-specific properties (injected dependencies, inputs, outputs, queries) at the top of the class, before any methods.\n- **Event handler naming:** Name event handlers for the action they perform (`saveUserData()`), not for the triggering event (`handleClick()`, `onSubmit()`).\n\n### HTML & Accessibility\n\n- Use **semantically correct** HTML.\n- Respect accessibility: proper use of tags, correct heading hierarchy, accessible attributes when needed.\n- Animations, transitions, and auto-scroll must respect `prefers-reduced-motion`.\n- **Prefer `[class]`/`[style]` bindings over `ngClass`/`ngStyle`:** Built-in class and style bindings are more performant and align with standard HTML. Avoid `NgClass` and `NgStyle` directives.\n\n### SCSS / Styling\n\n- Use **SASS (SCSS)** — no plain CSS if SASS can solve it.\n- Use **BEM** naming methodology.\n- **Mobile first:** default styles are mobile; use breakpoint mixins for desktop adaptations.\n- Never hardcode colors, typography, spacing, or z-index if a design system variable exists.\n- Transitions/animations must respect `prefers-reduced-motion` and provide a no-motion alternative.\n- Keep styles: readable, predictable, grouped by BEM block.\n- Avoid deep selectors or selectors dependent on HTML structure.\n\n## Unit Test Guidelines\n\n- **Behavior over implementation:** Tests should primarily verify observable behavior (DOM changes, emitted values, CSS classes, visible state). Implementation assertions (e.g., `expect(service.method).toHaveBeenCalledWith(...)`) are acceptable when they add real value, but the default approach should always be behavior-first.\n- **Coverage Thresholds:** Mandatory minimum coverage:\n  - Statements: 97%\n  - Branches: 93%\n  - Functions: 96%\n  - Lines: 97%\n- **Branch coverage:** All branches of the file or new functionality under test must be covered (if/else, switch cases, early returns, error paths, edge cases).\n- **Mock external dependencies:** Components and services that are NOT the subject of the test must be mocked/stubbed. Only test the unit in isolation.\n- **Environment & Mocks:**\n  - Use **Vitest** as the test runner.\n  - Implement global mocks for `ResizeObserver` and `IntersectionObserver` when needed.\n  - Tests must fail on unexpected `console.error` or `console.warn` (using spies in setup).\n- **Cleanup:** Reset mocks, spies, and any shared state before and after each test (`beforeEach`/`afterEach`) to ensure test isolation and prevent side effects between tests.\n\n## Infrastructure & Quality\n\n- **ESLint:** Strict adherence to rules. No `any`, no forbidden abbreviations, and strict void return types. Do not disable rules; fix the code.\n- **Husky Hooks:**\n  - `commit-msg`: Validates conventional commits.\n  - `pre-commit`: Runs `lint-staged` (ESLint, Prettier, Stylelint).\n  - `pre-push`: Runs full lint and tests with coverage.\n- **Path Aliases:** Use `~core/*`, `~shared/*`, and `~features/*` for imports.\n\n## Communication\n\n- Always respond in **Spanish** (español).\n- Be cordial and give encouragement when it makes sense, naturally and not forced.\n\n## Analytics\n\n- When working on a new feature, proactively suggest which analytics events should be added (page views, CTA clicks, user interactions, conversions, relevant errors, scroll depth, time on page, etc.).\n- When creating analytics events, do NOT include `page_url` or the logged-in user ID in the payload — the analytics library injects those automatically.\n\n## Commits\n\n- Use **Conventional Commits** format: `type(scope): subject`\n- Subject always lower-case, no trailing period.\n- Body and footer must be empty.\n- Check the project's commitlint config for allowed types and scopes.\n\n## Testing\n\n- Run tests with `npm test` (no additional flags).\n\n## Project Documentation\n\n- After each modification, evaluate if the change affects the project's `AGENTS.md` file. If so, suggest or apply the corresponding update. Examples: new features, new services/components/directives/pipes, dependency version changes, folder structure changes, new routes, ESLint/commitlint config changes, npm script changes, etc.\n"},"items":[{"name":"Global.md","path":".aiassistant/rules/Global.md","rawUrl":"https://raw.githubusercontent.com/Ismaestro/angular-example-app/HEAD/.aiassistant/rules/Global.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"---\napply: always\n---\n\n# Global Rules\n\n## Code Style & Architecture Rules\n\n### TypeScript\n\n- Avoid `any`.\n- Explicitly type **parameters** and relevant data structures.\n- Return types are NOT required, but add them when they improve clarity.\n- **Dependency Injection:** Use the `inject()` function exclusively. Constructor-based injection is forbidden.\n- **Modern Angular Patterns:**\n  - Use **Signals** for local and shared state management.\n  - Use `linkedSignal` for derived state when necessary.\n  - **Effects** (`effect`) must be declared as class properties (`readonly myEffect = effect(...)`) to ensure proper lifecycle management. Avoid calling `effect()` inside constructors.\n  - Mandatory use of `ChangeDetectionStrategy.OnPush` in all components.\n  - Follow **Zoneless** principles; avoid `NgZone` and rely on Signals for change detection.\n\n### General Code Quality\n\n- **Single Responsibility:** Each file, class, and function should do one thing and do it well.\n- **DRY (Don't Repeat Yourself):** Extract repeated code into shared utilities, services, or helper functions.\n- **Error handling:** Always handle errors in async operations (HTTP calls, promises). Never swallow errors silently — at minimum, log them.\n- **Naming conventions:** Use descriptive names without ambiguous abbreviations (avoid `req`, `res`, `err`). Verbs for functions (`getUser`, `handleClick`), nouns for variables (`userList`, `isVisible`).\n- **File Naming & Structure:**\n  - Types: `*.types.ts`\n  - Enums: `*.enums.ts`\n  - Constantes: `*.constants.ts`\n  - Fixtures de test: `*.fixtures.ts`\n  - Desacoplamiento: Extraer definiciones de interfaces y constantes de los archivos de servicios y componentes hacia sus archivos específicos.\n- **Immutability:** Prefer `const` over `let`. Avoid mutating state directly — use spread, `map`, `filter` instead of `push`, `splice`, or direct property assignment.\n- **Early returns:** Use guard clauses to reduce nesting and improve readability.\n- **Pure functions:** Prefer functions without side effects when possible. Isolate side effects at the edges (services, lifecycle hooks).\n- **Avoid magic strings/numbers:** Extract literal values into named constants with descriptive names. Improves maintainability and searchability.\n- **Fail fast:** Validate inputs at the beginning of functions. Do not let invalid data propagate deep into the execution flow.\n- **Small, atomic commits:** Each commit should be self-contained and represent a single responsibility or logical change.\n- **No complex logic in templates:** Move complex expressions (multiple operators, calculations, chained conditions) out of HTML templates into computed signals or component methods.\n- **Consistent return types:** A function should not return `null` sometimes, `undefined` other times, and the actual value in other cases. Be consistent with absence representation.\n- **Avoid nested subscriptions/callbacks:** Use RxJS composition operators (`switchMap`, `mergeMap`, `concatMap`) instead of nested `subscribe()` calls. Same applies to nested `.then()` chains — prefer `async/await`.\n- **Limit side effect scope:** If a function has side effects, they should only affect what is strictly necessary. Do not use a function to silently modify unrelated state.\n- **Prefer composition over inheritance:** Use composition (service injection, utility functions) over deep inheritance chains. Favor small, focused, reusable pieces.\n- **Keep conditionals positive:** Prefer positive conditions (`if (isVisible)`) over double negations or inverted logic (`if (!isNotHidden)`). Improves readability.\n- **One abstraction level per function:** Each function should operate at a single level of abstraction. Do not mix high-level orchestration with low-level details (parsing, formatting) in the same function.\n- **Avoid boolean parameters:** Functions with a `boolean` parameter often do two things. Prefer two descriptive named functions, or use a literal/enum type parameter.\n- **Explicit over implicit:** Prefer explicit, readable code over \"clever\" code. When choosing between brevity and clarity, choose clarity.\n- **Dependency direction:** Dependencies must flow inward: `features → shared → core`. Never the reverse. Core must not import from features or shared.\n- **Encapsulate conditionals:** Extract complex conditions into descriptive named variables or functions (`const isEligible = age >= 18 && hasConsent`) instead of inlining them in `if` statements.\n- **Prefer typed objects over long parameter lists:** When passing complex data to a function, use a typed object parameter instead of multiple positional parameters.\n- **Observables: always unsubscribe:** Every manual Observable subscription in components must be cleaned up in `ngOnDestroy` or via `takeUntilDestroyed()` / `DestroyRef`. Prefer `toSignal()` or the `async` pipe to avoid manual subscriptions altogether.\n- **Defensive data access:** Use optional chaining (`?.`) and nullish coalescing (`??`) when accessing properties that may not exist. Never assume API data is always complete.\n- No empty functions. If a function must exist without implementation, add: `// Empty`\n\n### Components\n\n- Components must contain **only the logic strictly necessary for the view**.\n- Keep components: simple, predictable, and easy to test.\n- Extract cross-cutting logic into **independent services** (scroll, state management, complex calculations, date formatting, etc.).\n- **`protected` for template-only members:** Use `protected` on class members that are only accessed from the component's template. Public members define a public API accessible via DI and queries — do not expose template-only members as public.\n- **`readonly` for Angular-initialized properties:** Mark `input()`, `output()`, `model()`, `viewChild()`, `viewChildren()`, `contentChild()`, and `contentChildren()` as `readonly`.\n- **Group Angular properties first:** In components/directives, group Angular-specific properties (injected dependencies, inputs, outputs, queries) at the top of the class, before any methods.\n- **Event handler naming:** Name event handlers for the action they perform (`saveUserData()`), not for the triggering event (`handleClick()`, `onSubmit()`).\n\n### HTML & Accessibility\n\n- Use **semantically correct** HTML.\n- Respect accessibility: proper use of tags, correct heading hierarchy, accessible attributes when needed.\n- Animations, transitions, and auto-scroll must respect `prefers-reduced-motion`.\n- **Prefer `[class]`/`[style]` bindings over `ngClass`/`ngStyle`:** Built-in class and style bindings are more performant and align with standard HTML. Avoid `NgClass` and `NgStyle` directives.\n\n### SCSS / Styling\n\n- Use **SASS (SCSS)** — no plain CSS if SASS can solve it.\n- Use **BEM** naming methodology.\n- **Mobile first:** default styles are mobile; use breakpoint mixins for desktop adaptations.\n- Never hardcode colors, typography, spacing, or z-index if a design system variable exists.\n- Transitions/animations must respect `prefers-reduced-motion` and provide a no-motion alternative.\n- Keep styles: readable, predictable, grouped by BEM block.\n- Avoid deep selectors or selectors dependent on HTML structure.\n\n## Unit Test Guidelines\n\n- **Behavior over implementation:** Tests should primarily verify observable behavior (DOM changes, emitted values, CSS classes, visible state). Implementation assertions (e.g., `expect(service.method).toHaveBeenCalledWith(...)`) are acceptable when they add real value, but the default approach should always be behavior-first.\n- **Coverage Thresholds:** Mandatory minimum coverage:\n  - Statements: 97%\n  - Branches: 93%\n  - Functions: 96%\n  - Lines: 97%\n- **Branch coverage:** All branches of the file or new functionality under test must be covered (if/else, switch cases, early returns, error paths, edge cases).\n- **Mock external dependencies:** Components and services that are NOT the subject of the test must be mocked/stubbed. Only test the unit in isolation.\n- **Environment & Mocks:**\n  - Use **Vitest** as the test runner.\n  - Implement global mocks for `ResizeObserver` and `IntersectionObserver` when needed.\n  - Tests must fail on unexpected `console.error` or `console.warn` (using spies in setup).\n- **Cleanup:** Reset mocks, spies, and any shared state before and after each test (`beforeEach`/`afterEach`) to ensure test isolation and prevent side effects between tests.\n\n## Infrastructure & Quality\n\n- **ESLint:** Strict adherence to rules. No `any`, no forbidden abbreviations, and strict void return types. Do not disable rules; fix the code.\n- **Husky Hooks:**\n  - `commit-msg`: Validates conventional commits.\n  - `pre-commit`: Runs `lint-staged` (ESLint, Prettier, Stylelint).\n  - `pre-push`: Runs full lint and tests with coverage.\n- **Path Aliases:** Use `~core/*`, `~shared/*`, and `~features/*` for imports.\n\n## Communication\n\n- Always respond in **Spanish** (español).\n- Be cordial and give encouragement when it makes sense, naturally and not forced.\n\n## Analytics\n\n- When working on a new feature, proactively suggest which analytics events should be added (page views, CTA clicks, user interactions, conversions, relevant errors, scroll depth, time on page, etc.).\n- When creating analytics events, do NOT include `page_url` or the logged-in user ID in the payload — the analytics library injects those automatically.\n\n## Commits\n\n- Use **Conventional Commits** format: `type(scope): subject`\n- Subject always lower-case, no trailing period.\n- Body and footer must be empty.\n- Check the project's commitlint config for allowed types and scopes.\n\n## Testing\n\n- Run tests with `npm test` (no additional flags).\n\n## Project Documentation\n\n- After each modification, evaluate if the change affects the project's `AGENTS.md` file. If so, suggest or apply the corresponding update. Examples: new features, new services/components/directives/pipes, dependency version changes, folder structure changes, new routes, ESLint/commitlint config changes, npm script changes, etc.\n","frontmatter":{"apply":"always"},"isInternal":false,"tokens":2152,"sizeBytes":10028}],"systemPromptSnippet":"<yakaai_skills repo=\"Ismaestro/angular-example-app\">\n<!-- File: .aiassistant/rules/Global.md (Tokens: ~2152 | Category: anthropic-skill) -->\n---\napply: always\n---\n\n# Global Rules\n\n## Code Style & Architecture Rules\n\n### TypeScript\n\n- Avoid `any`.\n- Explicitly type **parameters** and relevant data structures.\n- Return types are NOT required, but add them when they improve clarity.\n- **Dependency Injection:** Use the `inject()` function exclusively. Constructor-based injection is forbidden.\n- **Modern Angular Patterns:**\n  - Use **Signals** for local and shared state management.\n  - Use `linkedSignal` for derived state when necessary.\n  - **Effects** (`effect`) must be declared as class properties (`readonly myEffect = effect(...)`) to ensure proper lifecycle management. Avoid calling `effect()` inside constructors.\n  - Mandatory use of `ChangeDetectionStrategy.OnPush` in all components.\n  - Follow **Zoneless** principles; avoid `NgZone` and rely on Signals for change detection.\n\n### General Code Quality\n\n- **Single Responsibility:** Each file, class, and function should do one thing and do it well.\n- **DRY (Don't Repeat Yourself):** Extract repeated code into shared utilities, services, or helper functions.\n- **Error handling:** Always handle errors in async operations (HTTP calls, promises). Never swallow errors silently — at minimum, log them.\n- **Naming conventions:** Use descriptive names without ambiguous abbreviations (avoid `req`, `res`, `err`). Verbs for functions (`getUser`, `handleClick`), nouns for variables (`userList`, `isVisible`).\n- **File Naming & Structure:**\n  - Types: `*.types.ts`\n  - Enums: `*.enums.ts`\n  - Constantes: `*.constants.ts`\n  - Fixtures de test: `*.fixtures.ts`\n  - Desacoplamiento: Extraer definiciones de interfaces y constantes de los archivos de servicios y componentes hacia sus archivos específicos.\n- **Immutability:** Prefer `const` over `let`. Avoid mutating state directly — use spread, `map`, `filter` instead of `push`, `splice`, or direct property assignment.\n- **Early returns:** Use guard clauses to reduce nesting and improve readability.\n- **Pure functions:** Prefer functions without side effects when possible. Isolate side effects at the edges (services, lifecycle hooks).\n- **Avoid magic strings/numbers:** Extract literal values into named constants with descriptive names. Improves maintainability and searchability.\n- **Fail fast:** Validate inputs at the beginning of functions. Do not let invalid data propagate deep into the execution flow.\n- **Small, atomic commits:** Each commit should be self-contained and represent a single responsibility or logical change.\n- **No complex logic in templates:** Move complex expressions (multiple operators, calculations, chained conditions) out of HTML templates into computed signals or component methods.\n- **Consistent return types:** A function should not return `null` sometimes, `undefined` other times, and the actual value in other cases. Be consistent with absence representation.\n- **Avoid nested subscriptions/callbacks:** Use RxJS composition operators (`switchMap`, `mergeMap`, `concatMap`) instead of nested `subscribe()` calls. Same applies to nested `.then()` chains — prefer `async/await`.\n- **Limit side effect scope:** If a function has side effects, they should only affect what is strictly necessary. Do not use a function to silently modify unrelated state.\n- **Prefer composition over inheritance:** Use composition (service injection, utility functions) over deep inheritance chains. Favor small, focused, reusable pieces.\n- **Keep conditionals positive:** Prefer positive conditions (`if (isVisible)`) over double negations or inverted logic (`if (!isNotHidden)`). Improves readability.\n- **One abstraction level per function:** Each function should operate at a single level of abstraction. Do not mix high-level orchestration with low-level details (parsing, formatting) in the same function.\n- **Avoid boolean parameters:** Functions with a `boolean` parameter often do two things. Prefer two descriptive named functions, or use a literal/enum type parameter.\n- **Explicit over implicit:** Prefer explicit, readable code over \"clever\" code. When choosing between brevity and clarity, choose clarity.\n- **Dependency direction:** Dependencies must flow inward: `features → shared → core`. Never the reverse. Core must not import from features or shared.\n- **Encapsulate conditionals:** Extract complex conditions into descriptive named variables or functions (`const isEligible = age >= 18 && hasConsent`) instead of inlining them in `if` statements.\n- **Prefer typed objects over long parameter lists:** When passing complex data to a function, use a typed object parameter instead of multiple positional parameters.\n- **Observables: always unsubscribe:** Every manual Observable subscription in components must be cleaned up in `ngOnDestroy` or via `takeUntilDestroyed()` / `DestroyRef`. Prefer `toSignal()` or the `async` pipe to avoid manual subscriptions altogether.\n- **Defensive data access:** Use optional chaining (`?.`) and nullish coalescing (`??`) when accessing properties that may not exist. Never assume API data is always complete.\n- No empty functions. If a function must exist without implementation, add: `// Empty`\n\n### Components\n\n- Components must contain **only the logic strictly necessary for the view**.\n- Keep components: simple, predictable, and easy to test.\n- Extract cross-cutting logic into **independent services** (scroll, state management, complex calculations, date formatting, etc.).\n- **`protected` for template-only members:** Use `protected` on class members that are only accessed from the component's template. Public members define a public API accessible via DI and queries — do not expose template-only members as public.\n- **`readonly` for Angular-initialized properties:** Mark `input()`, `output()`, `model()`, `viewChild()`, `viewChildren()`, `contentChild()`, and `contentChildren()` as `readonly`.\n- **Group Angular properties first:** In components/directives, group Angular-specific properties (injected dependencies, inputs, outputs, queries) at the top of the class, before any methods.\n- **Event handler naming:** Name event handlers for the action they perform (`saveUserData()`), not for the triggering event (`handleClick()`, `onSubmit()`).\n\n### HTML & Accessibility\n\n- Use **semantically correct** HTML.\n- Respect accessibility: proper use of tags, correct heading hierarchy, accessible attributes when needed.\n- Animations, transitions, and auto-scroll must respect `prefers-reduced-motion`.\n- **Prefer `[class]`/`[style]` bindings over `ngClass`/`ngStyle`:** Built-in class and style bindings are more performant and align with standard HTML. Avoid `NgClass` and `NgStyle` directives.\n\n### SCSS / Styling\n\n- Use **SASS (SCSS)** — no plain CSS if SASS can solve it.\n- Use **BEM** naming methodology.\n- **Mobile first:** default styles are mobile; use breakpoint mixins for desktop adaptations.\n- Never hardcode colors, typography, spacing, or z-index if a design system variable exists.\n- Transitions/animations must respect `prefers-reduced-motion` and provide a no-motion alternative.\n- Keep styles: readable, predictable, grouped by BEM block.\n- Avoid deep selectors or selectors dependent on HTML structure.\n\n## Unit Test Guidelines\n\n- **Behavior over implementation:** Tests should primarily verify observable behavior (DOM changes, emitted values, CSS classes, visible state). Implementation assertions (e.g., `expect(service.method).toHaveBeenCalledWith(...)`) are acceptable when they add real value, but the default approach should always be behavior-first.\n- **Coverage Thresholds:** Mandatory minimum coverage:\n  - Statements: 97%\n  - Branches: 93%\n  - Functions: 96%\n  - Lines: 97%\n- **Branch coverage:** All branches of the file or new functionality under test must be covered (if/else, switch cases, early returns, error paths, edge cases).\n- **Mock external dependencies:** Components and services that are NOT the subject of the test must be mocked/stubbed. Only test the unit in isolation.\n- **Environment & Mocks:**\n  - Use **Vitest** as the test runner.\n  - Implement global mocks for `ResizeObserver` and `IntersectionObserver` when needed.\n  - Tests must fail on unexpected `console.error` or `console.warn` (using spies in setup).\n- **Cleanup:** Reset mocks, spies, and any shared state before and after each test (`beforeEach`/`afterEach`) to ensure test isolation and prevent side effects between tests.\n\n## Infrastructure & Quality\n\n- **ESLint:** Strict adherence to rules. No `any`, no forbidden abbreviations, and strict void return types. Do not disable rules; fix the code.\n- **Husky Hooks:**\n  - `commit-msg`: Validates conventional commits.\n  - `pre-commit`: Runs `lint-staged` (ESLint, Prettier, Stylelint).\n  - `pre-push`: Runs full lint and tests with coverage.\n- **Path Aliases:** Use `~core/*`, `~shared/*`, and `~features/*` for imports.\n\n## Communication\n\n- Always respond in **Spanish** (español).\n- Be cordial and give encouragement when it makes sense, naturally and not forced.\n\n## Analytics\n\n- When working on a new feature, proactively suggest which analytics events should be added (page views, CTA clicks, user interactions, conversions, relevant errors, scroll depth, time on page, etc.).\n- When creating analytics events, do NOT include `page_url` or the logged-in user ID in the payload — the analytics library injects those automatically.\n\n## Commits\n\n- Use **Conventional Commits** format: `type(scope): subject`\n- Subject always lower-case, no trailing period.\n- Body and footer must be empty.\n- Check the project's commitlint config for allowed types and scopes.\n\n## Testing\n\n- Run tests with `npm test` (no additional flags).\n\n## Project Documentation\n\n- After each modification, evaluate if the change affects the project's `AGENTS.md` file. If so, suggest or apply the corresponding update. Examples: new features, new services/components/directives/pipes, dependency version changes, folder structure changes, new routes, ESLint/commitlint config changes, npm script changes, etc.\n</yakaai_skills>"}