DEV Community: hassantayyab

AI Agent Tool Design: What I Wish I Knew Earlier

hassantayyab — Sun, 08 Feb 2026 16:23:00 +0000

I spent three days building my first AI agent, and it was terrible.

Not because I chose the wrong model. Not because my prompts were bad. The agent just... didn't work. It would give vague answers, get confused by simple requests, and sometimes try to do things it clearly wasn't capable of doing.

Then I discovered something that changed everything: the quality of an AI agent depends almost entirely on how you design its tools.

This article is what I wish I'd read before building that first agent. If you're exploring AI agent development—whether you're an Angular developer like me looking to add AI features, or just getting started with AI engineering—this framework will save you a lot of frustration.

What Are Tools in AI Agents?

Let me start with the basics because this confused me at first.

When we talk about "tools" in the context of AI agents, we're talking about functions the AI can call. That's it. Nothing fancy.

Here's a simple example:

const weatherTool = {
  name: "get_weather",
  description: "Get current weather for a city",
  parameters: {
    city: {
      type: "string", 
      description: "City name"
    }
  },
  execute: async (city) => {
    const data = await fetch(`api.weather.com/${city}`);
    return data;
  }
};

Without this tool, if someone asks "What's the weather in Tokyo?", the agent can only say "I don't have access to current weather data."

With this tool, the agent can actually call the function, get real data, and give a useful answer.

Tools transform your agent from a conversationalist into something that can actually do things.

This is similar to how we think about components in Angular—each tool should do one thing well, and you compose them together to build something powerful.

The Pattern That Changed My Approach

After my first failed attempt, I found this framework in a book about AI engineering, and it clicked immediately:

Ask yourself: "What would a human do to solve this problem?"

Then turn each step into a tool.

That's it. Simple but incredibly powerful.

Real Example: The Book Recommendation Agent

Let me show you an example that made this concept crystal clear for me.

Imagine you're building an agent that recommends books from investor reading lists. You have a database of 10,000 books that various investors have recommended.

My first instinct (WRONG):
Dump all 10,000 books into the agent's context and let it figure things out.

What actually happened:
The agent got completely overwhelmed. It couldn't navigate the data effectively. Recommendations were poor or generic.

The better approach:
Think like a human analyst. If I were manually analyzing these book recommendations, what would I do?

Look up which investors recommended specific books
Filter by genre or topic
Sort by popularity (how many investors recommended it)
Compare recommendations between different types of investors (founders vs VCs)

Each of these operations became a tool:

Tools created:
- get_books_by_investor(investor_name)
- get_books_by_genre(genre)
- sort_books_by_recommendations(books)
- get_investors_by_type(type) // founders vs VCs

Result: The agent could now navigate the data intelligently and make genuinely good recommendations.

This is exactly how I think about building features in Angular. When I'm creating a complex component, I break it down into smaller, focused services and components that each handle one responsibility. The same principle applies to AI agent tools.

Why Tool Design Matters More Than You Think

Here's what surprised me: tool design has more impact on your agent's quality than almost anything else.

You could have:

Perfect prompts
The best model available
Great context management

But if your tools are poorly designed, your agent will still struggle.

On the flip side, with well-designed tools, even a simpler model can deliver excellent results.

Tools = the capabilities of your agent.

Think of it this way: an LLM without tools is like a smart person with no hands. They can think, they can talk, but they can't actually do anything. Tools are what let your agent take action.

The Framework I Now Use

When I start building an agent, I follow this process:

Step 1: Define the Goal

Be specific. "Build a customer support agent" is too vague.

Better: "Build an agent that helps customers troubleshoot login issues, check order status, and create support tickets."

Step 2: List Human Actions

If a human were doing this job, what specific actions would they take?

For customer support:

Look up customer account information
Search help documentation
Check order/subscription status
Create a support ticket
Send confirmation email

Step 3: One Action = One Tool

Each action becomes a focused tool:

Tools needed:
- get_customer_info(customer_id)
- search_help_docs(query)
- check_order_status(order_id)
- create_ticket(issue_type, description)
- send_email(to, subject, body)

Step 4: Write Clear Descriptions

This part is crucial. The tool description isn't just for you—the agent actually reads it to decide when to use each tool.

Bad description:

{
  name: "search",
  description: "Search stuff"
}

The agent thinks: "When do I use this? What does it search?"

Good description:

{
  name: "search_help_docs",
  description: "Search company help documentation for 
                troubleshooting steps. Use this when 
                customer has a technical issue. Returns 
                relevant articles with solutions.",
  parameters: {
    query: {
      type: "string",
      description: "Search terms describing the issue 
                   (e.g. 'login error', 'payment failed')"
    }
  }
}

The agent thinks: "Clear! Use this for technical issues, search help docs."

Coming from a UX design background, I think of tool descriptions as the "interface" between the AI and your functionality. Good UX principles apply here—be clear, be specific, provide examples.

Common Mistakes I'm Learning to Avoid

Mistake #1: Too Many Tools

I made this mistake early. I thought "more tools = more capable agent."

Wrong.

With 25 tools: The agent gets confused about which to use, slows down analyzing all options, and prompts get expensive.

With 5 focused tools: Clear choices, fast decisions, cheaper to run.

Rule I follow now: Start with 3-5 tools. Only add more when there's a clear need.

Mistake #2: Vague Tool Descriptions

Remember: the agent reads your tool descriptions to decide what to use.

Vague descriptions = confused agent = poor results.

Always include:

What the tool does
When to use it
What it returns
Example inputs

Mistake #3: Tools That Do Too Much

I initially created a handle_customer_issue() tool that did everything—looked up the customer, searched docs, created tickets, sent emails.

The problem: The agent couldn't control the sequence. It was a black box.

Better approach: Separate tools that the agent chains together as needed. This gives the agent flexibility to handle different scenarios.

It's similar to the single responsibility principle we use in Angular services—each service should do one thing well.

Mistake #4: Not Testing Tools First

This one cost me debugging time.

I'd build a tool, give it to the agent, and when things failed, I wouldn't know if it was the tool or the agent logic.

Better workflow:

Build tool
Test tool manually (unit test it)
Verify it works correctly
Give to agent
If agent fails now, you know it's the agent logic, not the tool

How Tool Calling Actually Works

Understanding the execution loop helped me design better tools.

Here's what happens when an agent runs:

1. User: "I can't log in to my account"

2. Agent thinks: 
   "I need to help with login. Let me check their account status."

3. Agent calls: check_account_status(user_id)

4. Tool returns: {status: "locked", reason: "too many failed attempts"}

5. Agent thinks:
   "Account is locked. I should unlock it."

6. Agent calls: unlock_account(user_id)

7. Tool returns: {success: true}

8. Agent responds:
   "I've unlocked your account. Please try logging in now."

Key insight: The agent decides which tools to use and when. You're not programming IF/THEN logic. The agent figures out the sequence based on the situation.

This is both powerful and a bit mind-bending if you're used to traditional programming. It's more like declarative programming—you declare what tools are available, and the system figures out how to use them.

Practical Patterns I'm Finding Useful

As I build more agents, I'm noticing certain tool patterns that work well:

Data Retrieval Tools

get_customer_info(id)
search_database(query)
fetch_order_history(customer_id)

Action Tools

send_email(to, subject, body)
create_ticket(issue)
update_record(id, data)

Calculation Tools

calculate_total(items)
convert_currency(amount, from, to)
analyze_sentiment(text)

External API Tools

get_weather(city)
search_web(query)
translate_text(text, target_lang)

I'm starting to build a personal library of these patterns. When I need a new agent, I can quickly compose tools from these categories.

Applying This to Frontend Development

As an Angular developer, I see parallels to how we structure applications:

Bad Angular architecture:

// One giant service that does everything
class GodService {
  handleEverything() { /* thousands of lines */ }
}

Good Angular architecture:

// Focused services with clear responsibilities
class AuthService { }
class UserService { }
class OrderService { }
class NotificationService { }

The same principle applies to AI agent tools. Break things down into focused, composable pieces.

When I'm building AI features into Angular applications now (like I did with my Angular AI Chat Kit), I think about the AI's tools the same way I think about Angular services—each should have a clear, single responsibility.

The Emergent Behavior Surprise

Here's something that surprised me: with good tool design, agents start doing creative things you didn't explicitly program.

For example, with a meeting scheduler agent that has these tools:

get_calendar(user_id)
find_free_slots(calendar1, calendar2)
create_meeting(attendees, time, duration)
send_notification(user_id, message)

When someone asks "Schedule a meeting with Sarah next week", the agent figures out on its own:

Get both calendars
Find overlapping free time
Create the meeting
Send confirmation

You never programmed that exact sequence. The agent reasoned through it based on the tools available.

This is the "magic" of good tool design—the agent becomes more capable than the sum of its tools.

What I'm Building Next

I'm currently working on integrating AI agents into Angular applications, specifically for features in my Angular AI Chat Kit.

The lessons from tool design are directly applicable:

Each API endpoint becomes a potential tool
Frontend state management needs to work with agent actions
User interactions trigger agent workflows

I'm also exploring how to make AI-assisted development workflows more efficient by treating development tasks as agent operations—code review, refactoring, documentation generation, each with specific tools.

Key Takeaways

If you're building AI agents, remember these points:

Tool quality determines agent quality - spend time on tool design
Ask "What would a human do?" - then make each step a tool
Start with 3-5 tools - only add more when needed
One tool = one job - let the agent chain them
Write detailed descriptions - the agent reads them
Test tools independently - before giving to agent

The framework is simple, but it works. I wish I'd known this before spending days debugging my first agent.

What's Next for You?

If you're building AI agents or adding AI features to your applications, try this framework with your next project.

Start small. Build 3-5 focused tools. See what the agent can do.

Then iterate. Add tools as you discover gaps in functionality.

I'm still early in my AI engineering journey, but this framework has already made a huge difference in how I approach agent development. It's one of those concepts that seems obvious in hindsight but isn't intuitive when you're starting out.

What are you building with AI agents? I'd love to hear about your experiences—especially if you've discovered other patterns that work well.

Make Your App Feel Instant with Optimistic Updates

hassantayyab — Tue, 03 Feb 2026 21:35:12 +0000

You know that tiny moment of friction when you click "like" on a post and have to wait for the heart to fill in? That split second where you're not sure if it worked? That's not just annoying—it's breaking the trust between your user and your interface.

I learned this the hard way while building an AI chat feature. Users would send a message, and there'd be this awkward pause before their message appeared in the chat. Even though the API was responding in 200 milliseconds, it felt sluggish. People would click send again, thinking it didn't work. The feature was fast, but it didn't feel fast.

That's when I discovered optimistic updates, and honestly, it changed how I think about building interfaces.

What Actually Happens When You Wait

Most apps work like this: user does something, you show a spinner, wait for the server to confirm, then update the UI. It's safe. It's predictable. It's also what makes your app feel like it's running through molasses.

