If you’ve already integrated Claude Code into your Angular workflow—scaffolding components, untangling RxJS chains, or reshaping services—you’ve likely spotted a pattern: it sometimes falls back on older, deprecated code. NgModules where standalone components should be. @Input() decorators where signal-based inputs are expected. Constructor injection rather than inject(). Explainable by the fact that the model’s training data is anchored to a particular release timeline, and Angular changes quickly.
Agent Skills step in as the fix. These files act as structured guidance, steering Claude toward the exact coding conventions your project follows. What follows is a closer look at what Skills actually are, how they operate inside Claude Code, how you can craft your own effective ones, and which community-built resources Angular developers already have at their disposal.
What Are Skills?
At its core, a Skill is a folder that holds a SKILL.md file—a Markdown document carrying YAML frontmatter plus instructions Claude loads ahead of executing work. Picture a recipe card placed in front of an experienced chef: the chef knows their craft, but the card dictates how you specifically want the final dish plated.
angular-component/
├── SKILL.md # Main instructions (loaded when triggered)
└── references/
└── component-patterns.md # Advanced patterns (loaded as needed)
The SKILL.md follows a simple format:
---
name: angular-component
description: "Generates Angular standalone components with signal
inputs/outputs, OnPush change detection, and inject() function.
Use when creating components, pages, or features."
---
# Angular Component Patterns
## Component structure
Always use standalone components with OnPush:
```typescript
@Component({
selector: 'app-user-list',
changeDetection: ChangeDetectionStrategy.OnPush,
template: `...`
})
export class UserListComponent {
private readonly userService = inject(UserService);
readonly users = input.required<User[]>();
readonly selected = output<User>();
}
When defining a Skill in the frontmatter, two fields truly matter: `name` (must be lowercase, use hyphens, and stay under 64 characters) and `description` (keep it to 1024 characters or less). The `description` is what Claude uses to decide if your Skill is relevant – this text is what it scans to determine whether to pull up your Skill.
## How Skills Work in Claude Code
Running Claude Code in your terminal gives you Skills operating on three distinct layers:
**CLAUDE.md** is placed in the project root and gets loaded automatically for every interaction. It holds the project-specific details – your tech stack, conventions, and commands. Think of it like handing a README to a new developer joining the team.
**Skills** reside in `.claude/skills/` (or wherever your agent is configured to look) and come into play based on the task at hand. When you ask Claude to build a component, it scans available Skill descriptions, picks the matching one, opens its `SKILL.md`, and executes the instructions. A single request can trigger multiple Skills simultaneously.
**Built-in Skills** cover file generation – Word docs, spreadsheets, presentations. For Claude Code workflows this matters less, since the focus is on writing and modifying source code.
The loading is gradual. At the start, only the `name` and `description` fields from every Skill sit in context. Claude reads the full `SKILL.md` only once a Skill is flagged as relevant, and it pulls in referenced files (such as `references/component-patterns.md`) only on demand. This design lets you stash extensive reference material without burning context window capacity from the outset.
## Angular Skills by AnalogJS
Before you start writing your own Skills from zero, look at what's already out there. Brandon Roberts (NgRx maintainer, AnalogJS creator, Angular GDE) has released a set of Angular Skills centered on v20+ patterns:
„`bash
# Install all Angular skills
npx skills add analogjs/angular-skills
# Or install individually
npx skills add analogjs/angular-skills/skills/angular-component
npx skills add analogjs/angular-skills/skills/angular-signals
npx skills add analogjs/angular-skills/skills/angular-forms
The collection spans ten areas, each featuring a SKILL.md plus a references/ directory for deeper patterns:
- angular-component – standalone components using signal inputs/outputs, OnPush, host bindings, content projection
- angular-signals – signal(), computed(), linkedSignal(), effect(), RxJS interop via toSignal() and toObservable()
- angular-di – inject() function, injection tokens, provider setup, hierarchical DI
- angular-forms – Signal Forms with schema-driven validation and field state tracking
- angular-http – httpResource(), resource(), HttpClient, functional interceptors
- angular-routing – lazy loading, functional guards/resolvers, input.fromRoute()
- angular-directives – attribute/structural directives, host directive composition
- angular-ssr – SSR, incremental hydration, prerendering
- angular-testing – TestBed, component harnesses, signal testing, Vitest for v21+
- angular-tooling – CLI commands, schematics, build configuration
The repo demonstrates solid Skill authoring patterns. Every Skill uses a two-tier layout: SKILL.md for foundational patterns and a references/ directory for advanced examples. The descriptions are precise enough for agents to trigger appropriately. The content aligns with Angular v20+ defaults – no standalone: true (it's the standard now), signal-based APIs throughout, functional patterns preferred over class-based ones.
One caveat: these Skills are meant as general Angular knowledge, not project-specific guidance. They give Claude modern Angular techniques, but they won't enforce your team's folder layout, naming rules, or state management approach. For that, you'll want to build your own Skills on top – which is what the upcoming sections address.
The npx skills CLI places Skills in the right spot for your agent (Claude Code, Cursor, Codex, and more). It's agent-agnostic by design. Skills follow an open format from Anthropic, yet they function across a range of AI coding tools.
Writing Effective Skills – Best Practices
Anthropic's official docs on Skill authoring boil down to a handful of principles that pay off most for everyday Angular work.
Keep it concise
The context window is a limited pool. Your Skill competes with the system prompt, conversation history, other Skills, and your real request. Every line has to earn its token cost.
Operating under the assumption that Claude is already highly capable, you should only provide context that lies outside its existing knowledge. Avoid explaining established concepts like dependency injection or the purpose of signals. Instead, concentrate on the unique choices and conventions within your own codebase.
<!-- ❌ Too verbose -->
## Dependency Injection
Angular uses dependency injection (DI) to provide components
with the services they need. DI is a design pattern where a
class receives its dependencies from an external source rather
than creating them itself. In Angular, you can use the inject()
function to request dependencies...
<!-- ✅ Concise – Claude knows what DI is -->
## DI conventions
Use `inject()` function exclusively. Never use constructor injection.
Provide services in `root` unless feature-scoped state is needed.
Ask yourself about every paragraph: „Is this explanation genuinely necessary for Claude?” If it isn't, remove it.
Align latitude with vulnerability
Different operations call for different degrees of precision. Tailor that precision to how easily something can break.
Broad latitude – when several strategies work and the right choice depends on the situation:
## Code review focus areas
1. Check for proper signal usage and avoid unnecessary subscriptions
2. Verify OnPush compatibility
3. Look for missing unsubscribe patterns in remaining RxJS usage
4. Confirm barrel exports are consistent
Low freedom – in scenarios where a particular order is mandatory or uniformity is paramount:
## State management setup
Use exactly this NgRx Signal Store pattern:
```typescript
export const UsersStore = signalStore(
{ providedIn: 'root' },
withState(initialState),
withComputed(({ users }) => ({
activeUsers: computed(() => users().filter(u => u.active))
})),
withMethods((store, usersService = inject(UsersService)) => ({
loadUsers: rxMethod<void>(
pipe(
switchMap(() => usersService.getAll()),
tapResponse({
next: users => patchState(store, { users }),
error: console.error
})
)
)
}))
);
When building new functionality, avoid class-based stores and @ngrx/store altogether.
Think of it this way: if there's only one safe path forward (state store setup, migration scripts), give exact instructions. If the terrain is open (code reviews, refactoring suggestions), give direction and let Claude navigate.
### Write descriptions that trigger correctly
The `description` field is what Claude uses to choose your Skill from potentially dozens of available ones. Be specific and include trigger terms.
```yaml
# ❌ Too vague – Claude won't know when to activate
description: "Helps with Angular stuff"
# ✅ Specific triggers and scope
description: "Generates Angular standalone components with signal
inputs/outputs, OnPush change detection, host bindings, and
inject() function. Use when creating components, pages, or
features in Angular 20+ projects."
Descriptions must be authored in third person at all times. Because the description is placed directly into the system prompt, shifting point-of-view can break the model's ability to locate the right skill.
Progressive disclosure is key
The primary SKILL.md should stay below 5,000 words. Offload the deeper material into extra files that Claude pulls in solely when needed:
ngrx-signal-store/
├── SKILL.md # Core patterns (~200 lines)
└── references/
├── entity-management.md # withEntities() patterns
├── rxjs-integration.md # rxMethod, tapResponse
└── testing-patterns.md # Store testing utilities
In SKILL.md, point to these files:
## Advanced patterns
**Entity collections**: See [references/entity-management.md](references/entity-management.md)
**RxJS integration**: See [references/rxjs-integration.md](references/rxjs-integration.md)
**Testing stores**: See [references/testing-patterns.md](references/testing-patterns.md)
Nested references should stay at a single level. When entity-management.md points to yet another file, Claude might only skim that deeper document with head -100 rather than reading all of it.
Document anti-patterns
Explaining to Claude which behaviors to avoid frequently carries more weight than prescribing correct ones. Whenever you observe Claude producing faulty patterns in your codebase, write those down explicitly:
## Avoid
- Never use `subscribe()` in components – use `toSignal()` or async pipe
- Never use constructor injection – always `inject()`
- Never import `CommonModule` – use standalone imports (`NgIf`, `NgFor`)
or preferably `@if` / `@for` control flow
- Never use `*ngIf` / `*ngFor` – use `@if` / `@for` block syntax
- Never create NgModules – all new code is standalone
Supply whole examples rather than snippets
Claude tends to act on concrete samples more consistently than on high-level explanations. Provide the entire file:
import { Component, ChangeDetectionStrategy, inject, input, output } from '@angular/core';
import { UsersStore } from './users.store';
import { User } from './user.model';
@Component({
selector: 'app-user-list',
changeDetection: ChangeDetectionStrategy.OnPush,
template: `
@if (store.loading()) {
<app-spinner />
} @else {
@for (user of store.activeUsers(); track user.id) {
<app-user-card
[user]="user"
(selected)="onSelect($event)" />
}
}
`
})
export class UserListComponent {
protected readonly store = inject(UsersStore);
readonly filter = input<string>('');
readonly selected = output<User>();
onSelect(user: User) {
this.selected.emit(user);
}
}
Through this single example, Claude absorbs your import conventions, decorator setup, signal patterns, control-flow syntax, store injection methodology, and access modifier choices — no explicit textual instructions required.
Maintain consistent terminology
Select a single term and use it consistently throughout the Skill. Referring to „feature folder” in one section and „domain module” in another is counterproductive. Inconsistent vocabulary throws Claude off just as it would trip up a developer during a peer review.
Exclude time-sensitive guidance
Refrain from phrasing like „for Angular 19, implement X, but with Angular 20, switch to Y.” Instead, describe the current standard and, if needed, place the legacy approach inside an expandable region:
## Current approach
Use `@if` / `@for` block syntax for all control flow.
<details>
<summary>Legacy pattern (Angular < 17)</summary>
Previously used `*ngIf` and `*ngFor` structural directives.
These are no longer recommended.
</details>
Iterating on Skills with Claude
The development workflow here is refreshingly self-referential: spin up one Claude instance to draft the Skill, then validate it with a second.
Step 1: Execute a real assignment in Claude Code with no Skills loaded. Pay attention to the commands and patterns you type again and again – like reaching for standalone components, calling inject(), or sticking to a particular directory layout. That recurring behavior is exactly what your Skill should capture.
Step 2: Have Claude produce a SKILL.md from those conventions. Claude natively understands this format. Next, trim it down — Claude tends to pad instructions. Delete anything that Claude would already know without being told.
Step 3: Put the Skill to work on genuine tasks inside a brand-new Claude Code session. Have it build a feature, draft tests, or rethink a service. Watch closely for where the Skill holds and where it slips.
Step 4: After spotting mistakes, iterate. If Claude overlooked track inside an @for loop, elevate that rule in the Skill. If it leaned on the wrong state pattern, introduce a stricter guideline. Each pass sharpens the Skill based on what Claude actually does, not what you expect it to do.
This loop—observe, refine, test—is the engine behind solid Skills. The AnalogJS angular-skills repo was built through precisely this method, and the quality of its output speaks for itself.
CLAUDE.md – The Project Layer
Skills deliver reusable patterns that carry across projects. CLAUDE.md adds context that is specific to a given project. The two fit together naturally.
Here is what a practical CLAUDE.md for an Angular app might look like:
# CLAUDE.md
## Project
- Angular 21 with standalone components
- State management: NgRx Signal Store
- UI: Angular Material with custom theme
- API: REST with HttpClient + httpResource()
- Testing: Vitest (unit), Playwright (e2e)
## Conventions
- Feature-based folder structure: feature-name/{component,service,store,model,routes}
- All components use OnPush change detection
- API calls through services, never directly in components
- Barrel exports (index.ts) for every feature folder
## Commands
- `npm run test` – Run Vitest
- `npm run e2e` – Run Playwright
- `npm run lint` – ESLint check
- `npm run build` – Production build
## Avoid
- No NgModules, no CommonModule imports
- No constructor injection
- No *ngIf/*ngFor (use @if/@for)
- No subscribe() in components
When Claude Code analyzes your repository, it pulls in CLAUDE.md automatically and then triggers the relevant Skills depending on the task at hand. The architecture works as a tiered system: built-in knowledge is augmented by Skills, which are further refined by project-specific context.
Practical Takeaways
For those leveraging Claude Code in Angular projects, these are the steps to take without delay:
Add the AnalogJS skill set. A single terminal command grants you ten Skills, each carefully organized to address current Angular best practices. Even when your codebase follows custom rules, these serve as a dependable foundation, stopping Claude from proposing outdated or unmaintained APIs.
npx skills add analogjs/angular-skills
Place a CLAUDE.md file in your project’s root directory. Within it, spell out the stack you use, the patterns you follow, and the commands you rely on. Any Claude Code session that works with your code will pick up this guidance automatically. Aim for brevity—around 30 to 50 lines—and focus only on the essentials.
Develop a single custom Skill of your own. Choose the convention your team repeats most often—whether that’s how you set up stores, format component templates, or structure tests. Write a dedicated SKILL.md for that one pattern. Then put it to work on a real assignment, and fine-tune it according to what Claude actually produces.
Resist the urge to make Skills verbose. Scrutinize every line you include. Claude is already familiar with Angular fundamentals—your Skill should only highlight what is unique to your project or what has evolved since the model’s last update.
With Skills in place, Claude Code shifts from a generic coding assistant to one that already understands your workflows, your preferred libraries, and your overall architecture from the initial interaction. For Angular developers working in large-scale enterprise systems with rigid conventions, the gap between broad recommendations and code that aligns with your established patterns translates into hours reclaimed every week.