If you’ve been using Claude Code for your daily Angular work – scaffolding components, debugging RxJS chains, refactoring services – you’ve probably noticed it sometimes generates outdated patterns. NgModules instead of standalone components. @Input() decorators instead of signal inputs. Constructor injection instead of inject(). The model was trained on code from a specific point in time, and Angular evolves fast.
Agent Skills solve this. They’re structured instruction files that teach Claude how to write code the way your project needs it written. Here we will focus on what Skills are, how they work in Claude Code, how to write effective ones, and what community resources already exist for Angular developers.
What Are Skills?
A Skill is a directory containing a SKILL.md file – a markdown document with YAML frontmatter and instructions that Claude reads before performing tasks. Think of it as a recipe card you hand to a chef. The chef already knows how to cook, but the recipe tells them exactly how you want your dish prepared.
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>();
}
Two fields in the frontmatter are critical: `name` (lowercase, hyphens, max 64 chars) and `description` (max 1024 chars). The description determines whether Claude picks up your Skill – it’s what Claude scans to decide relevance.
## How Skills Work in Claude Code
When you use Claude Code in your terminal, Skills integrate at three levels:
**CLAUDE.md** sits in your project root and loads automatically for every conversation. It contains project-specific context – your tech stack, conventions, commands. This is the equivalent of onboarding a new team member by handing them a README.
**Skills** live in `.claude/skills/` (or wherever your agent stores them) and activate based on the task. When you ask Claude to create a component, it checks available Skill descriptions, finds the relevant one, reads its `SKILL.md`, and follows the instructions. Multiple Skills can activate for a single task.
**Built-in Skills** handle file creation – Word documents, spreadsheets, presentations. These are less relevant for Claude Code workflows, where the focus is on generating and editing source code.
The loading is progressive. At startup, only the `name` and `description` from all Skills are loaded into context. Claude reads the full `SKILL.md` only when a Skill becomes relevant, and reads referenced files (like `references/component-patterns.md`) only when needed. This means you can bundle comprehensive reference material without paying a context window cost upfront.
## Angular Skills by AnalogJS
Before writing your own Skills from scratch, check what already exists. Brandon Roberts (NgRx maintainer, creator of AnalogJS, Angular GDE) published a collection of Angular Skills targeting 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 covers ten domains, each with a SKILL.md and a references/ directory for advanced patterns:
- angular-component – standalone components with signal inputs/outputs, OnPush, host bindings, content projection
- angular-signals – signal(), computed(), linkedSignal(), effect(), RxJS interop with toSignal() and toObservable()
- angular-di – inject() function, injection tokens, provider configuration, hierarchical DI
- angular-forms – Signal Forms with schema-based validation and field state management
- 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 support for v21+
- angular-tooling – CLI commands, schematics, build configuration
The repository follows good Skill authoring practices. Each Skill uses a two-level structure: SKILL.md for core patterns and a references/ directory for advanced examples. The descriptions are specific enough for agents to trigger correctly. And the content targets Angular v20+ defaults – no standalone: true (it’s the default now), signal-based APIs everywhere, functional patterns over class-based ones.
One thing to watch: these Skills are designed as general Angular knowledge, not project-specific conventions. They teach Claude modern Angular patterns, but they won’t enforce your team’s folder structure, naming conventions, or state management choices. For that, you’ll want to layer your own Skills on top – which is exactly what the next sections cover.
The npx skills CLI installs Skills to the correct location for your agent (Claude Code, Cursor, Codex, and others). It’s agent-agnostic by design. Skills follow an open format developed by Anthropic, but they work across multiple AI coding tools.
Writing Effective Skills – Best Practices
The official Anthropic documentation on Skill authoring distills into a few principles that matter most for day-to-day Angular development.
Concise is key
The context window is a shared resource. Your Skill competes with the system prompt, conversation history, other Skills, and your actual request. Every line needs to justify its token cost.
The default assumption: Claude is already very smart. Only add context Claude doesn’t already have. Don’t explain what dependency injection is. Don’t describe what signals do conceptually. Focus on your project’s specific decisions and patterns.
<!-- ❌ 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.
Challenge each paragraph: „Does Claude really need this explanation?” If the answer is no, cut it.
Match freedom to fragility
Not every instruction needs the same level of specificity. Match it to how fragile the operation is.
High freedom – when multiple approaches are valid and context determines the best one:
## 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 – when a specific sequence must be followed or consistency is critical:
## 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
})
)
)
}))
);
Do not use class-based stores or @ngrx/store for new features.
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."
Always write descriptions in third person. The description gets injected into the system prompt, and inconsistent point-of-view causes discovery problems.
Use progressive disclosure
Keep the main SKILL.md under 5,000 words. Split detailed content into separate files that Claude loads only when relevant:
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)
Keep references one level deep. If entity-management.md itself references another file, Claude may only partially read the nested file using head -100 instead of loading it completely.
Include anti-patterns
Telling Claude what not to do is often more valuable than telling it what to do. If you’ve seen Claude generate wrong patterns for your project, capture those 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
Provide complete examples, not fragments
Claude follows examples more reliably than abstract descriptions. Show the full 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);
}
}
This one example teaches Claude your import style, decorator configuration, signal usage, control flow syntax, store injection pattern, and access modifiers – all without a single line of prose explanation.
Use consistent terminology
Pick one term and stick with it throughout the Skill. If you call it „feature folder” in section one, don’t switch to „domain module” in section three. Inconsistent naming confuses Claude the same way it confuses humans during code review.
Avoid time-sensitive information
Don’t include „if you’re on Angular 19, do X, but on Angular 20 do Y.” Instead, document the current approach and optionally tuck the old pattern in a collapsible section:
## 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 most effective development process is surprisingly meta: use one Claude instance to write the Skill, test it with another.
Step 1: Work through a real task with Claude Code without any Skills. Notice what you repeat – „use standalone”, „use inject()”, „follow this folder structure”. That repetition is your Skill’s content.
Step 2: Ask Claude to generate a SKILL.md from your conventions. Claude understands the format natively. Then review for conciseness – Claude tends to over-explain. Cut anything Claude would already know.
Step 3: Test the Skill on real tasks in a fresh Claude Code session. Ask it to create a feature, generate tests, refactor a service. Observe where it follows the Skill correctly and where it drifts.
Step 4: When you spot gaps, refine. If Claude forgot to use track in @for loops, make that rule more prominent. If it used the wrong state management pattern, add a stronger constraint. Each iteration improves the Skill based on observed behavior, not assumptions.
This observe-refine-test cycle is how good Skills get built. The AnalogJS angular-skills repository went through exactly this process – and it shows in the quality of the output.
CLAUDE.md – The Project Layer
Skills provide reusable patterns across projects. CLAUDE.md provides project-specific context. They complement each other.
A practical CLAUDE.md for an Angular project:
# 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 reads your project, it loads CLAUDE.md automatically, then activates relevant Skills based on the task. The three layers stack: built-in knowledge → Skills → project context.
Practical Takeaways
If you’re using Claude Code for Angular development, here’s what to do this week:
Install the AnalogJS skills. One command gives you ten well-structured Skills covering modern Angular patterns. Even if your project has its own conventions, these provide a solid baseline that prevents Claude from suggesting deprecated APIs.
npx skills add analogjs/angular-skills
Add CLAUDE.md to your project root. Document your tech stack, conventions, and commands. Every Claude Code session touching your codebase will benefit from this context. Keep it short – 30-50 lines covering what matters most.
Create one custom Skill. Pick your team’s most repeated convention – the store setup pattern, the component template, the test structure. Write a SKILL.md for it. Test it on a real task. Refine based on what Claude actually generates.
Keep Skills concise. Challenge every line. Claude already knows Angular – your Skill only needs to capture what’s specific to your project or what has changed since its training data.
Skills transform Claude Code from a general-purpose coding agent into one that knows your conventions, your stack, and your architecture from the first prompt. For Angular developers working in enterprise environments with large codebases and strict patterns, the difference between generic suggestions and output that matches your project’s conventions is measured in hours saved per week.