Think about it from the user's perspective. They just told your app to do something. They clicked the button. They made the decision. Why should they wait for permission from a server somewhere to see the result of their own action?

The thing is, most actions succeed. Like, 99% of the time, that API call is going to return a success. So we're making users wait every single time for the 1% chance something goes wrong.

The Optimistic Approach

Here's the mindset shift: assume the action will succeed, update the UI immediately, and deal with failures if they happen.

When someone sends a message in a chat, show it in the chat right away. Make the API call in the background. If it fails (which it rarely does), you handle it gracefully. Maybe you show a little "failed to send" indicator. Maybe you let them retry. But you don't make them wait when everything is working fine.

I rebuilt that AI chat feature with this pattern. Message appears instantly when you hit send. The typing animation from the AI starts right away. Behind the scenes, the message is being saved to the database, but the user doesn't need to wait for that confirmation to feel like their action worked.

The difference was night and day. People stopped double-clicking send. The feature felt responsive and alive instead of sluggish and disconnected.

The Delete Story

Another place this really hit home was building a simple todo list feature. You know the drill—user clicks delete on an item, you show a loading state, call the API, then remove the item from the list.

I switched it to optimistic updates. Click delete, item disappears immediately. API call happens quietly in the background. If it fails, the item reappears with a small toast notification saying "couldn't delete, try again."

What surprised me was how much faster the whole interaction felt, even though the actual API timing hadn't changed at all. The perceived performance went through the roof just by not making people wait to see the result of their own decision.

The Mistake Everyone Makes

Here's what I got wrong at first, and I see this in a lot of implementations: I forgot to actually handle the error case properly.

It's easy to write the happy path. Update the UI, fire the API call, done. But what happens when that call fails? If you don't store the previous state before making your optimistic update, you can't roll back. Your UI is now lying to the user, showing them something that didn't actually happen on the server.

The pattern needs three things to work. First, you store the current state before making any changes. Second, you update the UI optimistically. Third, if the API call fails, you restore that previous state and tell the user what happened.

Here's what that looks like in practice:

function deleteItem(itemId) {
  // Step 1: Store what we have now
  const previousItems = [...items];

  // Step 2: Update UI immediately (optimistic)
  items = items.filter(item => item.id !== itemId);

  // Step 3: Sync with server
  api.deleteItem(itemId)
    .then(() => {
      // Success! Nothing to do, UI already updated
    })
    .catch(() => {
      // Failure! Restore previous state
      items = previousItems;
      showToast('Failed to delete item. Please try again.');
    });
}

The beautiful thing about this pattern is that it works in any framework. React, Vue, Angular, Svelte—doesn't matter. The concept is the same. Update immediately, sync later, rollback on failure.

When Not to Use This

Now, before you go making every single action in your app optimistic, let's talk about when this is a bad idea.

Financial transactions? Don't be optimistic. You really do need to wait for confirmation before telling someone their payment went through. Deleting important data permanently? Maybe show a confirmation dialog first, then be optimistic about the actual deletion.

The rule I follow is this: if the action is easily reversible and failure is rare, be optimistic. If the action has serious consequences or you need guaranteed confirmation, wait for the server.

A like button? Perfect for optimistic updates. Processing a $10,000 wire transfer? Maybe not.

Why This Matters More Than You Think

Here's the thing about user experience that took me a while to understand. Users don't consciously notice when things are fast. They notice when things feel slow. That 300 millisecond wait for a server response? Your users might not be able to measure it, but they feel it.

Apps that use optimistic updates feel native. They feel responsive. They feel like the interface is actually listening to you instead of asking permission from a server every time you breathe.

Instagram doesn't make you wait to see your like. Twitter doesn't make you wait to see your retweet. Gmail doesn't make you wait when you archive an email (but they do give you that genius undo option in case you change your mind).

These apps feel fast because they trust that your actions will succeed and deal with failures as the exception, not the rule.

The Implementation Reality

When I first started using this pattern, I thought I'd need to rewrite huge chunks of my apps. Turns out, you can adopt it incrementally. Pick one feature that feels slow. Add optimistic updates to just that feature. See how it feels.

Start with something low-stakes like a like button or a simple toggle. Get comfortable with the pattern of store-update-sync-rollback. Once you've done it a few times, it becomes second nature.

The code isn't complicated. The mindset shift is what matters. You're moving from "ask permission, then act" to "act, then sync."

Wrapping Up

Optimistic updates aren't some advanced technique reserved for big tech companies with massive engineering teams. It's a simple pattern that makes a massive difference in how your app feels to use.

The next time you're building a feature and you catch yourself adding a loading spinner, ask yourself: does the user really need to wait for this? Can I show them the result immediately and sync in the background?

More often than not, the answer is yes. And your users will thank you for it, even if they don't consciously realize why your app just feels better to use.

If you found this helpful, I share more practical frontend tips and real experiences from building with modern frameworks over on LinkedIn. Would love to connect and hear about your own experiences with optimistic updates.

The Complete Guide to Prompt Engineering for Angular Developers

hassantayyab — Sun, 18 Jan 2026 11:09:57 +0000

If you've ever pasted code into an AI and gotten back something that looks like it was written in 2018, you're not alone. I spent months fighting AI outputs before realizing the problem wasn't the tool—it was how I was using it.

This guide covers everything I've learned about writing prompts that actually work for Angular development. Not generic tips you'll forget tomorrow, but practical techniques you can use on your next component.

Understanding How LLMs Actually Work

Before we dive into techniques, you need a mental model of what's happening under the hood.

An LLM is essentially a next-word prediction machine. You give it text, it predicts what should come next, then uses what it just wrote to predict the next bit, and so on. Your entire job as a prompt engineer is to set up the context so that the "next words" it predicts are the ones you actually want.

When you write "create an Angular component", the model draws from everything it's seen—Angular 2 through 17, good code and bad code, tutorials and production apps. Without more context, you get an average of all of that. Usually not what you want.

The key insight: prompt engineering is iterative. You write a prompt, test it, tweak the wording, add constraints, maybe include examples, and repeat until the results are reliable. There's no magic formula that works perfectly the first time.

The Settings That Change Everything

Before we get to prompt techniques, let's talk about the knobs you can adjust.

Temperature

Temperature controls randomness in the output.

Low temperature (0 to 0.3): More consistent, factual, repeatable. Use this for debugging, refactors, and production code where you want the same answer every time.
High temperature (0.7 to 1.0): More variety and creativity, but also more risk of weird outputs. Use this when brainstorming component ideas or exploring architecture options.

For 90% of Angular work, I keep temperature low. When I'm stuck and want the AI to suggest approaches I haven't considered, I bump it up.

Token Limits

More tokens means more output, but also more cost and sometimes more rambling. Here's the thing though—setting a low token limit doesn't magically make text concise. It just cuts it off mid-sentence.

If you want brief output, you need to ask for brevity in the prompt itself: "Explain this in 3 sentences" or "Show only the changed lines."

Top-K and Top-P

These control how "wide" the model looks when picking the next word.

Lower values = safer, more predictable outputs
Higher values = more diverse, sometimes surprising outputs

For most Angular work, the defaults are fine. But if you're getting repetitive outputs, bumping these up slightly can help.

The Prompt Skeleton I Use Daily

After trying dozens of approaches, I settled on this structure:

Role: You are an Angular [version] engineer.
Task: [Clear action verb] - create/debug/refactor/explain
Context: [Architecture, constraints, what already exists]
Output format: [How you want the answer structured]
Acceptance criteria: [What "done" looks like]
Edge cases: [Error handling, loading states, accessibility, tests]

Here's a real example:

You are an Angular 17 engineer.

Task: Create a notification toast component.

Context: 
- Standalone component with inline template
- Signals for state management
- TailwindCSS for styling
- Multiple toasts can stack vertically
- Auto-dismiss after configurable duration

Output: Single component file with TypeScript and inline template.

Acceptance criteria:
- Animations on enter and exit
- Click to dismiss manually
- Accessible (role="alert", aria-live="polite")
- Typed input for toast config (message, type, duration)

Edge cases:
- Handle rapid successive toasts
- Pause auto-dismiss on hover

This takes 30 seconds to write and saves 30 minutes of cleanup.

Core Prompting Techniques

Zero-Shot: Just Tell It What to Do

The simplest approach. You describe the task without any examples.

Write an Angular pipe that formats a number as currency, 
handling null values gracefully. Return only the pipe code.

This works when the task is straightforward and common. The AI has seen thousands of currency pipes and knows the pattern.

Use zero-shot for:

Simple utilities and pipes
Standard CRUD operations
Well-documented patterns

Few-Shot: Teach By Showing

When zero-shot gives inconsistent results, show the AI examples of what you want.

This is probably my most-used technique. Instead of describing your coding conventions, you demonstrate them:

Here's how we write components in this codebase:

import { Component, input, computed } from '@angular/core';

@Component({
  selector: 'app-user-avatar',
  standalone: true,
  template: `
    <div class="rounded-full bg-slate-200 flex items-center justify-center"
         [class]="sizeClasses()">
      @if (imageUrl()) {
        <img [src]="imageUrl()" [alt]="name()" class="rounded-full" />
      } @else {
        <span class="font-medium text-slate-600">{{ initials() }}</span>
      }
    </div>
  `
})
export class UserAvatarComponent {
  name = input.required<string>();
  imageUrl = input<string>();
  size = input<'sm' | 'md' | 'lg'>('md');

  initials = computed(() => 
    this.name().split(' ').map(n => n[0]).join('').toUpperCase()
  );

  sizeClasses = computed(() => ({
    'sm': 'w-8 h-8 text-xs',
    'md': 'w-10 h-10 text-sm', 
    'lg': 'w-14 h-14 text-base'
  })[this.size()]);
}

Now create a status-badge component following the exact same patterns:
- Same import style
- Same signal inputs with input()
- Same computed() for derived state
- Same inline template approach
- Same Tailwind conventions

The badge shows online/offline/away status with appropriate colors.

The AI sees your conventions—signal inputs, computed properties, inline templates, @if syntax, Tailwind classes—and mirrors them exactly.

Rule of thumb: 1 to 3 examples for simple patterns, 3 to 5 for complex ones. More examples means more input tokens and cost, so don't overdo it.

System, Role, and Context Prompting

Think of these as three layers of guidance:

System prompting sets the rules. What the model must do, how to format answers, constraints that always apply.

You are an Angular code assistant. 
Always use standalone components.
Never suggest NgModules.
Format code with 2-space indentation.
Include TypeScript types for all parameters.

Role prompting sets the voice and expertise level.

You are a senior Angular engineer who specializes in 
performance optimization and has deep experience with 
large-scale enterprise applications.

Context prompting provides the specific background for this request.

Context: This is for a dashboard application. We use 
Angular 17 with signals, TailwindCSS, and a REST API. 
The team prefers composition over inheritance.

You can combine all three:

[System] You are an Angular code assistant. Use standalone components only.

