What this prompt does
This prompt directs the AI to build a custom [component_name] Angular component on top of Angular CDK primitives rather than reinventing low-level behaviour. You describe the [requirements], choose which [cdk_features] to lean on (Overlay, a11y helpers, Scrolling), and set the [wcag_level] and [breakpoints], and it returns a component wired for keyboard navigation, ARIA, theming, animation, and reactive forms. The output also includes content projection slots and the tests and stories that keep the component maintainable.
It works because CDK already solves the hard parts — focus trapping, overlay positioning, live announcements — and the prompt forces the AI to use those instead of hand-rolling buggy equivalents. Naming the [breakpoints] makes responsive behaviour explicit (for example a dropdown that becomes full-screen on mobile), and requiring ControlValueAccessor means the component drops straight into Angular reactive forms with formControlName. The accessibility requirements are baked into the spec at the chosen [wcag_level], not bolted on afterward, so keyboard and ARIA support arrive with the first version rather than as a later retrofit.
When to use it
- Building a component Angular Material doesn't ship (multi-select with chips, custom pickers)
- Needing keyboard navigation and ARIA that meet a specific
[wcag_level] - Wanting a component that integrates with reactive forms via ControlValueAccessor
- Reusing CDK Overlay or FocusTrap instead of writing positioning and focus logic by hand
- Standardising responsive behaviour across
[breakpoints]for a shared component library - Producing Storybook stories and tests alongside the component for a design system
Example output
You get the full component: template and class using the chosen [cdk_features], keyboard handlers for Tab/Arrow/Enter/Escape, ARIA roles and attributes meeting [wcag_level], Angular Material theming hooks, animation via the animations API, ControlValueAccessor wiring for reactive forms, content projection slots using ng-content and ng-template, unit tests covering navigation and ARIA states, and Storybook stories for each variant. Standalone or NgModule setup and usage examples are included so it drops into a real project.
Pro tips
- Make
[requirements]concrete (searchable options, async loading, group support) so the AI scopes the component correctly instead of guessing - Only request the
[cdk_features]you need; pulling in Overlay, a11y and Scrolling together adds complexity if the component is simple - Set
[wcag_level]to your real compliance target — 2.1 AA is common — because it changes which ARIA and contrast checks the tests enforce - Spell out responsive intent in
[breakpoints], like the dropdown going full-screen on mobile, or you'll get desktop-only behaviour - Verify the generated ARIA against a real screen reader; automated tests catch attributes but not awkward or confusing announcements
- Wire the component through ControlValueAccessor early so validation and value changes flow naturally inside reactive form groups
- If you use standalone components, say so explicitly so the AI skips the NgModule boilerplate and emits the standalone setup instead
