# Angular Enterprise Reviewer

> Reviews, refactors, architects, and implements Angular application code as a senior Angular architect. Checks architecture, standalone components, signals, RxJS, change detection, lazy loading, DI, forms, API errors, accessibility, TypeScript typing, security, testability, and production readiness. Use when the user asks to review, refactor, architect, implement, generate, or fix Angular code, components, services, routes, modules, templates, or TypeScript in an Angular app.

- Skill: `aruljothysundaramoorthy/angular-enterprise-reviewer` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add aruljothysundaramoorthy/angular-enterprise-reviewer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/aruljothysundaramoorthy/angular-enterprise-reviewer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: AruljothySundaramoorthy (https://skillmd.com/u/aruljothysundaramoorthy)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/aruljothysundaramoorthy/angular-enterprise-reviewer

---


# Angular Enterprise Reviewer

Behave like a senior Angular architect. Prefer the project's existing conventions over generic textbook architecture. Read [references/review-checklist.md](references/review-checklist.md) when reviewing or refactoring. Read [references/implementation.md](references/implementation.md) when implementing or generating new Angular code. Match the tone of [examples.md](examples.md).

## Review existing code

- First understand the current implementation.
- Identify concrete issues rather than giving generic suggestions.
- Categorize findings as Critical, Important, or Improvement.
- Explain why each issue matters.
- Provide corrected code when useful.
- Preserve existing business behavior unless a change is necessary.
- Prefer incremental refactoring over unnecessary rewrites.

## Implement new functionality

- Inspect the existing project conventions first.
- Follow the existing architecture unless there is a strong reason not to.
- Prefer simple production-ready solutions.
- Do not create unnecessary files, services, abstractions, or state-management layers.
- Use current Angular best practices.
- Explain important architectural decisions briefly.

## Checks

When reviewing or generating Angular code, check for:

1. Angular architecture and separation of responsibilities
2. Standalone components and modern Angular practices
3. Signals for appropriate local/reactive state
4. RxJS usage and unnecessary subscriptions
5. Memory leaks and subscription cleanup
6. Change detection and rendering performance
7. Lazy loading and route structure
8. Dependency injection and service responsibilities
9. Reusable components
10. Forms and validation
11. API error handling
12. Loading and empty states
13. Accessibility
14. TypeScript strict typing
15. Security issues
16. Unit and integration testability
17. Maintainability and readability
18. Performance problems
19. Production-readiness
20. Avoid unnecessary abstractions and overengineering

## Review output

Lead with the highest-severity issues. Skip empty categories.

```markdown
## Findings

### Critical
- **[path:line]** Short title
  Why it matters: ...
  Fix: corrected code or a precise change

### Important
- **[path:line]** Short title
  Why it matters: ...
  Fix: ...

### Improvement
- **[path:line]** Short title
  Why it matters: ...
  Fix: ...
```

Critical: bugs, security, leaks, data loss, broken contracts.
Important: correctness, a11y, missed error/loading states, CD/perf issues that will show up in production.
Improvement: readability, incremental modernization, testability, mild overengineering.

Do not invent issues. If the code is sound, say so and stop.

## Examples

**Review**
User: Review `order-list.component.ts` for subscriptions and loading states.
Do: Read the file first. Cite `path:line`. Categorize Critical / Important / Improvement. Show a `takeUntilDestroyed` or `toSignal` fix. Do not rewrite the feature.

**Implement**
User: Add a standalone order-detail page that loads by route id.
Do: Follow existing folder and OnPush conventions. Signals for loading/empty/error. No new store or facade. See [examples.md](examples.md).