[Role] Act as a senior engineer doing a code review.

[Context] This component handles user authentication in a 
healthcare app with strict HIPAA requirements.

[Task] Review this login component for security issues.

Advanced Techniques for Harder Problems

Chain of Thought: Make It Think Step by Step

For problems that require reasoning—debugging, complex refactors, architectural decisions—asking for step-by-step thinking dramatically improves accuracy.

Without chain of thought, the AI pattern-matches to the first solution it recognizes. With it, the AI actually works through the problem.

I'm getting this error:

ERROR NullInjectorError: No provider for UserService!

Here's my code:

// user.service.ts
@Injectable()
export class UserService {
  private http = inject(HttpClient);
  // ...
}

// user-list.component.ts
@Component({
  selector: 'app-user-list',
  standalone: true,
  imports: [CommonModule],
  template: `...`
})
export class UserListComponent {
  private userService = inject(UserService);
}

Before giving me a fix, think through this step by step:
1. What does this error message mean?
2. What are the possible causes in a standalone component setup?
3. Which cause applies to my specific code?
4. What's the fix?

This catches edge cases that quick answers miss. The AI might realize "wait, the service is @Injectable() but not providedIn: 'root'" which it wouldn't have noticed if it just jumped to a solution.

Step-Back Prompting: Zoom Out, Then Zoom In

For architectural decisions or when you're stuck, first ask a broader question to activate relevant knowledge, then apply it to your specific situation.

Step 1: What are the key decision factors when choosing between 
these state management approaches in Angular 17?
- Local component state with signals
- Shared service with signals
- NgRx SignalStore
- NgRx full store

Consider: team size, app complexity, debugging needs, 
testing approach, boilerplate tolerance.

Step 2: Given my situation:
- 5 routes sharing user profile, cart, and notification data
- Team of 3 developers, one junior
- No need for time-travel debugging
- We prefer minimal boilerplate
- App will grow to ~50 components over the next year

Which approach fits best? Explain your reasoning.

This gets you a thoughtful recommendation instead of whatever the AI's training data happened to favor.

Self-Consistency: Same Prompt, Multiple Times

For problems where the AI gives different answers each time, run the prompt multiple times with higher temperature and pick the most common answer.

This is useful for:

Classification tasks where the boundary is fuzzy
Code reviews where multiple issues might exist
Debugging when you're not sure which hypothesis is right

I use this less often than other techniques, but it's valuable when you're getting inconsistent results and need confidence.

Practical Angular Scenarios

RxJS Prompts That Actually Work

RxJS is where generic prompts fail hardest. "Help me with observables" gives you textbook examples that don't match your data flow.

Be specific about your streams:

I have these observables in my component:

1. this.route.params - emits { userId: string } on navigation
2. this.searchControl.valueChanges - string, already debounced 300ms
3. this.refresh$ - Subject<void> triggered on refresh button click

Desired behavior:
- Fetch user profile when userId changes
- Cancel previous user request if userId changes before it completes
- Fetch search results when search query changes OR refresh$ emits
- Cancel previous search if new search starts
- Track loading state separately for user vs search
- Error handling: 404 → show "Not found", other errors → show "Try again"

Constraints:
- Use switchMap for automatic cancellation
- Prefer declarative streams, minimize subscribe() calls
- Component uses takeUntilDestroyed() for cleanup
- All responses are typed

Show me the component class with the stream setup.

Now the AI can construct the actual pipeline instead of guessing.

Reactive Forms with Real Requirements

Build a reactive form for user registration.

Fields:
- email (required, valid email format)
- password (required, min 12 chars, must include number and symbol)
- confirmPassword (must match password)
- acceptTerms (required, must be true)

Behavior:
- Show validation errors only after field is touched
- Disable submit until form is valid
- Password strength indicator (weak/medium/strong)

Accessibility:
- Proper labels linked to inputs
- Error messages with aria-describedby
- Focus management on validation failure

Output: Component class and template. Use Angular 17 signal-based approach 
where beneficial.

Routing and Guards

Create a route configuration for this app structure:

- /login (public)
- /register (public)  
- /app (protected, requires auth)
  - /app/dashboard (default child)
  - /app/users (lazy loaded)
  - /app/users/:id (user detail)
  - /app/settings (lazy loaded)

Requirements:
- Auth guard redirects to /login if not authenticated
- Already authenticated users visiting /login redirect to /app
- Lazy load the users and settings features
- Use standalone routing APIs

Output:
1. app.routes.ts
2. Auth guard
3. Brief explanation of the navigation flow

Component Generation with Consistency

I need to generate a complete feature module for "Products".

Routes: /products (list), /products/new (create), /products/:id (detail/edit)
API endpoints: GET /api/products, POST /api/products, 
GET /api/products/:id, PUT /api/products/:id, DELETE /api/products/:id

Follow this existing component as the pattern:
[paste your best existing feature component]

Generate:
1. products.routes.ts
2. product-list.component.ts (with pagination, search filter)
3. product-detail.component.ts (view/edit mode toggle)
4. product-form.component.ts (reusable for create/edit)
5. products.service.ts
6. product.model.ts

Show the file tree first, then each file with clear separation.

Structured Output: Getting JSON Back

When you need data extraction or structured responses, asking for JSON reduces hallucination and makes parsing easy.

Analyze this Angular component and return a JSON assessment:

[paste component code]

Return valid JSON only with this structure:
{
  "complexity": "low" | "medium" | "high",
  "issues": [
    {
      "type": "performance" | "accessibility" | "maintainability",
      "description": "...",
      "suggestion": "...",
      "priority": "low" | "medium" | "high"
    }
  ],
  "positives": ["...", "..."],
  "overallScore": 1-10
}

One warning: if you're hitting token limits, JSON can get cut off mid-structure. Either increase limits or ask for more concise output.

Best Practices Summary

Provide examples. Few-shot beats lengthy explanations almost every time.

Keep prompts clear. If it confuses you, it'll confuse the model. Rewrite until it's simple.

Be specific about output. Don't say "write a component." Say what kind, how long, what patterns to follow, what to include.

Prefer instructions over constraints. "Include only X, Y, Z" works better than "Don't do A, don't do B, don't do C." But constraints are still useful for hard rules.

Control length deliberately. Use token limits AND explicit instructions ("explain in 3 sentences").

Use variables for reusable prompts. If you're generating similar code often, template it: "Create a {entityName} service following the pattern above."

Experiment with phrasing. Questions, statements, and commands can all give different results. Try variations.

Mix your examples. For classification tasks, don't put all the positive examples first. Interleave them so the model learns the concept, not the order.

Document what works. Keep a file of prompts that give good results. Future you will thank past you.

Re-test after model updates. When the AI provider releases a new version, your prompts might need adjustment.

The Emergency Prompt

When you're completely stuck, use this:

I'm stuck. Here's everything:

