These 14 Angular prompts help ChatGPT, Claude, Claude Code and Codex write Angular the way current versions expect: signal inputs and outputs, built-in control flow, computed() instead of effects, httpResource, Signal Forms, zoneless change detection, @defer, Vitest tests and ng update. Each is a template with blanks you fill in.
For type errors and strictness in any TypeScript project, see the TypeScript prompts. This page sticks to Angular itself.
How to use these prompts
Copy a prompt, fill each blank in double braces, or keep the default after the colon. {{angular_version:22}} means Angular 22 unless you change it.
State your Angular major version every time. Defaults have moved quickly: Angular's best-practices file for AI says standalone is the default from v20, OnPush is the default from v22, and Signal Forms are stable in v22. The zoneless guide says zoneless is the default from v21. A prompt that leaves the version out gets an answer for whichever version the model saw most.
Paste the component class and its template together, plus any service it injects. In an agent, name the files and ask it to run ng build and ng test after each change so template type errors show up at once.
Use Angular's own context. The best-practices file is a ready system prompt, and llms.txt indexes the docs. Paste the first into your project instructions and you can keep the prompts below short.
How do you write modern Angular components?
1. Modernize a component to current conventions
Angular's best-practices file asks for input() and output() functions, inject() instead of constructor injection, host bindings in the host object, and class bindings instead of ngClass.
Update this Angular component to current Angular {{angular_version:22}}
conventions without changing its behavior:
{{component_ts}}
{{component_html}}
Apply: input() and output() instead of @Input and @Output, inject()
instead of constructor injection, the host object instead of
@HostBinding and @HostListener, @if, @for and @switch instead of
structural directives, class and style bindings instead of ngClass and
ngStyle, and direct imports instead of CommonModule. Don't add
standalone: true or an explicit OnPush setting if they are defaults in
my version. Show both files and list each change in one line.
2. Design a component's API with signal inputs
Decide inputs, two-way bindings and outputs before a shared component spreads across the app.
I need a reusable {{component:app-date-range}} component. It will be used
in: {{use_cases}}
Design its API for Angular {{angular_version:22}}: which values are
input() or input.required(), which need two-way binding with model() and
[(value)] syntax, and which are output() events with typed payloads.
Add input transforms where a string attribute should become a boolean or
number. Show the class, three usage examples in parent templates, and
the inputs you chose not to add and why.
3. Plan the official migrations
Angular ships schematics for most modernization work, such as ng generate @angular/core:control-flow, ng generate @angular/core:signal-input-migration and ng generate @angular/core:output-migration. See the full list on the migrations page.
Our Angular app is on version {{angular_version:22}} with
{{size:about 200}} components. Most use NgModules, @Input, constructor
injection and *ngIf/*ngFor.
Plan how to run Angular's official migration schematics (standalone,
control flow, inject, signal inputs, outputs, signal queries, cleanup of
unused imports). For each, give the order to run it, what to review in
the diff, and what to test. Recommend using --path to migrate one
feature folder at a time and --insert-todos where available. Then tell
me which leftover cases usually need hand edits.
How do you manage state with signals?
4. Replace effects with computed or linkedSignal
The signals guide says computed signals are "both lazily evaluated and memoized". It recommends derivations for reacting to state changes and keeps effect for side effects on non-reactive APIs.
Review every effect() in this component and its service:
{{code}}
For each effect, decide whether it only derives a value from other
signals. If so, replace it with computed(). If the value is derived but
must also be writable by the user, use linkedSignal(). Keep effects that
sync with something outside Angular (localStorage, a chart library,
logging). Flag any signal writes inside effects that could loop. Show
the new code and explain each change in one line.
5. Bridge RxJS and signals
The RxJS interop guide warns that toSignal "subscribes to the Observable immediately, which may trigger side effects."
This component mixes Observables and signals:
{{component}}
Decide which streams should stay as RxJS (events over time, debouncing,
cancellation with switchMap) and which should become signals for the
template. Convert with toSignal and toObservable where it helps, set an
initialValue or requireSync where needed, and remove manual subscribe
calls and the async pipe where a signal is simpler. Call out any
toSignal on an Observable with side effects, and anywhere toSignal runs
outside an injection context.
6. Load data with httpResource
The httpResource guide says to guard reads of value with hasValue() and to use HttpClient directly for mutations such as POST or PUT.
Rewrite the data loading in this component with httpResource:
{{component}}
The request depends on {{inputs:the userId input and the page signal}}.
Make the URL a function of those signals so changes trigger a new
request. Show loading, error and empty states in the template with @if,
guarding value with hasValue(). Keep the save and delete calls on
HttpClient. Add a response type in TypeScript and explain what happens
to an in-flight request when the inputs change.
How do you build forms in Angular?
7. Build a form with Signal Forms
Angular's best-practices file says to prefer Signal Forms (@angular/forms/signals) for new forms, and notes they are stable in v22.
Build a {{form:sign-up}} form with Signal Forms from
@angular/forms/signals in Angular {{angular_version:22}}.
Fields and rules:
{{fields}}
Use a typed model signal, schema-based validation (required, email,
length and one cross-field rule such as password confirmation), and the
FormField directive in the template. Show field errors only after the
user has touched a field, disable submit while invalid or submitting,
and handle a server-side error on one field. Check the API against the
Signal Forms guide on angular.dev and say if anything you used is
uncertain in my version.
8. Plan a move off an older form setup
For apps with template-driven forms or large Reactive forms you want to change gradually.
This feature uses {{current:template-driven forms with ngModel}}:
{{form_code}}
Compare three options for this form: keep it, move it to Reactive forms,
or move it to Signal Forms. Base the choice on our Angular version
({{angular_version:22}}), how dynamic the form is, and how much code
reads its value elsewhere. Recommend one, show the rewritten form, and
list the tests that should pass before and after the change.
How do you make an Angular app faster?
9. Remove code that depends on zone.js
The zoneless guide says NgZone.onMicrotaskEmpty, onUnstable and onStable never emit in zoneless apps, and recommends afterNextRender or afterEveryRender instead.
We're moving this app to zoneless change detection. Find code that will
break or stop updating:
{{code}}
Look for: NgZone.onStable, onUnstable and onMicrotaskEmpty, checks on
NgZone.isStable, setTimeout or setInterval used to "wake up" the view,
third-party callbacks that change state, and Reactive forms values read
in templates. For each, say why it relies on zone.js and give the fix:
a signal, markForCheck, the async pipe or afterNextRender. Then list the
tests to run to confirm nothing went stale.
10. Defer heavy parts of a template
The @defer guide says deferred dependencies must be standalone and cannot be referenced outside @defer blocks in the same file, or they load eagerly.
This page loads slowly. Here is its template and the components it uses:
{{template}}
Pick which parts to wrap in @defer and choose a trigger for each (on
viewport, on interaction, on idle, on hover or on timer), with prefetch
where it helps. Add @placeholder blocks with a minimum time to avoid
flicker, and @loading and @error blocks where needed. Check that every
deferred component is standalone and not referenced elsewhere in the
file. Explain the expected effect on the initial bundle.
11. Explain an Angular runtime error
Many Angular errors carry an NG code, such as NG0100 for "Expression Changed After Checked", and Angular's Error Encyclopedia explains the common runtime and compiler codes.
I get this error in Angular {{angular_version:22}}:
{{error}}
Here is the component and template it points to:
{{code}}
Explain in plain language what the NG error code means and why it
happens here. Find the exact line, give the fix that follows current
Angular patterns (for example computing a value with a signal instead of
changing state during change detection), and say how to prevent this
class of error in the rest of the codebase.
How do you test Angular code?
12. Write component tests with Vitest
Angular's testing guide says new projects include vitest and jsdom by default, and tests run with ng test.
Write tests for this Angular component with {{runner:Vitest}} and
TestBed:
{{component}}
Set signal inputs with fixture.componentRef.setInput. Test what the user
sees: rendered text, button states and emitted outputs. Cover the main
flow, a loading state, an error state and one keyboard interaction. Use
real child components unless they make network calls. Avoid reading
private fields. Show the spec file only.
13. Test a service that calls an API
The HTTP testing guide says to register provideHttpClient() before provideHttpClientTesting(), and to call verify() so no request is left outstanding.
Write tests for this Angular service:
{{service}}
Use provideHttpClient() then provideHttpClientTesting() and
HttpTestingController. For each method, assert the URL, method, headers
and body with expectOne, flush a realistic response, and check the
result. Add one test for a 500 error and one for a retry or timeout if
the service has them. Call verify() in afterEach.
14. Plan an upgrade with ng update
The ng update reference shows moving between majors by pinning the target, for example ng update @angular/cli@^21 @angular/core@^21, and points to the Angular Update Guide for details.
Plan an upgrade of our app from Angular {{from:19}} to
{{to:22}}. Here is package.json and angular.json:
{{files}}
Give me: the order of major versions to go through, the ng update
command for each step, third-party packages that must be upgraded first
(component libraries, NgRx, testing tools), and the breaking changes most
likely to hit code like ours. Suggest running each step on its own
branch with --create-commits so migrations are easy to review. Flag
anything you're unsure about so I can check it in the Update Guide.
Turn your favorite one into a skill
If you run the modernization or testing prompts every week, turn one into a skill so Claude Code or Codex applies it when the task matches. Paste it into the free SKILL.md generator to get a valid SKILL.md in your browser. For larger structural changes, the refactoring prompts work in any codebase, and the unit test prompts cover test design beyond Angular.
To keep these prompts one shortcut away, save them in Kipt. Your prompts live as Markdown in a private GitHub repo you own, blanks like {{angular_version:22}} stay fillable, and Cmd+K finds any prompt by name or tag.