Goal: [what should happen]
Current code: [relevant files]
Actual behavior: [what's happening vs expected]
Error message: [if any]
What I've tried: [your attempts so far]
Constraints: [Angular version, libraries, patterns required]

Please:
1. Restate the problem in your own words so I know you understand
2. List 3 possible causes
3. Pick the most likely and explain why
4. Show the fix with minimal changes
5. Tell me how to verify it worked

This forces the AI to engage with your specific situation instead of pattern-matching to a generic solution.

Final Thoughts

Prompt engineering isn't about memorizing magic phrases. It's about recognizing that the AI is context-blind and your job is to provide that context.

Every prompt is a knowledge transfer. You're teaching the AI enough about your project, your conventions, and your specific problem that its predictions land on the patterns you actually want.

Get good at that transfer, and AI becomes a genuine force multiplier. Skip it, and you'll spend more time fixing AI output than you would have spent writing the code yourself.

The techniques in this guide work. But they work best when you experiment, iterate, and build your own library of prompts that fit your specific workflow.

Start with the prompt skeleton. Add few-shot examples from your own codebase. Use chain of thought when debugging. Be embarrassingly specific with RxJS.

Your future self—and your deadline—will thank you.

What prompting techniques have worked for your Angular projects? I'm always looking to learn from others. Connect with me on LinkedIn or X.

Agent Skills: How to Make AI Write Modern Angular Code

hassantayyab — Fri, 16 Jan 2026 23:15:31 +0000

Agent Skills: Teaching Your AI Coding Assistant to Write Better Angular Code

If you've used AI coding assistants like Claude Code, Cursor, or GitHub Copilot, you've probably noticed something frustrating: they often generate outdated code. Ask for an Angular component, and you might get constructor-based dependency injection instead of the modern inject() function, or *ngIf instead of the new @if control flow. This happens because these AI models were trained on code from a specific point in time, and frameworks like Angular evolve rapidly.

Agent Skills solve this problem. They're simple instruction files that teach AI assistants how to write code the way you want it written.

What exactly is an Agent Skill?

Think of an Agent Skill like a recipe card you hand to a chef. The chef (the AI) already knows how to cook, but the recipe card tells them exactly how you want your dish prepared—which ingredients to use, which to avoid, and what the final result should look like.

In technical terms, a skill is just a markdown file named SKILL.md that contains instructions for the AI. When you ask the AI to do something that matches a skill's purpose, it reads those instructions and follows them.

Here's the simplest possible skill:

---
name: my-angular-skill
description: "Use when creating Angular components or services."
---

# Angular Rules

Always use the `inject()` function for dependency injection.
Never use constructor injection.

That's it. When the AI recognizes you're working on Angular code, it reads this file and follows the rules.

Why do Angular developers need skills?

Angular has changed dramatically in recent versions. The patterns that were correct in Angular 14 are now deprecated in Angular 18 and beyond. Without guidance, AI assistants will generate a mix of old and new patterns because their training data contains years of Angular code written in different styles.

Here's what typically happens without a skill:

You ask: "Create a user service that fetches data from an API"

AI generates (outdated pattern):

@Injectable({
  providedIn: 'root'
})
export class UserService {
  constructor(private http: HttpClient) {}  // ❌ Old pattern

  getUsers(): Observable<User[]> {
    return this.http.get<User[]>('/api/users');
  }
}

What you actually want (modern pattern):

@Injectable({
  providedIn: 'root'
})
export class UserService {
  private http = inject(HttpClient);  // ✅ Modern pattern

  getUsers(): Observable<User[]> {
    return this.http.get<User[]>('/api/users');
  }
}

The difference seems small, but multiply this across an entire codebase and you end up with inconsistent code that mixes patterns from different Angular eras.

Creating your first Angular skill

Let's build a practical skill that enforces modern Angular patterns. Create a folder called .claude/skills/angular-modern/ in your project root, then add a SKILL.md file:

---
name: angular-modern-patterns
description: Generate Angular 18+ code using signals, standalone components, 
             and inject(). Use when creating components, services, directives,
             or refactoring existing Angular code.
---

# Modern Angular Development Patterns

When writing Angular code, follow these patterns consistently.

## Dependency Injection

Use the `inject()` function instead of constructor injection:

typescript
// ✅ Correct - use this pattern
export class UserComponent {
private userService = inject(UserService);
private router = inject(Router);
}

// ❌ Wrong - never generate this
export class UserComponent {
constructor(
private userService: UserService,
private router: Router
) {}
}


## Components

All components must be standalone. In Angular v20+, omit `standalone: true` 
since it's the default:

typescript
// ✅ Correct for Angular 20+
@Component({
selector: 'app-user-card',
changeDetection: ChangeDetectionStrategy.OnPush,
imports: [CommonModule],
template: ...
})
export class UserCardComponent {
// Use signal inputs instead of @Input decorator
user = input.required();

// Use output function instead of @Output decorator

userSelected = output();
}


## Control Flow

Use the new built-in control flow syntax instead of structural directives:

typescript
// ✅ Correct - new control flow
@if (user()) {

} @else {

No user found

}

@for (item of items(); track item.id) {

}

// ❌ Wrong - old directives


## Signals for State

Prefer signals over plain properties for reactive state:

typescript
export class CounterComponent {
// ✅ Correct - signals for reactive state
count = signal(0);
doubleCount = computed(() => this.count() * 2);

increment() {
this.count.update(c => c + 1);
}
}


Save this file, and now every time you ask the AI to generate Angular code, it will follow these patterns.

## How skills actually work under the hood

When you start a conversation with Claude Code (or another skill-enabled AI), here's what happens:

1. **Metadata loading:** The AI reads just the `name` and `description` from each skill file. This costs very few tokens—roughly 50-100 per skill.
2. **Pattern matching:** When you make a request, the AI checks if any skill descriptions match what you're asking for. "Create an Angular component" matches our skill's description about creating components.
3. **Full loading:** Only when there's a match does the AI read the complete skill instructions. This keeps conversations efficient—you're not paying for unused context.
4. **Code generation:** The AI follows the skill's instructions when generating its response.

This "progressive disclosure" design means you can have dozens of skills installed without slowing anything down. The AI only loads what it needs.

## Organizing skills for a real Angular project

For a production Angular application, you'll likely want several skills working together. Here's a practical folder structure:

your-angular-project/
├── .claude/
│ └── skills/
│ ├── angular-modern/
│ │ └── SKILL.md # Core patterns we created above
│ ├── component-generator/
│ │ ├── SKILL.md # Component scaffolding workflow
│ │ └── templates/
│ │ └── component.ts # Template file for reference
│ ├── ngrx-patterns/
│ │ └── SKILL.md # State management conventions
│ └── testing/
│ └── SKILL.md # Jest and TestBed patterns
├── CLAUDE.md # Project-level context (always loaded)
└── src/
└── ...


The `CLAUDE.md` file at your project root is special—it loads automatically for every conversation and should contain high-level project context:

markdown

Project: Customer Portal

Tech Stack

Angular 20
NgRx Signals for state management
Angular Material with custom theme
Jest for testing

Conventions

All components use OnPush change detection
Feature modules organized by domain (users, orders, products)
API calls go through services, never directly in components

Commands

npm run test - Run unit tests
npm run e2e - Run Playwright tests
npm run lint - Check code style


## A complete example: Component generation workflow

Let's create a more advanced skill that handles a common workflow—generating a complete Angular feature with a component, service, and tests.

Create `.claude/skills/feature-generator/SKILL.md`:

markdown

name: angular-feature-generator
description: Generate complete Angular features including component, service,
and tests. Use when asked to create a new feature, page, or

module for the application.

Angular Feature Generation

When asked to create a new feature, generate these files in order:

1. Service (data layer first)

// feature-name.service.ts
import { inject, Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';

@Injectable({ providedIn: 'root' })
export class FeatureNameService {
  private http = inject(HttpClient);

  // Methods return Observables for flexibility
  // Components convert to signals as needed
}

2. Component (presentation layer)

// feature-name.component.ts
import { ChangeDetectionStrategy, Component, inject } from '@angular/core';
import { toSignal } from '@angular/core/rxjs-interop';

@Component({
  selector: 'app-feature-name',
  changeDetection: ChangeDetectionStrategy.OnPush,
  imports: [],  // Add required imports
  template: ``
})
export class FeatureNameComponent {
  private featureService = inject(FeatureNameService);

  // Convert service observables to signals for template
  // data = toSignal(this.featureService.getData());
}

3. Test file

// feature-name.component.spec.ts
import { ComponentFixture, TestBed } from '@angular/core/testing';
import { provideHttpClientTesting } from '@angular/common/http/testing';

describe('FeatureNameComponent', () => {
  let component: FeatureNameComponent;
  let fixture: ComponentFixture<FeatureNameComponent>;

  beforeEach(async () => {
    await TestBed.configureTestingModule({
      imports: [FeatureNameComponent],
      providers: [provideHttpClientTesting()]
    }).compileComponents();

    fixture = TestBed.createComponent(FeatureNameComponent);
    component = fixture.componentInstance;
  });

  it('should create', () => {
    expect(component).toBeTruthy();
  });
});

File organization

Place generated files in the appropriate feature folder:

src/app/features/feature-name/
├── feature-name.component.ts
├── feature-name.component.spec.ts
├── feature-name.service.ts
└── feature-name.service.spec.ts

Now when you ask "Create a user profile feature," the AI knows exactly what files to generate, in what order, and following which patterns.

Skills versus other AI extension methods

You might wonder how skills compare to other ways of extending AI assistants, like MCP servers or function calling. They serve different purposes and work well together:

Skills teach the AI how to approach tasks. They provide patterns, conventions, and domain knowledge. Skills are static instruction files that get loaded into the conversation.

MCP (Model Context Protocol) connects the AI to external systems. An MCP server might give the AI access to your Figma designs, your GitHub repository, or a live database. MCP provides dynamic, real-time data.

Function calling lets the AI execute specific actions, like running a calculation or calling an API endpoint.

For Angular development, a practical setup might combine all three:

Skill: Teaches the AI your component patterns and coding standards
MCP server: Connects to Figma so the AI can see your designs while generating components
Function: Runs ng generate commands to actually create the files

Getting started today

Here's a practical path to start using skills in your Angular projects:

Step 1: Create the .claude/skills/ folder in your project root.

Step 2: Add a basic Angular patterns skill using the example from this post.

Step 3: Create a CLAUDE.md file documenting your project's tech stack and conventions.

Step 4: Test it by asking the AI to generate a component and verify it follows your patterns.

Step 5: Iterate. When the AI generates something wrong, add a rule to your skill to prevent it next time.

The Angular team has also published official AI configuration that you can generate with ng new in Angular CLI v20.2+. This gives you a solid starting point that you can customize for your team's specific conventions.

Conclusion

Agent Skills transform AI coding assistants from generic code generators into specialized development partners that understand your project's conventions. For Angular developers dealing with rapidly evolving framework patterns, skills ensure the AI generates modern, consistent code instead of a mixture of deprecated approaches.

The investment is minimal—a few markdown files—but the payoff is significant. Instead of constantly correcting AI-generated code, you teach the AI once and it follows your patterns consistently. As your conventions evolve, you update the skill files and every future interaction reflects those changes.

Start small with a single skill covering your most important patterns, and expand from there as you identify more opportunities for guidance.

How I Get Better UI from Claude: Research First, Build Second

hassantayyab — Mon, 12 Jan 2026 09:39:11 +0000

Most AI-generated UIs look the same. You know the vibe — generic gradients, overused shadows, that "I was clearly made by AI" aesthetic you see in every vibe-coded app.

I found a simple workflow that fixes this. It takes an extra 5 minutes but the output looks like it came from an actual designer.

The Problem with "Build Me a Component"

When you ask Claude to build a UI component directly, it pulls from its training data. That means you get a mix of patterns it's seen — some good, some dated, some just weird.

I was building a typing indicator for my Angular AI UI component library. You know, those animated dots that show when the AI is thinking.

My first instinct was to just ask Claude to build it.

The result? Functional, but forgettable. Three bouncing dots that looked like every tutorial example from 2019.

The Fix: Make Claude a Design Researcher First

Instead of jumping straight to code, I added one step.

I asked Claude Code (using Opus 4.5 in research mode) to research the problem first:

Research how typing indicators are used in modern web apps, 
especially AI chats like ChatGPT, Claude, and Gemini. 
Look at design patterns, animations, and how they signal 
different states.

Giving it specific examples of well-designed apps makes a huge difference. Claude now has a reference point for what "good" looks like in this specific context.

The research came back with insights I wouldn't have thought to look for — how ChatGPT uses a pulsing effect vs Claude's shimmer animation, how Gemini handles the transition between thinking and responding, accessibility considerations for motion-sensitive users.

Then Feed the Research Back

Here's the key part.

I take the entire research document and paste it into a new conversation. Then I ask Claude to build the component with this context.

Based on this research, build me a typing indicator component 
for Angular that follows modern AI chat patterns. Make it 
polished and professional.

The difference is night and day.

Instead of generic bouncing dots, I got a component with:

Subtle animation timing that felt natural
Smooth state transitions
Design choices that actually made sense for an AI chat context
Details I wouldn't have specified myself

It looked like something that belongs in a production app, not a weekend hackathon.

Why This Works

Claude is good at following patterns. The problem is which patterns it follows.

When you ask it to build something from scratch, it averages across everything it knows. You get median design quality — safe, boring, forgettable.

When you give it focused research on how the best apps solve this exact problem, it has a much tighter reference point. It's not guessing anymore. It's applying specific patterns from apps you actually want to emulate.

Think of it like this: asking Claude to "design a button" vs asking it to "design a button like Stripe's dashboard" gives you completely different results. Research mode just automates finding those references.

My Workflow Now

For any UI component that needs to look good:

Step 1: Ask Claude (Opus 4.5, research mode) to research the problem

Research how [component] is implemented in modern apps like 
[2-3 specific well-designed examples]. Focus on design patterns, 
animations, and UX details.

Step 2: Review the research (sometimes it surfaces things I didn't know to ask for)

Step 3: Paste the full research document into a new conversation

Step 4: Ask Claude to build with that context

The extra 5 minutes of research saves hours of tweaking generic output into something that actually looks professional.

When I Use This

I don't do this for every component. Simple stuff like form fields or basic layouts — Claude handles those fine without research.

But for anything that needs to feel polished:

Complex interactive components
Animations and micro-interactions
Components where "feel" matters (chat UIs, dashboards, onboarding flows)
Anything users will see repeatedly

That's when research-first pays off.

The Bigger Point

AI-assisted development isn't just about speed. It's about using AI at the right step.

Most people use Claude as a code generator. But it's also a researcher, a design consultant, and a pattern library — if you prompt it that way.

The typing indicator I built is now one of the best-looking components in my library. Not because I'm a designer, but because I let Claude do the design research before writing a single line of code.

Try it on your next UI component. Research first, build second.

Links:

Stop Wasting Tokens on UI Bugs: How Chrome DevTools MCP Changed My Debugging Workflow

hassantayyab — Thu, 08 Jan 2026 12:00:54 +0000

Stop Wasting Tokens on UI Bugs: How Chrome DevTools MCP Changed My Debugging Workflow

There's a frustrating pattern when using AI for frontend development.

You describe a UI bug. Claude tries to fix it. Doesn't work. You describe it again, maybe paste some CSS. Still doesn't work. Claude keeps guessing, trying different things, burning through tokens while you watch the same broken UI.

The problem is simple: AI can't fix what it can't see.

I found a solution that cuts my UI debugging time in half. Sometimes more.

The Problem: Blind Debugging

A few weeks ago I had a scrollbar that wouldn't hide. Simple enough, right?

I told Claude to hide the scrollbar on a long list of items. It added overflow: hidden. Didn't work. Tried ::-webkit-scrollbar { display: none }. Still showing. Added scrollbar-width: none. Nothing.

Claude kept trying different CSS combinations. I kept saying "still not working." We went back and forth, wasting tokens, getting nowhere.

The issue? Claude was guessing based on code. It couldn't actually see what was rendering in the browser.

The Fix: Give AI Eyes

Chrome DevTools MCP lets Claude actually interact with your running application. It can:

Launch your app
Open Chrome
Click around and reproduce scenarios
Take screenshots
Inspect the actual rendered DOM
See computed styles

Instead of guessing from code, it can see exactly what you're seeing.

How It Actually Works

Here's what happened when I used Chrome DevTools MCP for that scrollbar issue.

I told Claude: "use the mcp server to fix this"

Then it:

Started my dev server
Opened Chrome to the app
Added items to the list one by one to reproduce the scenario
Took a screenshot of the UI
Saw the actual problem
Fixed it

I didn't click anything. I just watched Chrome doing stuff on its own and made sure not to close it.

The fix was instant once Claude could actually see the rendered output.

Another Example: The Mysterious Textarea Outline

I had a chat input component with a textarea wrapped in a div. There was an outline appearing that I wanted gone.

Claude kept targeting the textarea styles within the component. Didn't work. Tried different border and outline properties. Still there.

When I had it use Chrome DevTools MCP, it could inspect the computed styles and discovered global styles were interfering. The component styles were encapsulated, but something in the global CSS was adding the outline.

Once Claude could see the actual cascade of styles hitting that element, the fix was obvious.

When to Use This

I don't use Chrome DevTools MCP for everything. Most UI work Claude handles fine from code alone.

But when:

Claude keeps trying fixes that don't work
You're going back and forth with no progress
The issue involves visual state that's hard to describe
Something is overriding styles and you can't figure out what

That's when I tell it to use the MCP server. Usually fixes things immediately.

The Workflow

It's surprisingly simple.

My prompt when Claude is stuck:

use the mcp server to fix this

That's it. Claude handles the rest:

Runs the app on a port
Opens Chrome
Navigates to the right page
Interacts with the UI to reproduce the issue
Takes screenshots automatically
Inspects what it needs to
Fixes the problem

Just make sure Chrome is open and don't close it while Claude is working. If you interrupt the process, it breaks.

Setting It Up

Setup is straightforward. I followed the official docs.

For Claude Code / Claude Desktop:

Check the official MCP documentation:
https://modelcontextprotocol.io/docs/develop/connect-local-servers

For Cursor:

Cursor has its own MCP setup process:
https://cursor.com/docs/context/mcp

The Chrome DevTools MCP server:
https://github.com/ChromeDevTools/chrome-devtools-mcp

Follow the steps, connect the server, and you're good to go.

Why This Saves So Much Time

When AI is stuck on a UI bug, it enters a frustrating loop:

Claude tries something
You say it didn't work
Claude tries something else
Still doesn't work
Repeat until you give up or get lucky

Each cycle wastes tokens and time. And often Claude is just guessing because it can't see the actual problem.

Chrome MCP breaks this loop. Instead of guessing, Claude can see. The fix usually comes on the first try.

For me, this saves at least half the debugging time on visual issues. Sometimes way more.

Limitations

It's not magic. A few things to know:

You need to keep Chrome open while it works
It's overkill for simple CSS fixes Claude can handle from code
Sometimes the automation is slower than just fixing it yourself if you already know the issue

Use it when you're stuck, not for everything.

The Takeaway

Most AI coding frustration comes from the AI not being able to see what you're seeing.

For UI bugs, Chrome DevTools MCP fixes this. Claude can actually run your app, look at the screen, inspect elements, and understand what's happening.

Next time you're going back and forth on a visual bug that Claude can't seem to fix, just tell it to use the MCP server.

You'll wonder why you didn't set this up sooner.

Links:

How I 10x'd My Development Speed with Claude Code

hassantayyab — Mon, 05 Jan 2026 10:55:50 +0000

After 6 months of daily Claude Code usage and countless hours of trial and error, I've developed a rule-based system that transformed my AI-assisted development workflow. Here's everything I learned.

The Problem: AI That Forgets Everything

When I first started using Claude Code for building Angular applications, I was excited. An AI that could write code, understand context, and help me build faster? Sign me up.

But reality hit quickly.

The AI kept making the same mistakes. It would use bg-[var(--bg-primary)] instead of proper Tailwind semantic classes. It forgot to implement dark mode. It used constructor injection when I needed inject(). Every. Single. Time.

I found myself copy-pasting the same corrections over and over:

"No, use bg-card not bg-[var(--card)]"
"Remember, we're using Angular v21 signals, not the old syntax"
"Don't forget dark mode support"

I was spending more time correcting the AI than coding.

Sound familiar?

After 6 months of refining my approach, I've built a system that eliminates 90% of these corrections. Claude Code now produces consistent, production-ready code on the first try.

Here's exactly how I did it.

The Solution: A Structured Rule System

The key insight was simple: Claude Code can't remember your preferences between sessions, but it CAN read files at the start of every conversation.

Instead of repeating myself, I created a .claude/ directory with structured rule files that Claude reads automatically. Think of it as giving your AI assistant a comprehensive onboarding document.

My File Structure

.claude/
├── CLAUDE.md                  # Main project memory & quick reference
├── README.md                  # Overview of all rules
├── TODO-TEMPLATE.md           # Template for tracking progress
└── rules/
    ├── accessibility.md       # WCAG AA requirements
    ├── ai-components.md       # AI chat component patterns
    ├── angular-cdk.md         # Angular CDK usage
    ├── angular-v21.md         # Angular v21 best practices
    ├── architecture.md        # Scalability patterns
    ├── component-patterns.md  # Component structure
    ├── styling-architecture.md # CSS variables & theming
    ├── tailwind-v4.md         # Tailwind v4 setup
    ├── todo-management.md     # Progress tracking
    └── typescript.md          # TypeScript patterns

Why split into multiple files?

Easier maintenance - Update one concern without touching others
Better organization - Find rules quickly when you need to reference them
Modular loading - Claude can focus on relevant rules for specific tasks
Cleaner diffs - Git history shows exactly what changed and why

Tip #1: Add Rules When AI Keeps Repeating Mistakes

This is the most valuable habit I've developed: Every time Claude makes the same mistake twice, I add a rule.

Real Example: The Dark Mode Disaster

Claude kept generating Tailwind classes like this:

<!-- What Claude kept generating -->
<div class="bg-white dark:bg-gray-900 text-gray-900 dark:text-gray-100">

Or worse:

<!-- The CSS variable nightmare -->
<div class="bg-[var(--card)] text-[var(--foreground)]">

Both approaches are maintenance nightmares. The first requires duplicating every color with dark: prefixes. The second bypasses Tailwind's utility system entirely.

The fix? I added this to my styling-architecture.md:

## ❌ What NOT to Do

### NEVER Use dark: Prefix

typescript
// ❌ WRONG: dark: prefix
'bg-white dark:bg-gray-900'
'text-gray-900 dark:text-gray-100'

// ✅ CORRECT: Tailwind semantic classes
'bg-card'
'text-foreground'


### NEVER Use var() in Tailwind Classes

typescript
// ❌ WRONG: var() syntax
'bg-[var(--card)]'
'text-[var(--foreground)]'

// ✅ CORRECT: Tailwind semantic classes
'bg-card'
'text-foreground'

Result: Claude now automatically uses the correct pattern. No more corrections needed.

The Rule-Adding Workflow

Notice a repeated mistake - Claude does something wrong twice
Identify the correct pattern - What should it have done?
Write a clear rule - Include both ❌ wrong and ✅ correct examples
Add to the appropriate file - Put it where it logically belongs
Test - Verify Claude follows the rule in your next session

Tip #2: Structure Rules with Clear Examples

Vague rules don't work. "Use proper styling" means nothing. Concrete examples are everything.

Here's my template for effective rules:

## [Pattern Name]

**When to use:** [Clear trigger condition]

### ✅ Correct

typescript
// Good: Explanation of why this is right
const example = 'correct pattern';


### ❌ Wrong

typescript
// Bad: Explanation of why this is wrong
const example = 'incorrect pattern';


### Why This Matters

[1-2 sentences explaining the reasoning]

Real Example from My Component Patterns

## Template Files (CRITICAL)

**ALWAYS use separate HTML template files for components. DO NOT use inline templates.**

### ✅ CORRECT: Use separate template file

typescript
@Component({
selector: 'ai-message-bubble',
templateUrl: './message-bubble.component.html',
changeDetection: ChangeDetectionStrategy.OnPush,
})
export class MessageBubbleComponent {}


### ❌ WRONG: Inline template

typescript
@Component({
selector: 'ai-message-bubble',
template: ...,
})
export class MessageBubbleComponent {}


### Why Separate Templates?

- Better IDE support (syntax highlighting, Emmet)
- Cleaner component files
- Easier code reviews

The explicit ✅ and ❌ markers make it crystal clear what Claude should and shouldn't do.

Tip #3: Create a Central Quick Reference (CLAUDE.md)

While split files are great for detailed rules, you need a central document for critical reminders. My CLAUDE.md serves as the "executive summary."

Key Sections in My CLAUDE.md

1. Project Overview - What we're building

## Project Overview

This is an **Angular v21** component library focused on AI chat interfaces.
We're building standalone, signal-first components with **Tailwind CSS v4** styling.

2. What NOT to Do - The most common mistakes

## Quick Reference: What NOT to Do

- ❌ Don't use NgModules (use standalone components)
- ❌ Don't set `standalone: true` (it's default in Angular v20+)
- ❌ Don't use `@HostBinding`/`@HostListener` (use `host` object)
- ❌ Don't use constructor injection (use `inject()` function)
- ❌ **NEVER use `dark:` prefix** (use semantic classes)
- ❌ **NEVER use `var()` in Tailwind** (use bg-card NOT bg-[var(--card)])

3. Rule File Index - Where to find detailed rules

## Rule Files

| File                      | Purpose                                    |
| ------------------------- | ------------------------------------------ |
| `accessibility.md`        | WCAG, ARIA, keyboard navigation            |
| `angular-v21.md`          | Angular patterns, signals, standalone      |
| `styling-architecture.md` | CSS variables, color system, dark mode     |
| `tailwind-v4.md`          | Tailwind v4 setup, cn() utility            |

4. Code Review Checklist - Quality gates

## Code Review Checklist

Before considering code complete:

**Structure:**
- [ ] Separate HTML template file (not inline)
- [ ] Barrel export (`index.ts`) in folder
- [ ] OnPush change detection
- [ ] ViewEncapsulation.None

**Styling:**
- [ ] CSS only (no SCSS)
- [ ] Tailwind utility classes
- [ ] Dark mode support

Tip #4: Track Progress with TODO Files

For large features or multi-session projects, Claude needs to know what's done and what's left. I use a TODO system that persists across sessions.

The Problem with Large Projects

When building something complex—like a 15-component library—Claude can lose track:

What components are finished?
What's currently being worked on?
What's the priority order?

My Solution: Phase-Based TODOs

I create a TODO.md at the start of each phase:

# Phase 0.2 - Core Chat Components

## ✅ Completed Tasks

- [x] MessageBubble component
- [x] MessageList component
- [x] Dark mode support

## 🔄 In Progress

- [ ] ChatInput component (currently implementing)
- [ ] Auto-resize textarea

## 📋 Pending

- [ ] TypingIndicator component
- [ ] StreamingText component

## 📊 Progress Summary

**Overall Progress:** 40% Complete

The Workflow

Start of phase: Create TODO from template
During work: Mark tasks [x] immediately after completion
End of session: Update progress summary
End of phase: Archive as TODO-Phase-0.2.md, create fresh TODO for next phase

This gives Claude instant context on project status, even in a brand new session.

Tip #5: Use Path-Specific Rules

Some rules only apply to certain files. Claude's rule system supports this with frontmatter:

---
paths: '**/*.component.ts'
---

# Component Structure & Patterns

These rules apply specifically to Angular components...

This tells Claude to apply these rules when working on component files, but not when editing services or utilities.

My Path-Specific Rules

File	Paths	Purpose
`component-patterns.md`	`*/.component.ts`	Component structure
`typescript.md`	`*/.ts`	TypeScript patterns
`accessibility.md`	`*/.{ts,component.ts}`	A11y requirements
`tailwind-v4.md`	`*/.{ts,css}`	Styling rules

Tip #6: Document the "Why," Not Just the "What"

Rules work better when Claude understands the reasoning. Compare these:

Weak rule:

Use `inject()` instead of constructor injection.

Strong rule:

## Service Injection

Use `inject()` function instead of constructor injection.

### Why?

1. Works with standalone components without module context
2. Cleaner syntax with less boilerplate
3. Better tree-shaking support
4. Consistent with Angular's modern patterns

### ✅ Correct

typescript
export class ChatComponent {
private chatService = inject(ChatService);
private config = inject(CHAT_CONFIG);
}


### ❌ Wrong

typescript
export class ChatComponent {
constructor(private chatService: ChatService) {}
}

When Claude understands why a pattern exists, it makes better decisions in edge cases.

Tip #7: Include Technology Version Context

AI models often default to older patterns. Be explicit about versions:

## Critical Context

**CRITICAL: We are using Angular v21 and Tailwind CSS v4**

- Angular v21 is the LATEST version with all modern features
- Tailwind v4 uses NEW @tailwindcss/postcss plugin (not the old tailwindcss plugin)
- AI assistants often make mistakes with latest versions - ALWAYS verify against official docs

This primes Claude to use modern patterns instead of falling back to outdated approaches.

The Results: Before vs. After

Before (Without Rule System)

Constant corrections needed
Inconsistent code patterns
Had to review everything manually
Repeated prompts for same issues
Development felt slow and frustrating

After (With Rule System)

90% fewer corrections
Consistent, production-ready code
Trust the output, verify less
Never repeat the same instruction
Development feels 10x faster

The initial investment of creating these rule files paid for itself within days.

Getting Started: Your First Rule File

Don't try to build my entire system on day one. Start small:

Step 1: Create `.claude/CLAUDE.md`

Add your tech stack and 3-5 "What NOT to Do" items:

# Project Memory

## Tech Stack
- [Your framework] v[version]
- [Your CSS solution]

## What NOT to Do
- ❌ [Most common mistake]
- ❌ [Second most common mistake]
- ❌ [Third most common mistake]

Step 2: Add Rules When Mistakes Repeat

Every time you correct Claude twice for the same thing:

Create a rule file in .claude/rules/
Document the correct pattern with examples
Add a reference in CLAUDE.md

Step 3: Review and Refine Weekly

As your rule files grow:

Split large files into focused topics
Remove rules that are no longer relevant
Add new rules for new patterns

Quick Reference: Rule File Best Practices

Do	Don't
✅ Use concrete examples	❌ Write vague guidelines
✅ Show ❌ wrong AND ✅ correct	❌ Only show correct patterns
✅ Explain the "why"	❌ Give rules without reasoning
✅ Keep files focused (one topic each)	❌ Dump everything in one file
✅ Update rules when AI makes new mistakes	❌ Let outdated rules accumulate
✅ Include version numbers	❌ Assume AI knows your tech stack

Conclusion

Claude Code is an incredible tool, but it's only as good as the context you provide. By building a structured rule system:

You eliminate repetitive corrections - Rules persist across sessions
You get consistent output - Same patterns every time
You build faster - Less review, more shipping
You create institutional knowledge - Rules document your project's standards

The investment in creating rule files pays dividends on every single Claude Code session.

Start with one file. Add rules when mistakes repeat. Split files as they grow.

That's it. That's the system.

Resources

My GitHub - See my projects using this approach
Claude Code Documentation
More articles on my blog

Have questions about this approach? Connect with me on LinkedIn or X/Twitter. I'd love to hear how you're using Claude Code in your workflow.

Keywords: Claude Code, AI-assisted development, Claude Code tips, AI coding assistant, Claude rules, developer productivity, Angular development, Tailwind CSS, AI pair programming, Claude Code workflow, AI coding best practices, development automation

🚀 Prompt Engineering: A Practical Guide for Developers

hassantayyab — Fri, 12 Dec 2025 14:48:49 +0000

Prompt engineering is the practice of designing inputs that reliably guide large language models to produce accurate, structured, and useful outputs.

For developers, prompt engineering is not about clever wording.
It is about controlling ambiguity, constraining solutions, and shaping reasoning so the model produces correct code.

This guide covers:

the core prompt engineering techniques
why they exist
when to use each
how they apply to real coding workflows

What Is Prompt Engineering?

Prompt engineering is the process of turning an intent into a precise instruction that a model can execute correctly.

In software development, this includes:

generating code
refactoring safely
debugging errors
enforcing style and structure
producing machine-readable outputs

You can think of prompts as specifications.
Poor specifications produce poor implementations.

Core Prompt Engineering Techniques

Below are the standard techniques used in prompt engineering, explained in a practical, developer-friendly way.

1. Zero-Shot Prompting

What it is:
Asking the model to perform a task without giving examples.

Example:

Write a function that removes duplicate values from an array while preserving order.

When to use it:

Common tasks
Well-defined problems
Straightforward code generation

Limitations:
Fails when format, style, or edge cases matter.

2. Few-Shot Prompting

What it is:
Providing one or more examples to demonstrate the desired pattern.

Example:

Convert text to snake_case.

Input: "User Name"
Output: "user_name"

Input: "Account ID"
Output: "account_id"

Now convert: "Order Number"

When to use it:

Output formatting matters
Naming conventions
Transformations and parsing
UI or data normalization

Few-shot prompting dramatically improves consistency.

3. Instruction Prompting

What it is:
Explicitly telling the model what to do.

Example:

Refactor this code for readability.
Do not change behavior.
Remove dead code.

Why it matters:
Models follow instructions better than vague descriptions.

4. Contextual Prompting

What it is:
Providing background information that shapes decisions.

Example:

This code is part of a TypeScript backend.
The project enforces immutability and strict typing.
Refactor the function accordingly.

When to use it:

Existing codebases
Architectural constraints
Style enforcement

Context reduces incorrect assumptions.

5. Role Prompting

What it is:
Assigning the model a role to bias decision-making.

Example:

Act as a senior software engineer.
Review the following code and suggest improvements.

Why it works:
Different roles imply different trade-offs (performance, safety, readability).

6. Chain-of-Thought Prompting

What it is:
Asking the model to reason step-by-step before answering.

Example:

Analyze the problem step-by-step.
Explain the root cause.
Then provide the corrected code.

Best used for:

Debugging
Algorithms
Complex logic
Data processing

This improves correctness and transparency.

7. Delimiter Prompting

What it is:
Separating instructions from code or data.

Example:

Analyze the following code and identify bugs:

[code]

Why it matters:
Prevents the model from mixing instructions with content.

8. Structured Output Prompting

What it is:
Explicitly defining the output format.

Example:

Return the result in this format:

{
  "summary": "...",
  "issues": [],
  "fixed_code": "..."
}

Essential for:

Automation
Tooling
Programmatic consumption

9. Constraint Prompting

What it is:
Defining hard rules the solution must follow.

Example:

Rewrite this function with these constraints:
- No external libraries
- Time complexity must be O(n)
- Do not change the public API

Constraints dramatically reduce bad solutions.

10. Error-Driven Prompting

What it is:
Using real error messages as input.

Example:

Here is the exact error and stack trace:
[error]

Explain the root cause and provide a fix.

Why it works:
Error messages anchor the model to reality.

11. Self-Reflection Prompting

What it is:
Asking the model to review and correct itself.

Example:

Review your previous answer.
Identify edge cases and improve the solution.

This often catches subtle bugs.

12. Prompt Chaining

What it is:
Breaking a complex task into multiple prompts.

Example workflow:

Analyze requirements
Define interfaces
Implement logic
Add validation
Write tests

Each step has a focused prompt.

Coding-Focused Use Cases

Code Generation

Write a reusable debounce utility.
Handle edge cases and explain the logic.

Refactoring

Refactor this code for readability without changing behavior.

Debugging

Explain why this function fails for negative values and fix it.

Performance Optimization

Analyze time and space complexity.
Optimize the function and explain the changes.

Documentation

Generate documentation with usage examples for this module.

Best Practices

Be explicit
Provide context when needed
Use examples when format matters
Define output structure
Add constraints early
Use step-by-step reasoning for complex tasks
Break large problems into smaller prompts

Prompt engineering is iterative, like coding.

Prompt Engineering Cheat Sheet

Techniques

Technique	When to Use
Zero-shot	Simple, common tasks
Few-shot	Formatting, transformations
Instruction prompting	Direct actions
Contextual prompting	Codebase consistency
Role prompting	Quality and trade-offs
Chain-of-thought	Logic and debugging
Structured output	Automation
Constraint prompting	Safety and correctness
Error-driven prompting	Debugging
Prompt chaining	Large workflows

Common Coding Tasks

Task	Example Prompt
Generate code	“Write a function that…”
Refactor	“Improve readability without changing behavior.”
Debug	“Explain and fix this error.”
Optimize	“Reduce time complexity.”
Document	“Add documentation with examples.”
Review	“Review and suggest improvements.”

Final Thought

Prompt engineering is not about talking to AI.
It is about designing instructions.

The better your prompts, the more predictable and useful the output becomes.

Treat prompts like code:

structured
constrained
reviewed
improved over time

That’s how AI becomes a real development tool.

A Beginner Friendly Guide to Memoization in NgRx Selectors

hassantayyab — Fri, 28 Nov 2025 12:24:53 +0000

Memoization is a way to speed up functions by caching their results.

If you call a function with the same inputs, instead of recomputing everything again, it just returns the previous result from memory.

Very simplified:

function memoize<T extends (...args: any[]) => any>(fn: T): T {
  let lastArgs: any[] | null = null;
  let lastResult: any;

  return function (...args: any[]) {
    if (
      lastArgs &&
      args.length === lastArgs.length &&
      args.every((arg, i) => arg === lastArgs[i])
    ) {
      return lastResult; // same inputs -> reuse result
    }

    lastArgs = args;
    lastResult = fn(...args);
    return lastResult;
  } as T;
}

So:
Same args → skip work → return cached result.

Why memoization matters in NgRx

In NgRx you often have:

A big state tree
Selectors that derive data from that state
Components that subscribe to those selectors

Some derived data can be expensive to compute:

Filtering large lists
Sorting
Computing aggregates
Mapping to complex view models

If your selector recalculates this on every change detection, your app feels heavier than it should.

This is where NgRx comes in with a gift:

Selectors created with createSelector are memoized by default.

They only recompute when their inputs change (by reference).

Basic NgRx selector example (with memoization)

Imagine a simple state:

export interface Todo {
  id: string;
  title: string;
  completed: boolean;
}

export interface TodosState {
  todos: Todo[];
  filter: 'all' | 'completed' | 'active';
}

Feature selector:

export const selectTodosState = createFeatureSelector<TodosState>('todos');

Now a few selectors:

export const selectTodos = createSelector(
  selectTodosState,
  (state) => state.todos
);

export const selectFilter = createSelector(
  selectTodosState,
  (state) => state.filter
);

export const selectFilteredTodos = createSelector(
  selectTodos,
  selectFilter,
  (todos, filter) => {
    console.log('Recomputing filtered todos...');

    if (filter === 'completed') {
      return todos.filter((t) => t.completed);
    }

    if (filter === 'active') {
      return todos.filter((t) => !t.completed);
    }

    return todos;
  }
);

What NgRx does for you:

selectFilteredTodos is memoized
It only recalculates when:
- selectTodos returns a new array reference, or
- selectFilter returns a new filter value

If unrelated parts of the store change, and the todos array and filter are the same references, NgRx just returns the cached filtered list.

Less CPU, fewer unnecessary component updates.

How this helps your Angular components

Component:

@Component({
  selector: 'app-todos',
  template: `
    <div *ngFor="let todo of todos$ | async">
      {{ todo.title }}
    </div>
  `,
  changeDetection: ChangeDetectionStrategy.OnPush,
})
export class TodosComponent {
  todos$ = this.store.select(selectFilteredTodos);

  constructor(private store: Store) {}
}

Because selectFilteredTodos is memoized:

If state changes somewhere else (e.g. user profile), but todos slice is unchanged:
- Selector returns the same array reference
- With OnPush, Angular sees no new value → no re-render of this list

This is exactly the combo you want:

NgRx memoization
OnPush change detection
Less work, smoother app

Memoization and selectors with props

You can also use memoization when your selector depends on an argument, for example selecting a single todo by id.

export const selectTodoById = (id: string) =>
  createSelector(
    selectTodos,
    (todos) => {
      console.log('Recomputing todo by id...', id);
      return todos.find((t) => t.id === id) ?? null;
    }
  );

Then in your component:

todo$ = this.store.select(selectTodoById(this.todoId));

NgRx memoizes per selector instance here:

For this particular id, as long as selectTodos returns the same array reference, the selector returns the cached todo and doesn’t run find again.

A subtle gotcha: new objects break memoization

Memoization in NgRx works based on referential equality of the selector inputs.

If you do this:

export const selectTodoViewModels = createSelector(
  selectTodos,
  (todos) =>
    todos.map((t) => ({
      ...t,
      label: `${t.completed ? '✅' : '⬜'} ${t.title}`,
    }))
);

Each time selectTodoViewModels recomputes, it returns a new array with new objects.

The selector itself is still memoized, but if todos changes reference often, you’re rebuilding everything.

Better pattern in many cases:
Keep heavy transformations inside selectors, but don’t unnecessarily create new objects if inputs haven’t changed. Memoization helps at the selector level, but your code still needs to be reasonable.

Custom memoization (if you ever need more control)

NgRx also lets you define selectors with custom memoization via createSelectorFactory, but honestly in most apps:

createSelector’s built-in memoization is enough
You rarely need to touch lower-level memoization

If you ever have a crazy use case with complex arguments, that’s when you look into selector factories.

Quick recap

Memoization = caching function results based on inputs
NgRx selectors created with createSelector are memoized by default
They recompute only when their input selectors’ outputs change by reference
This works beautifully with OnPush and large apps where you can’t afford to recompute everything on every change detection
Use selectors to:
- Filter, sort, and derive data
- Keep components lean
- Let memoization + change detection handle performance

Angular Aria vs Angular Primitives: What’s the Difference and When Should You Use Each?

hassantayyab — Thu, 27 Nov 2025 12:38:24 +0000

Angular Aria vs Angular Primitives: What’s the Difference and When Should You Use Each?

The Angular ecosystem is evolving rapidly, especially around headless UI, accessibility, and composable component design. Two major players in this space are Angular Aria (introduced officially in Angular 21) and the Angular Primitives community library.

At first glance they may seem similar — both provide unstyled, headless building blocks for creating highly customizable UI components. But they actually solve different layers of the UI problem.

Understanding how they differ, where they overlap, and how to use them together is key if you’re building modern Angular applications, design systems, or complex custom UI libraries.

This article breaks it all down.

What Is Angular Aria?

Angular Aria is an official Angular package introduced in Angular 21. Its goal is simple:
to make accessible components easy to build.

Angular Aria provides WAI-ARIA–compliant UI patterns that include baked-in accessibility behaviors such as:

Keyboard navigation
Focus management
Screen-reader semantics
ARIA roles and state attributes
Correct interactive behavior patterns (accordion, tabs, tree, grid, etc.)

These components are headless — meaning they come with no CSS or styling. You provide all the UI design, and Angular Aria provides the accessibility and interaction logic.

Angular Aria currently supports these major patterns:

Tabs
Accordion
Combobox
Listbox
Select
Multiselect
Menu
Menubar
Toolbar
Grid
Tree
Autocomplete

In short: Angular Aria ensures components behave correctly for all users, including those relying on assistive technologies.

What Is Angular Primitives?

Angular Primitives (angularprimitives.com) is a community-driven library that provides low-level composable utilities — much like Radix UI, Headless UI, or React Aria Primitive hooks in the React ecosystem.

Its goal is different from Angular Aria:

Instead of giving you ARIA-compliant components, Angular Primitives gives you the building blocks needed to create your own component logic such as:

Dialog and modal behavior
Popover and floating positioning
Click-outside detection
Toggle state
Collapsed/disclosure logic
Stores and reactive utilities
Focus traps
Motion and transition helpers
Overlay logic
Accessible patterns for interactions

Angular Primitives is about interaction mechanics, not full ARIA patterns.

It is perfect for building things like:

Custom dialogs
Custom popovers
Custom dropdown logic
Custom tooltips
Custom toggle controls
Custom multi-step flows
Custom interactive UI widgets

All while remaining unstyled and flexible.

How Angular Aria and Angular Primitives Differ

Here is the simplest way to think about the difference:

Angular Aria = Accessibility Behavior (Official)
Angular Primitives = Interaction Logic (Community)

More specifically:

Angular Aria focuses on accessibility and ARIA correctness
Angular Primitives focuses on composable UI behaviors and state
Angular Aria gives entire UI patterns (tabs, menus, combobox…)
Angular Primitives gives low-level utilities (popover, toggle, click-outside…)
Angular Aria is about meeting accessibility standards
Angular Primitives is about building custom, interactive experiences

Another way to say it:

Angular Aria is "what accessible UI patterns should do."
Angular Primitives is "how UI components actually behave and interact."

Where They Overlap

Both:

Are headless (unstyled)
Focus on custom component building
Encourage composability
Improve developer ergonomics
Fit perfectly into design-system workflows

Because they have different goals, they rarely conflict.

How They Work Together (The Powerful Combination)

Using Angular Aria and Angular Primitives together gives you maximum power.

Example: You want to build a fully custom Select/Combobox component.

Angular Aria provides:

Listbox behavior
Keyboard navigation
Screen reader patterns
ARIA roles and attributes
Accessibility state
Focus management

Angular Primitives provides:

Popover open/close logic
Floating panel positioning
Arrow key open/close behavior
Click outside to dismiss
Animate the dropdown
Manage local state
Trap focus when expanded

Combine both, and you get:

Fully custom design
Fully accessible
Fully interactive
Perfect ARIA compliance
Minimal boilerplate
No dependence on Angular Material or heavy UI kits

This is the ideal combination for building your own design system.

When To Use Angular Aria

Use Angular Aria when you need:

Fully accessible UI components
ARIA-compliant patterns (tabs, accordion, grid, tree, menu…)
A custom design system with accessibility built in
Complex components like Combobox or Listbox
Consistent, official Angular tooling

It is best for enterprise apps, public-sector apps, or any project where accessibility cannot be optional.

When To Use Angular Primitives

Use Angular Primitives when you need:

Low-level interactive logic
Dialog behavior
Popover logic
Floating UI positioning
Toggle or disclosure mechanics
Overlay management
Stores and shared reactive state
Click-outside detection
Motion and transitions

It is best for building deeply customized UI behaviors and complex components.

When You Should Use Both Together

Use both when:

You are building a design system
You want strong accessibility and rich interactions
You want complete styling freedom
You prefer headless, composable component architecture
You want to replace Angular Material with a fully custom UI suite
You need both ARIA correctness and complex UI behaviors

This combination is becoming a modern best practice in the Angular ecosystem.

Summary

Angular Aria and Angular Primitives are not competitors — they are complementary tools that operate on different layers:

Angular Aria gives you officially supported ARIA-compliant UI patterns.
Angular Primitives gives you interaction primitives and utilities.

Together, they form a powerful foundation for building fully custom, fully accessible, and highly interactive UI components — an essential approach for modern Angular applications and design systems.

Angular Aria in Angular 21: The Future of Accessible, Headless UI Components

hassantayyab — Wed, 26 Nov 2025 12:00:36 +0000

Accessibility has become one of the most important pillars of modern web development. With Angular 21, the framework takes a huge leap forward with Angular Aria, a brand-new package that delivers headless, accessibility-ready UI patterns out of the box — without enforcing any styling or visual design.

Angular Aria brings powerful, production-ready accessibility to your custom UI components while giving you full control over markup and CSS. If you’re building design systems, enterprise dashboards, or any rich interactive UI, this new feature dramatically reduces the complexity of building accessible components.

🚀 What Is Angular Aria?

Angular Aria is a new library introduced in Angular 21 to standardize accessibility behaviors for commonly used interactive UI patterns. It handles:

ARIA roles & attributes
Keyboard navigation
Focus management
Screen-reader semantics
Interaction state management

All while remaining unstyled and fully customizable, allowing you to craft your own visual identity.

Instead of manually implementing complex accessibility rules, you use Angular Aria’s directives — and the accessibility logic is done for you.

🧩 Supported UI Patterns in Angular Aria

Here are the major patterns available in the first release:

🔹 Inputs & Selection

Autocomplete
Listbox
Select
Multiselect
Combobox

🔹 Navigation & Menus

Menu
Menubar
Toolbar

🔹 Structure & Content Organization

Accordion
Tabs
Tree
Grid

These patterns cover a large portion of real-world accessibility needs — especially in design systems and enterprise-grade apps.

🎯 Why Angular Aria Matters

1. Accessibility by Default

Accessibility is complex — especially with dynamic components like menus or comboboxes. Angular Aria builds accessibility into the logic, so your UI is accessible without manual ARIA implementation.

2. Headless Architecture

You control:

HTML
CSS
Layout
Branding

Angular Aria only provides the behaviors — perfect for custom design systems.

3. Enterprise-Friendly

Teams maintaining multiple apps can rely on Angular Aria to ensure accessibility consistency across all projects.

4. Better Developer Experience

You no longer need to memorize ARIA rules or behavior patterns. The library handles them so you can focus on productivity.

🎨 Example: Simple Accessible Toolbar

import {
  Toolbar,
  ToolbarWidget,
  ToolbarWidgetGroup
} from '@angular/aria/toolbar';

<div ngToolbar aria-label="Text Controls">
  <div class="group">
    <button ngToolbarWidget value="undo" aria-label="Undo">Undo</button>
    <button ngToolbarWidget value="redo" aria-label="Redo">Redo</button>
  </div>

  <div class="group">
    <button ngToolbarWidget value="bold" aria-label="Bold">Bold</button>
    <button ngToolbarWidget value="italic" aria-label="Italic">Italic</button>
  </div>
</div>

Accessible: ✔️
Keyboard-friendly: ✔️
Screen-reader ready: ✔️
No extra work required: ✔️

🛠️ Getting Started With Angular Aria

Install the package

npm install @angular/aria

Import the pattern module you need

import { Tabs, Tab, TabPanel } from '@angular/aria/tabs';

Use the directives in your templates

<div ngTabs>
  <button ngTab="tab1">Overview</button>
  <button ngTab="tab2">Details</button>

  <section ngTabPanel="tab1">Overview content…</section>
  <section ngTabPanel="tab2">Detailed content…</section>
</div>

Add your own styling Angular Aria provides no CSS — giving you full creative freedom.

📘 Angular Aria Cheat Sheet (Quick Reference)

Installation

npm install @angular/aria

Common Imports

Pattern	Import Example
Tabs	`import { Tabs, Tab, TabPanel } from '@angular/aria/tabs';`
Accordion	`import { Accordion, AccordionItem } from '@angular/aria/accordion';`
Menu	`import { Menu, Menuitem } from '@angular/aria/menu';`
Toolbar	`import { Toolbar, ToolbarWidget } from '@angular/aria/toolbar';`
Listbox	`import { Listbox, ListboxOption } from '@angular/aria/listbox';`
Combobox	`import { Combobox, ComboboxOption } from '@angular/aria/combobox';`

Directive Patterns

Tabs

<div ngTabs>
  <button ngTab="id1">Tab 1</button>
  <section ngTabPanel="id1">Content 1</section>
</div>

Accordion

<div ngAccordion>
  <div ngAccordionItem>
    <button ngAccordionItemToggle>Title</button>
    <section ngAccordionItemPanel>Content</section>
  </div>
</div>

Listbox

<ul ngListbox>
  <li ngListboxOption value="1">Option A</li>
  <li ngListboxOption value="2">Option B</li>
</ul>

Combobox

<input ngCombobox />
<ul ngComboboxOptions>
  <li ngComboboxOption value="alpha">Alpha</li>
</ul>

Keyboard Support (Handled Automatically)

Example behaviors Angular Aria manages:

Arrow keys for navigation
Enter/Space for selection
Escape for closing menus
Tab/Shift+Tab focus trapping
Focus restoration when components close

You don’t implement any of this manually — Angular Aria does it.

📚 Further Reading & Resources

For detailed documentation, examples, and the full API reference, visit:

👉 Angular Aria Official Documentation
https://angular.dev/guide/aria/overview

Building fast in Angular with Zard UI Tailwind CSS Signals and NgRx

hassantayyab — Tue, 25 Nov 2025 11:26:59 +0000

If you are building products in a startup environment you do not have time to reinvent buttons and argue about folder structures for a week.

You need to ship.

Modern Angular actually makes that pretty fun
Especially when you combine four things

Zard UI
Tailwind CSS
Angular’s new signals and control flow
NgRx when your state gets serious

Add a couple of small helper libraries on top and you get a stack that lets you move very fast without your codebase turning into chaos.

Let’s break it down.

1. Why this stack is so fast

Most frontend time is lost in three places

Designing and styling basic UI from scratch
Rewriting state management every project
Fighting with inconsistent patterns between team members

Zard UI and Tailwind handle the first part
Signals and NgRx handle the second
Angular itself handles the third with its opinionated structure

You get speed without giving up structure.

2. Zard UI – plug in real components instead of drawing them

Zard UI gives you a set of ready made Angular components inspired by modern headless and design system libraries.

Things like

Buttons
Dialogs
Dropdown menus
Menus and navigation
Inputs and forms
Toasts and alerts

Instead of designing all of these from zero you drop them in wire them to your data and you are done.

Why it helps you move faster

You stop re designing basic components every project
You get accessibility and interaction patterns handled for you
You keep a consistent look and feel across the app

For an MVP you can have a clean UI in a day instead of a week
And because components are composable you can still customize them when you actually need to.

3. Tailwind CSS – styling without bike shedding

Tailwind fits this really well.

You write your styles as utility classes in the template
No long naming debates
No giant CSS files you are scared to touch months later.

Example

<button
  class="px-4 py-2 rounded-xl text-sm font-medium bg-blue-600 hover:bg-blue-700 text-white"
>
  Save
</button>

It is readable and you see the styling right in the markup.
Design tweaks become quick edits not refactors.

Tailwind plus Zard UI

Most components expose class or style hooks so your workflow becomes

Drop a Zard UI component
Add or tweak Tailwind classes
Ship

You stay in flow and you rarely have to open a separate CSS file.

4. State management with Signals first NgRx when it matters

This is where many Angular apps either stay clean or become pain.

Start with Angular signals for local and feature level state

For a lot of early stage or smaller features you do not need a full global store.
Angular’s signals give you a simple pull based mental model.

import { signal, computed } from '@angular/core';

export class UsersComponent {
  users = signal<User[]>([]);
  loading = signal(false);

  totalUsers = computed(() => this.users().length);

  async loadUsers() {
    this.loading.set(true);
    const data = await this.api.getUsers();
    this.users.set(data);
    this.loading.set(false);
  }
}

Template

@if (loading()) {
  <p>Loading users...</p>
} @else {
  <p>Total users {{ totalUsers() }}</p>

  @for (user of users(); track user.id) {
    <div class="p-3 rounded-lg border mb-2">
      {{ user.name }}
    </div>
  }
}

Signals are perfect when

The state is local to a component or small feature
Only a few components need the same data
You are still exploring the product and requirements move fast

You write less boilerplate and you can refactor easily later.

Bring in NgRx when the app and data sharing grow

At some point you hit problems that signals alone should not solve

Many components across the app rely on the same data
You need predictable behaviour on complex flows
You want time travel debugging or strict immutability
You start duplicating fetch and update logic in multiple places

This is where NgRx earns its place.

You move shared and complex state out of random services and into feature stores.
Signals can still live at the edge of the UI to map store data to components
But NgRx holds the source of truth.

Typical pattern

Use signals and simple services for local UI state modal open flags form steps local filters
Use NgRx for domain level state shared across screens auth user profile entities lists cart etc

This gives you

A clear separation between UI state and application state
A single source of truth for important data
Scalable patterns when the team grows and multiple people touch the same features

The key is timing
Do not force NgRx on day one for a tiny MVP
Introduce it when you feel real pain from shared or duplicated state.

5. A few extra helpers that keep things fast

Some small tools that work nicely with this setup

Angular CDK
Overlays drag and drop portals accessibility tools.
Often enough for custom interactions without huge dependencies.
Zod or Valibot with Angular forms
You define the schema once
Use it for validation on the client and server
This keeps your forms honest and type safe.
A query style data fetching layer if needed
You can pair NgRx with entity adapters or use a query library for server state.
Either way the goal is the same
caching loading error handling in one place instead of every component doing its own thing.

You do not need all of these from day one
You add them when you hit a real problem.

6. A simple “fast stack” blueprint

If I was starting a new Angular product today and I cared about speed and long term health this is what I would do

Use Angular with standalone components new control flow and signals
Add Tailwind CSS for styling
Add Zard UI for core UI primitives buttons dialogs forms toasts
Use signals plus lightweight services for local and feature state
When multiple parts of the app depend on the same data introduce NgRx for that domain and keep using signals at the component level
Only add extra libs when they remove real pain not just because they look cool

Rule
If it does not help me ship in the next week it goes to the backlog.

7. Mindset still beats stack

All of this works only if the mindset matches

Reuse existing components before building new ones
Avoid premature “enterprise” architecture for a tiny product
Keep your first versions simple but shippable
Refactor when it actually hurts not just because you are bored

Angular gives enough structure that you can move fast without creating a junkyard.
Signals Zard UI Tailwind and NgRx just make the path smoother.

Closing thoughts

Angular today is not the heavy slow framework people remember from years ago.
With Zard UI Tailwind CSS signals and NgRx used at the right time you can build modern apps that ship fast now and stay maintainable later.

I will hopefully share my real world experience with this stack in a post very soon and drop it here for everyone 😊

And I am curious
How are you mixing signals and NgRx in your Angular apps right now?