Forem: Alfredo Perez

Getting Started with Angular Toolbar

Alfredo Perez — Mon, 02 Feb 2026 15:54:00 +0000

You're building an internal business application. Your QA team needs to test what an Admin sees versus a regular user. Your stakeholder wants to demo the new dashboard that's still behind a feature flag. And IT wants to verify that the "Bulk Export" feature is properly gated to licensed users only.

Three requests. Normally, that's three database changes, three test accounts, and a lot of context switching.

Or... you could just use the Angular Toolbar.

In the previous article, we introduced ngx-dev-toolbar and why it's useful for internal business applications. Now let's get it running and set up Feature Flags, Permissions, and App Features—the three tools that make testing different scenarios instant.

Quick Setup

Initialize the toolbar in your main.ts:

import { bootstrapApplication } from '@angular/platform-browser';
import { isDevMode } from '@angular/core';

async function bootstrap() {
  const appRef = await bootstrapApplication(AppComponent, appConfig);

  if (isDevMode()) {
    const { initToolbar } = await import('ngx-dev-toolbar');
    initToolbar(appRef);
  }
}

bootstrap();

The dynamic import ensures zero production bundle impact—the toolbar code only loads in development.

How It Works

All three tools work the same way:

Register your options with setAvailableOptions()
Read the values with getValues()

The toolbar stores any overrides in localStorage, so they persist across page reloads. When you read values with getValues(), you get your original values with any toolbar overrides already applied.

Feature Flags

Remember that new dashboard your stakeholder wants to demo? That's a feature flag. Let's wire it up.

// 📃 feature-flags.service.ts
import { ToolbarFeatureFlagService } from 'ngx-dev-toolbar';

@Injectable({ providedIn: 'root' })
export class FeatureFlagsService {
  private toolbarService = inject(ToolbarFeatureFlagService);

  // 👇 Real flag values from your flag provider (LaunchDarkly, Split, etc.)
  private realFlags = toSignal(this.flagProvider.getFlags(), { initialValue: [] });

  // 👇 All flags with toolbar overrides already applied
  private flags = toSignal(this.toolbarService.getValues(), { initialValue: [] });

  constructor() {
    // Register flags with the toolbar when they load
    effect(() => {
      const flags = this.realFlags();
      if (flags.length) {
        this.toolbarService.setAvailableOptions(
          flags.map(f => ({
            id: f.key,
            name: f.name,
            description: f.description,
            isEnabled: f.value,
          }))
        );
      }
    });
  }

  getFlag(id: string): Signal<boolean> {
    return computed(() =>
      this.flags().find(f => f.id === id)?.isEnabled ?? false
    );
  }
}

The getValues() method returns all flags with any toolbar overrides already merged in—no manual merging required.

Your flag provider might return data in a different format than the toolbar expects. You can map the values when registering:

// LaunchDarkly returns: { key: 'dark-mode', value: true }
// Toolbar expects: { id: string, name: string, description: string, isEnabled: boolean }

this.toolbarService.setAvailableOptions(
  flags.map(f => ({
    id: f.key,                              // key → id
    name: this.formatName(f.key),           // 'dark-mode' → 'Dark Mode'
    description: this.descriptions[f.key],  // Add descriptions from a local map
    isEnabled: f.value,                     // value → isEnabled
  }))
);

Use it in your components:

// 📃 dashboard.component.ts
@Component({...})
export class DashboardComponent {
  private featureFlagsService = inject(FeatureFlagsService);

  showNewDashboard = this.featureFlagsService.getFlag('new-dashboard');
}

@if (showNewDashboard()) {
  <app-new-dashboard />
} @else {
  <app-classic-dashboard />
}

Permissions

Now for that QA scenario—testing what an Admin sees versus a regular user. That's all about permissions.

Permissions work the same way as feature flags, but with three possible states: original value, forced granted, or forced denied.

For permissions, you might want more control over how overrides are applied. Instead of getValues(), you can use getForcedValues() which returns only the permissions that were overridden in the toolbar:

// 📃 permissions.service.ts
import { ToolbarPermissionsService } from 'ngx-dev-toolbar';

@Injectable({ providedIn: 'root' })
export class PermissionsService {
  private toolbarService = inject(ToolbarPermissionsService);

  // 👇 Real permissions from your auth backend
  private realPermissions = toSignal(this.authService.getPermissions(), { initialValue: [] });

  // 👇 Only the permissions overridden in the toolbar
  private forcedPermissions = toSignal(this.toolbarService.getForcedValues(), { initialValue: [] });

  constructor() {
    // Register permissions with the toolbar
    effect(() => {
      const perms = this.realPermissions();
      if (perms.length) {
        this.toolbarService.setAvailableOptions(
          perms.map(p => ({
            id: p.id,
            name: p.name,
            isGranted: p.granted,
          }))
        );
      }
    });
  }

  hasPermission(id: string): Signal<boolean> {
    return computed(() => {
      // 👇 Check toolbar override first
      const forced = this.forcedPermissions().find(p => p.id === id);
      if (forced) return forced.isGranted;

      // 👇 Fall back to real permission
      return this.realPermissions().find(p => p.id === id)?.granted ?? false;
    });
  }
}

This pattern gives you explicit control: real values from your backend, with toolbar overrides layered on top only when set.

getValues() vs getForcedValues()

Both methods work, but serve different needs:

getValues() — Returns all options with overrides already applied. Simpler to use when you want the toolbar to manage everything.
getForcedValues() — Returns only the options that were manually overridden. Use this when your backend is the source of truth and you want to explicitly layer toolbar overrides on top.

Choose getValues() for simpler integrations. Choose getForcedValues() when you need to preserve the distinction between real values and test overrides.

App Features

And finally, that "Bulk Export" feature IT wants to verify? That's a license-gated app feature.

App Features are perfect for testing subscription tiers and license-based functionality:

// 📃 app-features.service.ts
import { ToolbarAppFeaturesService } from 'ngx-dev-toolbar';

@Injectable({ providedIn: 'root' })
export class AppFeaturesService {
  private toolbarService = inject(ToolbarAppFeaturesService);

  // 👇 Real features from your licensing backend
  private realFeatures = toSignal(this.licensingService.getFeatures(), { initialValue: [] });

  private features = toSignal(this.toolbarService.getValues(), { initialValue: [] });

  constructor() {
    effect(() => {
      const features = this.realFeatures();
      if (features.length) {
        this.toolbarService.setAvailableOptions(
          features.map(f => ({
            id: f.id,
            name: FEATURE_METADATA[f.id]?.name ?? f.id,
            description: FEATURE_METADATA[f.id]?.description ?? '',
            isEnabled: f.enabled,
          }))
        );
      }
    });
  }

  isEnabled(id: string): Signal<boolean> {
    return computed(() => this.features().find(f => f.id === id)?.isEnabled ?? false);
  }
}

Did you notice the FEATURE_METADATA mapping? Your licensing API typically returns just feature IDs and enabled status—no user-friendly names or descriptions. We added both name (to control how it appears in the toolbar) and description locally:

// 📃 app-features.models.ts
export enum Feature {
  Analytics = 'analytics',
  BulkExport = 'bulk-export',
  WhiteLabel = 'white-label',
  Notifications = 'notifications',
  ApiAccess = 'api-access',
}

export const FEATURE_METADATA: Record<string, { name: string; description: string }> = {
  [Feature.Analytics]: { name: 'Analytics Dashboard', description: 'Advanced reporting and visualization' },
  [Feature.BulkExport]: { name: 'Bulk Export', description: 'Export datasets to CSV or Excel' },
  [Feature.WhiteLabel]: { name: 'White Label', description: 'Custom branding with your logo' },
  [Feature.Notifications]: { name: 'Notifications', description: 'Real-time push notifications' },
  [Feature.ApiAccess]: { name: 'API Access', description: 'REST API for integrations' },
};

This keeps your feature definitions type-safe and your descriptions in one place.

Now you can test what users on different subscription tiers see—without touching the database.

Combining for Realistic Scenarios

Here's where it all comes together.

Remember those three requests from the beginning? With the toolbar set up, you can handle all of them without touching the database. Toggle the new dashboard flag for the demo. Grant "can-admin" permission to simulate an admin user. Enable "Bulk Export" to verify the license gate.

The real power comes when you combine all three tools. Want to test what an "Admin with Enterprise license" sees? Enable the app features and grant the permissions. Testing a "Regular user on Basic tier"? Adjust accordingly.

In the next article, we'll see how to save these combinations as Presets—so you can switch between user personas with a single click.

What's Next

Now that you know how to use the built-in tools, check out the next article on Presets to learn how to save and share your configurations with your team.

Happy developing!

Spec-Driven Development: Stop Vibe Coding

Alfredo Perez — Sat, 03 Jan 2026 05:13:20 +0000

I want to add a feature to my VS Code extension that highlights the current plan step in the workflow progress bar.

My first instinct? Just start coding... but what if we can vibe code it? Ok, let's give it a shot. Open Claude Code, type "highlight the current plan step in the workflow progress bar and order the sub-menu so Plan is first," and let the AI figure it out. But then the questions start flooding in: How should the highlighting work visually? Should it persist across sessions? What about the sub-menu ordering—alphabetical or by workflow phase? How does the extension communicate between the sidebar and the WebView?

Here's the thing: I could just prompt the AI and hope it makes the right assumptions. Or I could spend the next hour going back and forth, correcting misunderstandings, and ending up with something that "works" but isn't quite what I had in mind.

There's a better way. Let me show you how I approached this differently using spec-driven development.

What is "Vibe Coding"?

You know the feeling. You have a rough idea of what you want to build, you open your AI coding assistant, type something like "Highlight the current step in the progress bar," and hope for the best.

The AI starts generating code. It looks reasonable. It compiles. But then you realize—it highlighted the wrong element. Or it used inline styles when you wanted CSS classes. Or it assumed the highlighting should be permanent when you wanted it to update dynamically as users navigate.

So you go back and forth. Re-prompt. Clarify. Debug. Re-prompt again. After an hour of this, you're either frustrated enough to just code it yourself, or you accept something that's "good enough" but not quite right.

This is vibe coding—jumping straight into implementation without making your decisions explicit. And with AI assistants, it happens faster than ever. As Microsoft's spec-driven development post puts it: "Code is inherently a binding artifact—once you write an implementation, it's very hard to decouple from it."

The consequences compound. You spend endless hours going back and forth fixing misunderstandings. There's no documentation of why decisions were made, so each AI session starts from scratch—it doesn't remember your intent. And if you're working with a team? Good luck. Nobody has shared context about what you were actually trying to build.

If you want to see this problem explained in more detail, check out Dan Delamarski's demo of spec-kit where he walks through the full workflow.

The Solution: Spec-Driven Development

Spec-driven development flips the script. Instead of jumping to code, you first make your intent explicit through specifications. These specs become executable artifacts that directly generate implementations.

The core principle: Define what and why before how.

Here's what changes: the AI finally understands your intent because it's working from detailed specifications, not vague prompts. You get fewer iterations to reach the correct implementation. Your specs become living documentation that evolves with your project. Teams can coordinate through shared, reviewable specs—and new team members can onboard by reading them instead of reverse-engineering your code.

Think of it as "version control for architectural thinking."

Tools like Kiro have built their entire IDE around this concept—transforming natural language prompts into detailed specifications, then into functional code, documentation, and tests. GitHub's spec-kit brings this methodology to any AI coding assistant you already use.

Getting Started

Let me walk you through setting up spec-driven development and then show you exactly how I used it to build the plan step highlight feature.

Step 1: Install Prerequisites

You'll need:

Python 3.11+
Git
uv package manager
An AI coding assistant (Claude Code, GitHub Copilot, Gemini CLI, etc.)

Step 2: Install spec-kit CLI

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

For more details, check out the spec-kit GitHub repo.

Step 3: Install SpecKit Companion (VS Code Extension)

This extension gives you a visual interface for the spec-driven workflow:

Open VS Code Extensions
Search for "SpecKit Companion"
Install the extension

Or visit: SpecKit Companion on Marketplace

Step 4: Initialize Your Project

specify init my-project --ai claude
# Or in an existing project:
specify init . --here --ai claude

Spec-kit supports 15+ AI assistants including Claude Code, GitHub Copilot, Gemini CLI, Cursor, and more.

I'll be using Claude Code for this demo, but the workflow is the same regardless of which AI you choose.

The Spec-Driven Workflow: Building Plan Step Highlight

Now let's see this in action. I'll walk through each phase of the spec-driven workflow as I build the plan step highlight feature for my VS Code extension. Watch how SpecKit Companion visualizes each step.

Phase 1: Constitution

Before writing any specs, I establish the project's governing principles. The constitution defines non-negotiable constraints that anchor all future decisions.

/speckit.constitution Create principles for SpecKit Companion focused on:
- TypeScript with strict mode enabled
- VS Code Extension API best practices
- WebView communication via message passing
- State updates within 100ms of navigation
- Must integrate with existing workflow editor architecture

This creates .specify/memory/constitution.md with my project principles.

Why does this matter? Every spec I write from now on will reference these principles. When the AI plans the highlight feature, it knows to use proper message passing between extension and WebView, keep state updates performant, and follow the existing architecture patterns.

Phase 2: Specify

Now I define what I want to build—without making technical decisions yet.

In the SpecKit Companion sidebar, I click the "+" button to create a new spec. This opens the "Create New Spec" dialog where I describe what I want:

Notice the Attach Image button at the bottom—I can add screenshots or mockups to give the AI visual context. This is powerful when describing UI changes.

I write my description: "We need to make sure that when a sub-section of the plan is opened, the plan step is highlighted. Also, we need to show in the sub-menu inside the plan step that the plan is the first menu option and then the other ones ordered alphabetically."

Notice what I'm NOT saying: no mention of CSS classes, message passing implementation, or state management patterns. Just the what and why.

I click Submit to AI, and the extension generates the specification. The Workflow Editor opens showing my spec in Phase 1 of 4:

The 4-phase progress bar at the top shows where I am: Spec → Plan → Tasks → Done.

If I need to refine the spec, I can click the Clarify button to ask questions like "Should the highlight persist when switching between tabs?" The AI will help resolve ambiguities.

When I'm satisfied, I click Approve & Next Phase to move to the Plan phase.

Alternatively, you can create specs from the terminal with /speckit.specify followed by your description.

Phase 3: Plan

After clicking Approve & Next Phase, the extension automatically advances to the Plan phase. Now I make the technical decisions—this is where I specify how to implement the feature.

The Workflow Editor shows the generated Implementation Plan. Notice the tabs at the top—the Plan phase includes multiple sub-sections:

Plan — Summary and Technical Context (language, dependencies, testing approach)
Data Model — Data structures and schemas
Quickstart — Quick reference for getting started
Research — Background research and references

The plan includes architecture decisions, dependencies, and testing strategy. Notice how it references my constitution—it confirms that message passing aligns with "WebView communication" and performance targets.

If I want to validate the plan, I can click the Checklist button to generate validation checklists—like "unit tests for English" that verify my requirements are complete and consistent.

When the plan looks good, I click Go to Next Phase to proceed to Tasks.

Alternatively, you can generate plans from the terminal with /speckit.plan followed by your technical decisions.

Phase 4: Tasks

The Tasks phase opens automatically after approving the plan. The extension generates .specify/specs/001-plan-step-highlight/tasks.md—a breakdown with ordered tasks and dependencies, markers for tasks that can run in parallel, and a test-driven development structure built right in.

Tasks are organized by phases (Setup, Core Implementation, etc.) with clear dependencies. The format shows which tasks can run in parallel and which user story each task belongs to.

Before implementing, I can click the Analyze button to run a cross-artifact consistency check—this validates that my spec, plan, and tasks all align properly.

The tasks are editable. If I want to reorder something or add a task, I click Edit Source and modify the markdown directly.

When ready, I click Approve & Next Phase to complete the workflow.

Alternatively, you can generate tasks from the terminal with /speckit.tasks.

Phase 5: Implement

After clicking Approve & Next Phase in Tasks, the workflow advances to the Done phase—all four circles in the progress bar are now checked. My spec, plan, and tasks are ready for implementation.

From here, I can:

Copy the tasks to paste into my AI assistant
Open in Claude Code (or your preferred AI) directly from the extension
Run /speckit.implement in the terminal to let the AI execute the plan systematically

The AI works through each task in order, respecting dependencies. Because it has full context from the spec and plan, it knows exactly what I want and why.

Project Structure

Here's what the .specify folder looks like after going through the workflow:

.specify/
├── memory/
│   └── constitution.md      # Project principles
└── specs/
    └── 001-plan-step-highlight/
        ├── spec.md          # Requirements (what/why)
        ├── plan.md          # Technical strategy (how)
        ├── tasks.md         # Implementation roadmap
        ├── data-model.md    # Data structures
        ├── quickstart.md    # Quick reference
        └── research.md      # Background research

The key benefit? All files are editable markdown—you're not locked into AI-generated content. They're version control friendly, so you can branch and iterate on specs before implementing. Your team can review and contribute to specs. And if requirements change, you just update the spec and re-run—no starting from scratch.

What's Different?

Compare this to vibe coding:

Vibe Coding	Spec-Driven
"Highlight the step" → hope AI understands	Explicit spec defines exactly what highlighting means
5-10 iterations to get it right	1-2 refinements with clear context
No documentation	Living docs in `.specify/`
Next session starts from scratch	Specs persist and evolve
"It works... I think?"	Implementation matches verified spec

SpecKit Companion: More Than Workflow

The extension does more than guide you through specs. The sidebar gives you quick access to everything in your project:

Specs — Browse all your specifications with their plan and tasks
Steering — Access your constitution, project rules, and shared scripts
Agents — Configure user and project-level AI agents
Skills — Manage MCP servers for extended capabilities
Hooks — Set up Claude Code hooks for automation

We'll dive deeper into each of these features in the next article.

Conclusion

Spec-driven development transforms how you work with AI. Instead of hoping the AI understands your intent, you make sure it does—with explicit specifications that become living documentation.

For my plan step highlight feature, I went from a vague idea to a clear spec, a technical plan, and an ordered task list—all before writing a single line of implementation code. When the AI finally implemented the feature, it had full context about what I wanted and why.

Your specs become the single source of truth. They're reviewable, version-controlled, and collaborative. And when requirements change (they always do), you update the spec and re-run—instead of starting from scratch.

Ready to stop vibe coding?

spec-kit on GitHub — The CLI toolkit
SpecKit Companion — VS Code extension for visual workflow
Kiro — AI IDE built around spec-driven development

Next up: A deep dive into SpecKit Companion's sidebar—agents, skills, hooks, and more.

Universal Knowledge Base for AI

Alfredo Perez — Sat, 03 Jan 2026 05:12:37 +0000

Okay, tell me if this sounds familiar: You're working on a new project and need to add a page, but suddenly you don't know what patterns to follow. You check the closest page to see how it's structured and verify when it was created, and the code feels dated with outdated patterns. So you look for another page that was recently modified in one of the current PRs, and you notice that some code looks modern, and some looks like legacy code. Now you don't know what pattern or practice to follow because maybe the latest page is just the result of copy-pasting from other pages. It's like a collage of coding patterns and practices.

Here's another example that might sound familiar: What if you use Cursor and you've set up your Cursor rules, and it knows how to create components using Angular's modern features, but when you try the same with Claude Code, it doesn't follow any of the rules you already set up? What if you use VS Code and you have to set up instructions? or what if your team uses five different AI Tools?

Well, if you've been in this situation, that's why I decided to create a knowledge base for AI that can set our patterns and style guides, share how we configure AI tools, and document all the patterns a company or project needs to follow. This knowledge base needs to be universal—document once, use everywhere, whether you're working with Cursor, Claude Code, or collaborating with your team.

Why do we need it?

Okay, so if you still need convincing, let's talk about three reasons why it's important to have this knowledge base specialized for AI.

Share Knowledge That Actually Gets Used

I've been a big proponent of documentation as a great way to share knowledge between teams. As your team grows and practices evolve, you can share recipes, tips, and tricks. This makes it super fast for developers to start developing and focus on bigger problems (how to make customers happier or create better product features) instead of figuring out how to build a page, table, or dialog again.

This is the first reason why I think it's important to have this knowledge base for AI — it's not only used by AI but also shared with all team members. Good for onboarding and standardization.

Stop Recreating AI Tool Configuration

Another reason is that there are a lot of AI tools and if we configure or write agents for one tool, we have to recreate the same strategy in others if we want consistency. By centralizing how we create an agent that checks stability (just an example), we can reuse it in both tools. It doesn't matter what format each tool needs—we just point to the document that has the details.

Allow Developers to Choose Their Workflow

We want to allow developers to try different workflows without forcing them into one approach. You might think, "Well, we can just commit the .claude folder or .cursor folder to GitHub, and that's how they can reuse agents and rules." But moving the knowledge base to a separate folder lets developers choose their own way to use AI tools without being locked into a specific approach.

Here's the difference: If we create a shared agent that does Angular development one way and put it directly into the .claude/agents folder, developers have to either use it as-is or create a PR to request changes to that shared configuration.

But if we put all the recommended agents, commands, and AI modes in a separate knowledge base, every developer can pick and choose what they need to create their own workflow. They're not stuck with our decisions — they can mix and match based on their preferences.

Also, since AI tooling is changing daily, keeping AI configuration folders out of the main repo allows developers to download and experiment with new tools without risking interference with anyone else's setup.

How do we create a Universal Knowledge Base?

Well, now to get this working, we'll create a knowledge base folder in your project with three major sections:

Code Style — Framework and language patterns
Project — Project-specific rules and guides
Tools — AI tool configurations and templates

The key is creating specialized, focused files rather than monolithic ones. We don't want one massive file that covers everything from creating components to unit tests to building pages with tables. Instead, we want targeted files that are concrete, concise, and reusable in multiple contexts. These files should be token-efficient and well-formatted for AI consumption (using Markdown and XML tags).

This modular approach gives us flexibility. For example, we can create a comprehensive agent that knows everything about Angular for complex tasks but also build a lightweight Claude Code command that only reviews component files and just needs a small subset of those specialized files.

The beauty is in the mix-and-match capability—each file serves a specific purpose, and you can combine them however makes sense for the task at hand.

Code Style

The code style folder is for all your framework patterns—guides, rules, and definitions that work across projects. If two projects share Angular, TypeScript, or Jest, they can share this knowledge base. Think about organizing this the way your mind categorizes development work. Angular patterns live in one folder, testing strategies in another, and component libraries get their own space.

The key is file granularity. When you're building a component creation agent, it doesn't need state management or directive context—just focused component standards. I structure each domain with a core foundation document plus specialized task files. angular/angular-core.md establishes your fundamental philosophy and shared patterns, while angular/components-guide.md focuses purely on component creation.

This approach lets you create surgical workflows instead of feeding every AI tool your entire knowledge base. A component expert gets exactly the context it needs—no token waste, no cognitive overload, just precise guidance that produces consistent results.

code-style/
  angular/
    angular-core.md        # Angular setup and conventions
    components-guide.md    # Component patterns
    services-guide.md      # Service patterns
  ngrx/                    # NgRx setup and conventions
    ngrx-core.md           # Main rules on how ngrx is used
  scss-guide.md            # Styling conventions
  testing-guide.md         # Unit testing
  e2e-testing-guide.md     # E2E strategies

Project

The project folder contains the specific patterns and conventions that make your application unique. While Angular fundamentals stay consistent across projects, each application develops its own approach to common problems. This folder documents how we've chosen to solve them and why.

This becomes crucial for team consistency. New developers can understand how we build table pages, implement pagination, or handle data exports without digging through existing code to figure out our approach. Instead of reverse-engineering patterns from scattered examples, they get direct guidance on our component library structure, usage conventions, and the solutions we've refined through experience.

When AI generates new code, this knowledge ensures it follows our established patterns rather than creating components that might work but don't align with our standards. The AI understands exactly how we structure pages, organize components, and handle common scenarios.

project/
  core/
    technical-stack.md      # Tech decisions & versions
    architecture.md         # System design principles
    deployment-flow.md      # How code reaches production
  patterns/
    page-structure.md       # Standard page layout
    component-hierarchy.md  # How components relate
    data-flow.md            # State management approach
    error-handling.md       # Consistent error patterns
  recipes/
    table-with-filters.md   # Complete table implementation
    form-validation.md      # Form patterns & validation
    modal-dialogs.md        # Modal best practices
    api-integration.md      # Service layer patterns

Tools

The Tools folder tackles a real workflow problem around sharing AI setups without forcing them on everyone. This folder contains agent templates, commands, and configurations that team members can choose to adopt, rather than putting them into the repository.

Here's the issue we're solving. Claude Code creates agents by adding files to .claude/agents/, but committing these to your repo means everyone gets the same AI setup whether they want it or not. That's like forcing everyone to use identical workflows by having the same set of agents, commands, etc.

Instead, we store suggested configurations that teammates can pick and choose from. Want our Angular expert agent? Grab the tools/agents/angular-expert-agent.md. Prefer building your own? Start with our templates and customize.

These configurations get powerful when they reference your existing guides. An Angular expert agent pulls from code-style/angular/core.md. A component creator combines the Angular core code-style/angular/core.md with your component patterns code-style/angular/component-guide.md. A table generator uses your table recipes. You're not duplicating content—you're creating smart entry points into your knowledge base.

tools/
  agents/
    angular-expert.md      # Full Angular agent
    component-creator.md   # Component specialist
    test-writer.md         # Test generator
    pr-reviewer.md         # Code reviewer
  commands/
    quick-fixes.md         # Common fixes
    refactoring.md         # Refactor commands
  modes/
    plan-mode.md           # Cursor Mode to start planning
  hooks/
    pre-commit.md          # Claude Code hooks

Folder Structure Example

Here's the full folder structure bringing it all together:

knowledge-base/
  core.md                    # Index and overview

  code-style/
    angular/
      core.md                # Angular fundamentals
      components.md          # Component patterns
      services.md            # Service patterns
      directives.md          # Custom directives
      pipes.md               # Custom pipes
      ngrx.md                # State management
    html.md                  # HTML standards
    scss.md                  # Styling conventions
    typescript.md            # TS best practices
    testing.md               # Unit testing
    integration-testing.md   # Integration tests
    e2e-testing.md           # E2E strategies
    documentation.md         # Doc standards

  project/
    core/
      technical-specs.md     # Tech stack
      architecture.md        # System design
      folder-structure.md    # Project organization
      environments.md        # Dev/staging/prod
    code-style/
      design-system.md       # UI library
      shared-components.md   # Reusables
      data-selectors.md      # Test selectors
      mock-apis.md           # API mocking
      feature-flags.md       # Feature toggles
    guides/
      create-table-page.md   # Table pattern
      implement-sidebar.md   # Navigation
      form-validation.md     # Complex forms
      error-handling.md      # Error patterns
      auth-flow.md           # Authentication

  tools/
    agents/
      angular-expert.md      # Full Angular dev
      component-creator.md   # Components only
      test-writer.md         # Test generation
      pr-reviewer.md         # Code review
      refactoring.md         # Code cleanup
      bug-fixer.md           # Debug specialist
    commands/
      quick-fixes.md         # Common fixes
      generate-crud.md       # CRUD operations
    modes/
      architecture-mode.md   # System design
      learning-mode.md       # Onboarding
    hooks/
      pre-commit.md          # Validation
      post-generate.md       # After generation

Once this knowledge base lives in your repository, developers gain genuine workflow autonomy. If I want to create a Claude agent, I can build it in my own workspace and reference whatever combination of guides makes sense for my approach. Maybe I use the suggested Angular expert configuration as-is, or maybe I craft my own version that pulls from specific guides and adds my personal development preferences.

This flexibility transforms how teams approach AI-assisted development. Instead of one-size-fits-all configurations, each developer can curate their AI toolkit while still building on shared institutional knowledge. The knowledge base becomes the foundation, but the workflows remain personal and adaptable.

Hopefully I've convinced you of the benefits of having a universal knowledge base for your AI that lives outside individual tool configurations. This approach helps not just AI, but your entire team—they get written documentation on how things should be implemented, and you can reuse these documents across multiple tools. In a landscape where new AI tools keep emerging, having the freedom to choose and experiment with different workflows becomes crucial.

The three-folder structure covers this spectrum from general to specific: framework patterns in code style, project conventions, and tool-specific configurations. Each layer builds on the previous one, creating a knowledge hierarchy that scales with your needs.

Try it out, start small, and most importantly, make it fit your team's actual workflows and needs.

Create Reliable Unit Tests with Claude Code

Alfredo Perez — Fri, 02 Jan 2026 17:46:43 +0000

So you're using Claude Code to generate tests and it's creating 45 test files that check if setTimeout works. Yeah, that's not what we want. And that's in the best-case scenario.

In the worst case? The tests don't even run. Claude might use Jasmine instead of Jest even though your whole project uses Jest. Or it creates mock files for every single service, every component, every dependency—turning your test folder into a maintenance nightmare. Or tests that mock HttpClient just to verify that… HttpClient makes HTTP requests.

At this point, The AI is not useful because it is basically testing the framework instead of your application logic or creating a bunch of useless tests; in a few words, this is just AI Slop.

… But…BUT…here's the thing—with the right setup, you can transform that mess into a few focused, behavior-driven tests that actually matter.

Why Does This Happen?

The thing is, AI doesn't understand your codebase's context. It sees a component and thinks, "I should test everything!" So it tests that observables are observables. It verifies that Angular's dependency injection works. It checks if setTimeout actually sets a timeout. You know, things that the framework authors already tested for us.

And the mocks? Oh boy. Every single test creates its own mock from scratch. No sharing, no reusability. You end up with test files that are three times longer than the actual component you're testing. A 50-line component gets a 200-line test file filled with mock setup that's copy-pasted everywhere.

The AI also has this weird obsession with quantity. It thinks more tests equal better coverage, so you get 40+ tests for a simple form component. Most of them are testing edge cases that will never happen or that are already handled in other services or components. Meanwhile, the actual user flow—the thing that matters—gets buried in all that noise.

But here's the worst part: these tests are fragile. They're testing how your code works, not what it does.

Change a variable name? Tests break.
Extract a method? Tests break.
Look at your code the wrong way? You guessed it—tests break.

Refactoring and maintaining tests becomes a nightmare because you're not just updating your code; you're rewriting half your tests. and you might think, "well… we can just tell AI to refactor them," and yes, that is what we should do but if we tell it the how and why, it can create meaningful tests even in a way that we can reuse mocks or fake data for other tests or even StoryBook or Integration tests.

Teach Claude Code Your Team's Testing Style

Here's where it gets interesting. Instead of fighting with Claude Code's default behavior, we're going to teach it how to test like your team does.

Think of it like this: when a developer joins your team—whether they're senior, mid-level, or just starting out—they need to learn how your codebase works. How do you structure tests? What do you mock? What patterns do you follow? This usually happens through pair programming, code reviews, and a lot of talking, but that won't work with Claude Code. Instead, we'll write up all that information in guides that AI and even developers can use.

The approach is simple:

Create testing guides that document your team's patterns
Put them where Claude Code (and your team) can find them
Use them consistently
Keep refining them when you spot new patterns or issues

As mentioned before, the cool thing about this is that these guides don't just help AI or Claude Code; they also become your team's testing documentation. Any team member, whether new or one that has been in the company for a while, can read them to understand your testing philosophy, making code reviews easier because everyone is on the same page, and yeah, Claude code can generate better tests too or it can be used just to review your tests.

Setting Up Your Testing Guides

The Basic Structure

The first thing to do is that we're going to put all this under a knowledge-base folder with a testing folder inside, and here is the basic structure that you will have in this directory

knowledge-base/testing/
├── testing-core.md                #Foundation rules and tech stack
├── testing-components.md          #File or Type specific patterns
├── testing-services.md
├── ...
└── testing-when-using-store.md    #Special cases patterns

testing-core.md

The testing core file is the foundational file for all your testing. Here we will have all the rules that we are going to use for all our tests, and they have to be really clear and concise. This is what we should include in it:

Tech Stack
We start by specifying what the tech stack used in your application is. This can include the testing framework you are using, either Jest or Jasmine, whether you're using any library for mocking, if you're using any state management, or any other aspects related to the tech stack of the application so it knows better how to test it.

#Core Testing Guidelines

## Tech Stack
- **Testing Framework**: Jest with Angular Testing Library
- **Mocking**: ng-mocks for Angular components/services
- **State Management**: NgRx with @ngrx/store/testing
- **HTTP Testing**: Angular HttpClientTestingModule

How to test
Next, we are going to specify how we want our unit tests to be created. Like you can specify the groupings of the public methods in describe, test only behaviors or use the SIFERS pattern.

### Test Strategy
-Group public methods in describe
-Focus on testing the behaviors
-Do not test the internals of the framework or related depndencies
-Use SIFER pattern

Fakes? Mocks? What to Mock and what Not to Mock?
In the next section, I like to talk about how we're going to fake data or create mocks. This is interesting because depending on your application or your team, you might have strategies on when to use fake instead of using mocks or when to put the mocks so they can be reusable. This section is where we're going to put all the data related to that.

### Mocking Strategy

**DO Mock:**
-External API services
-Third-party libraries
-Browser APIs (localStorage, etc.)

**DON'T Mock:**
-Angular framework features
-Your own models/interfaces
-Simple utility functions

Example
Finally, we can finish the document by just including a quick example of a testing file so the agent can have better information on what we mean with all the rules.

Example

// Example: Clean test structure
describe('UserProfileComponent', () => {
  // Setup
  let component: UserProfileComponent;

  // Fakes (reusable)
  const userServiceFake = createUserServiceFake();

  // Readable tests with BDD naming
  describe('WHEN user data is loaded', () => {
    it('SHOULD display user name', () => {
      // Test focused on behavior, not implementation
    });
  });
});

Here is the complete testing-core.md we just created. Don't forget that this is just a small template to give you ideas. You should change it to fit your testing plan:

#Core Testing Guidelines

## Tech Stack
- **Testing Framework**: Jest with Angular Testing Library
- **Mocking**: ng-mocks for Angular components/services
- **State Management**: NgRx with @ngrx/store/testing
- **HTTP Testing**: Angular HttpClientTestingModule

### Test Strategy
-Group public methods in describe
-Focus on testing the behaviors
-Do not test the internals of the framework or related depndencies
-Use SIFER pattern

### Mocking Strategy

**DO Mock:**
-External API services
-Third-party libraries
-Browser APIs (localStorage, etc.)

**DON'T Mock:**
-Angular framework features
-Your own models/interfaces
-Simple utility functions

### Example

ts
// Example: Clean test structure
describe('UserProfileComponent', () => {
// Setup
let component: UserProfileComponent;

// Fakes (reusable)
const userServiceFake = createUserServiceFake();

// Readable tests with BDD naming
describe('WHEN user data is loaded', () => {
it('SHOULD display user name', () => {
// Test focused on behavior, not implementation
});
});
});

The key is keeping this file focused and practical. Don't write a novel—Claude Code needs clear, actionable guidelines it can follow immediately.

Type-Specific Guides

The second type of guides that we need to provide to Claude Code is the type-specific guides. In these guides, we're going to write how to test based on the type of file that we're going to be creating the unit test for. For example, if we want to create a component test, it's going to use something different from creating a test for a service or a utility that doesn't have any dependency injection.

The reason why we split these guides into multiple is that whenever we use them with Claude Code, we don't have to pass the whole context of how to test everything, and we can create specialized agents or commands that will know how to test that specific file. Here is an example of how to test a component.

#Component Testing Guidelines

## Component Types & Testing Approaches

### Presentational Components (No services, pure display)
-Use Angular Testing Library directly
-Focus on rendering and user interactions
-Test props/inputs and outputs/events
-Maximum 5-8 tests

### Smart Components (Connected to services)
-Mock external services only
-Test component behavior, not service implementation
-Use fakes for complex service interactions
-Focus on user workflows

## Testing Dialogs
-Don't test dialog opening/closing mechanisms (that's Angular's job)
-Focus on dialog content and user actions
-Mock DialogRef for dialog-specific behavior

## Common Mistake to Avoid
Never test framework internals:
❌ `expect(component).toBeTruthy()`
✅ `expect(screen.getByRole('heading')).toHaveTextContent('User Profile')`

Case-Specific Guides

The final type of guide is the case-specific guide. We need these guides because not all the components are created the same way nor have the same complexity. For example, there can be a component that is completely presentational and doesn't have any dependency injection. But then also you can have the case where you have a component that has state management using NgRx and also has dependencies for other services that are related to logging or to metrics, and instead of having to put all this information into the guides for components, we can isolate these case-specific guides to tell Claude what to do for case-by-case situations.

Another use case of these case-specific guides is to document the testing patterns that we are encountering. Like, for example, if we have a component that uses the user's API service instead of letting Claude Code create the user API with mock data or using ngmocks or whatever it decides at the time, we can tell it the location of the provideFakeUserApi service that we already created for other components.

Okay, so far we have created the guides that we're going to use in this case for Claude Code. Just so you know, these guides (since they are created without using anything Claude Code specific) can be reused by any other AI tools that you have. But at this time, I'm going to show you how to use them with Claude Code so they can be easily picked up by it.

Creating Agents and Commands in Claude Code

There are two ways that we can use these guides in Claude Code:

By creating an agent
By creating a slash command

The benefit of creating an agent is that Claude Code will detect whenever we are about to create a unit test and immediately load the testing agent that has access to all the rules and guides that we just created. The other way that we can use this is by creating commands where we can create a command for testing and pass which component or which file we want to create a unit test for.

Creating an Agent

Creating an agent with Claude Code is super easy because it has a slash command that can help you do it. So the only thing that we're going to do is open Claude Code and then we're going to tell it to use the /agents and we are going to select the option to Create a new agent.

After this you need to:

Select 1. Project (.claude/agents/)
Select 1. Generate with Claude (recommended)
Give it a small prompt that gives a brief description of the agent objectives and has a reference to the guides we just created

Create an agent that reads my testing guides from knowledge-base/testing and generates focused unit tests.

When generating tests:
1. Read testing-core.md for foundation rules
2. Read the appropriate specialized guide (components, services, etc.)
3. Follow BDD naming conventions (GIVEN/WHEN/SHOULD)
4. Generate maximum 10 tests per file
5. Use established fake patterns
6. Focus on user behavior, not implementation details

Always prioritize readable, maintainable tests over comprehensive coverage.

Next you will need to define which tools you want to give the agent access to, and here I usually just give access to All Tools. Then it will ask for which model you want to use, and here I pick Sonnet. Finally it will ask for the agent color and here you can pick whatever you like.

That is it! The agent file will be created at .claude/agents/ and you will get a confirmation like this:

Once this agent is created, the next time you want to create a test or Claude Code has a task to create a test, it will automatically use the test-generator-bdd agent to create it. Here is an example of how I asked to create a test.

Creating Custom Slash Commands

Let's start by defining when you would need a slash command. If you're using a Claude Code agent, whenever you begin creating a unit test, you can theoretically leverage the agent to generate it using its built-in instructions — in this case, the knowledge base we created for our testing process. However, sometimes you want to ensure the testing follows a reliable pattern or explicitly specify which files need testing. This is where custom slash commands become valuable.

Slash commands are created using Claude Code itself. The process is straightforward: prompt Claude Code to create a test command, then provide a similar prompt to what you want executed within that command.

You can even expand this approach to create more sophisticated commands. For example, you could:

Pass parameters specifying which files to test
Configure the component to use a specific mock API
Add any other explicit requirements for your unit testing workflow

This flexibility makes your testing process more targeted and consistent.

In the following example, I created a custom command using Claude Code, and this is the slash command that was generated:

---
name: test
description: "Generate focused BDD unit tests for a file using testing guidelines"
---

Generate unit tests for the specified file using the test-generator-bdd agent.

This command will:
1. Read testing guidelines from knowledge-base/testing/
2. Analyze the target code
3. Generate focused BDD-style unit tests (max 10 per file)
4. Follow project testing conventions

Usage: /test <file-path>
Example: /test src/app/users/shared/components/add-user-modal.component.ts

Let's make it more useful and add a parameter. One good example would be to test all the files changed in the current branch, and we'll likely call the command like /test --files-changed. To add this functionality, we need to specify this parameter in the same command file, and the easiest way to do it is to tell Claude to do it, and you'll get something like:

---
name: test
description: Generate focused BDD unit tests for files using testing guidelines
---

Generate unit tests using the test-generator-bdd agent.

This command will:
1. Read testing guidelines from knowledge-base/testing/
2. Analyze the target code
3. Generate focused BDD-style unit tests (max 10 per file)
4. Follow project testing conventions

Usage:
-Test a specific file: `/test <file-path>`
-Test all changed files in current branch: `/test --changed`

Examples:
-`/test src/app/users/shared/components/add-user-modal.component.ts`
-`/test --changed` (tests all modified .ts files in current branch)

When using `--changed`:
-Compares current branch against main branch
-Only processes TypeScript files (.ts)
-Excludes test files (.spec.ts)
-Generates tests for each changed component/service

Keep refining your rules

Okay, finally! But not least important—to have a successful, reliable way to create unit tests with Claude Code, I think three of the most important things are:

Good context usage. We're achieving this by creating separate files with our patterns and guides for testing, so we don't contaminate the context by having everything in a single file. We just choose what we need for the specific test we're creating.
Integration with the tools. We're achieving this by creating agents and slash commands that we can use to trigger these guides.
Good documentation. How we do testing and what patterns we follow. The most important thing here is to actually use these tools as much as possible so we can see what kind of tests they're generating. Once we review those tests, we can make decisions about whether we need to update our rules or what things we need to add. This is all with the goal that in the future, we have a better chance of creating tests the way we want them.

If you are interested in learning about more ways to use AI in your Angular projects, you might be interested in my following articles:

Create Cursor Rules for Angular

Generating Your First Rules with Cursor for Your Angular Project

Generating Your First Rules with Cursor for Your Angular Project

Alfredo Perez — Fri, 02 Jan 2026 17:46:27 +0000

Building consistent, high-quality Angular applications becomes increasingly challenging as your codebase grows and your team expands. While Cursor IDE's rule system offers powerful automation capabilities, getting started can feel overwhelming when you're staring at a blank .cursor/rules directory and you might be making the mistake of using Cursor just as a fancy autocomplete.

In our previous article, we explored the four fundamental rule types that form the backbone of Cursor's automation system:

Always Rules: Global rules that apply to every chat and command, perfect for defining how AI should respond or general behavior patterns.
Auto-Apply Rules: Rules that automatically activate based on file patterns, ideal for components, services, testing, and other file-specific guidelines
Agent-Select Rules: Contextual rules that Cursor intelligently chooses based on what you're working on, great for complex scenarios like state management or advanced routing
Manual Rules: Custom-made rules you reference explicitly, useful for unique patterns like feature flags or company-specific conventions.

Make sure to read the previous article in case you want to understand more about these rule types:

Creating Angular Guardrails: A Guide to Custom Cursor Rules for Better Code

The challenge many Angular developers face is figuring out where to start. Instead of manually crafting each rule from scratch — trying to figure out naming conventions, folder structures, and frontmatter configurations What if you could generate in a few minutes a useful starting point made specifically for Angular development?

This article introduces a meta-rule approach that provides exactly that foundation. By the end, you'll have a complete rule generation system that understands Angular project structures, automatically organizes rules by functionality, and gives you powerful prompts to generate your initial rule set based on your actual project dependencies.

Meta Rule Explanation

Before diving into our Angular-specific implementation, let's check two excellent examples that inspired this approach. Understanding these will help you understand why our improved and Angular-focused variation is better for frontend development needs.

Example 1—BMAD Method

The BMAD approach, demonstrated in this YouTube video and available on GitHub, provides a comprehensive framework for rule generation.

The key parts:

Strict Rule Type Definitions: Clearly defines the 4 frontmatter types with specific naming conventions (-manual.mdc, -auto.mdc, -always.mdc, -agent.mdc)
Technology-Agnostic Organization: Uses folders like core-rules, ts-rules, py-rules, ui-rules that scale across different tech stacks
Comprehensive Template Structure: Includes required examples (both valid and invalid), detailed glob pattern guidance, and automated confirmation responses
Built-in Validation: Enforces consistent file locations and prevents rule duplication

Here you can find a link to the meta-rule from the BMAD method:

cursor-custom-agents-rules-generator on GitHub

Example 2—Elie Steinbock Method

Elie's approach, featured in this video with the rule available on GitHub, focuses on simplicity and clarity.

The key parts:

Minimal Overhead: Provides essential structure without overwhelming complexity
Clear Directory Guidelines: Simple, straightforward placement rules that are easy to follow
Practical Focus: Shows exactly what developers need to know to get started quickly
Human-Readable Format: Uses straightforward language that both AI and team members can easily understand

Here is a link to the meta-rule:

inbox-zero cursor-rules.mdc on GitHub

While both approaches offer valuable insights into creating a meta-rule for rule management, their focus is primarily on general development scenarios. Angular projects have specific patterns—component hierarchies, state management libraries, testing strategies, and styling conventions—that benefit from a more targeted organizational approach.

Cursor Meta Rule for Angular Development

Building on the strengths of both examples, here's a meta rule specifically designed for Angular development. This rule maintains the robustness of the BMAD approach while incorporating the clarity of Elie's method, but organizes everything around how Angular developers actually think about their projects.

---
description: "This rule is essential for maintaining consistency and quality in rule creation across the codebase. It must be followed whenever: (1) A user requests a new rule to be created, (2) An existing rule needs modification, (3) The user asks to remember certain behaviors or patterns, or (4) Future behavior changes are requested. This rule ensures proper organization, clear documentation, and effective rule application by defining standard formats, naming conventions, and content requirements. It's particularly crucial for maintaining the rule hierarchy, ensuring rules are discoverable by the AI, and preserving the effectiveness of the rule-based system. The rule system is fundamental to project consistency, code quality, and automated assistance effectiveness."
globs:
alwaysApply: true
---

Rule Generation Guidelines

This document outlines the standard format for creating and organizing all AI-generated rules for this project. Its main goal is to ensure clarity, consistency, and a scalable structure.

Check for existing rules before creating new ones @.cursor/rules
Update existing rules when possible instead of creating duplicates

Organizational Folders

Do not separate by library (e.g., do not use a libraries/ folder).
Rule files must be located and named using the format: .cursor/rules/{area-folder}/{area-of-focus}-{type}.mdc. The {area-of-focus} describes the specific part of the technology or functionality the rule applies to.
.cursor/rules/global/: Rules that apply to every chat and command. Also, Cursor behavior and rule generation rules
.cursor/rules/angular/: Angular framework rules. Examples:
- For rules about Angular components: .cursor/rules/angular/component-development-agent.mdc
- For rules about Angular services: .cursor/rules/angular/services-state-agent.mdc
- For broad Angular rules: .cursor/rules/angular/global-standards-agent.mdc
.cursor/rules/state/: State management rules. Examples:
- For NGXS: .cursor/rules/state/ngxs-state-agent.mdc
- For TanStack Query: .cursor/rules/state/tanstack-query-agent.mdc
.cursor/rules/testing/: Testing rules. Examples:
- For Jest: .cursor/rules/testing/jest-testing-agent.mdc
- For Angular testing: .cursor/rules/testing/testing-standards-auto.mdc
.cursor/rules/typescript/: General TypeScript rules. Examples:
- For error handling: .cursor/rules/typescript/typescript-error-handling-agent.mdc
- For style: .cursor/rules/typescript/typescript-style-agent.mdc
.cursor/rules/styles/: CSS, SCSS, and styling rules. Examples:
- For SCSS conventions: .cursor/rules/styles/scss-conventions-agent.mdc
- For typography: .cursor/rules/styles/scss-typography-classes-agent.mdc

Metadata

The frontmatter is mandatory and determines rule application. When creating a rule, first make sure what type is it and base on that setup the metadata:

Always

Applies to all chats/commands. e.g. add emojis after reading a rule
Suffix with -always.mdc
alwaysApply: true and empty description and globs
Must be in .cursor/rules/global/

Auto-Apply

Use when the rule applies to files matching a glob.
Suffix with -auto.mdc
Requires globs pattern alwaysApply: false and description is empty

Agent Select

Use when the rules that should be applied occasionally.
Suffix the file name with -agent.mdc
Requires descriptive description. alwaysApply: false and the globs is empty

Manual (`-manual.mdc`):

This is for rules that should be manually requested by the user
Suffix with -manual.mdc
alwaysApply: false and description and globs should be empty

Glob Pattern Examples

Use these patterns in the globs frontmatter field to target specific files:

All TypeScript: *.ts
All Angular Components: *.component.ts
All State Files: state/*/.ts
All Tests: *.spec.ts
All Styles: *.scss

Description

Keep rule descriptions under 200 characters for better readability

Rule Template Structure

All rule files must follow this structure

---
description: `Comprehensive description that provides full context and clearly indicates when this rule should be applied. Include key scenarios, impacted areas, and why following this rule is important. While being thorough, remain focused and relevant. The description should be detailed enough that the agent can confidently determine whether to apply the rule in any given situation.`
globs: .cursor/rules/**/*.mdc OR blank
alwaysApply: {true or false}
---

#Rule Title

## Critical Rules

- Concise, bulleted list of actionable rules the agent MUST follow
- Rule with Example
<example>
{valid rule application}
</example>

<example type="invalid">
{invalid rule application}
</example>

Examples

Place examples immediately after their corresponding rules for clear context
Omit examples for rules that are clear without them
Keep examples brief and focused
Include only one example type when the rule is self-explanatory

Confirmation Response Format

After creating or updating a rule, send a message with this format:

🧠 Rule Generation Success: [file path]
Rule Type: [Agent Select | Auto-Apply | Global | Manual]
Rule Description: [Brief description of the rule's purpose]
Rule metadata:

Understanding the Meta Rule Structure

Let's deconstruct the key sections of our Angular meta rule and comprehend the rationale behind the design of each component.

Rules Folders

Example showing the rules folders.

The folder organization is the heart of what makes this Angular-specific. Instead of generic categories like ui-rules or ts-rules, we organize by Angular development concerns:

**/angular/** - Framework-specific patterns like component structure, lifecycle hooks, dependency injection, and routing conventions.
**/state/** - State management is complex enough to warrant its category, whether you're using NGXS, NgRx, TanStack Query, or custom solutions.
**/testing/** - Angular testing has unique patterns with TestBed, component testing, and service mocking that deserve focused organization.
**/styles/** - CSS, SCSS, and styling conventions include guidelines on working with Angular's component-scoped styles and integrating your design system.

This structure mirrors how Angular developers mentally organize their work, making rules easier to find and maintain.

Rule Template Structure

Since these rules frequently serve as team documentation, the template prioritizes human readability by showing examples immediately after the rule is stated and only when it is crucial to have them.

---
description: `Comprehensive description that provides full context and clearly indicates when this rule should be applied. Include key scenarios, impacted areas, and why following this rule is important. While being thorough, remain focused and relevant. The description should be detailed enough that the agent can confidently determine whether to apply the rule in any given situation.`
globs: .cursor/rules/**/*.mdc OR blank
alwaysApply: {true or false}
---

#Rule Title

## Critical Rules

- Concise, bulleted list of actionable rules the agent MUST follow
- Rule with Example
<example>
{valid rule application}
</example>

<example type="invalid">
{invalid rule application}
</example>

When a new developer joins your team or when you want to remember what the practices are, you can read through the rules to understand coding conventions, not just rely on AI automation.

Frontmatter Types in Angular Context

Always Rules are typically the rules you use to work with Cursor and are not closely related to Angular. Some examples of this can include how it should respond or whether it should include emojis

Auto-Apply Rules shine for file-specific patterns. For example, an auto-apply rule for *.component.ts files can enforce consistent component structure, lifecycle hook usage, and naming conventions.

Agent-Select Rules excel for contextual decisions. You might be working in a TypeScript file, but Cursor only applies your state management rules when it detects you're actually working with state—not every time you touch a .ts file.

Manual Rules are situational rules that cannot be applied solely based on file extension or file type. These manual rules can include, for example, guidelines on managing forms or feature flags.

Cursor Rule types and when to use them

How to Generate Rules

With our meta rule in place, let's explore three approaches to generating your initial rule set, from basic to advanced.

Option 1: Cursor.directory Website

The simplest approach uses the cursor.directory website. You can upload your package.json file and get a basic set of rules generated automatically.

Shows the cursor.directory website where you can generate the rules based on the package.json

Once you upload the file, it will generate all the rules based on the libraries you are using. Here's an example of what cursor.directory generates for a typical Angular project:

Shows rules generated by cursor.directory

While this file provides a starting point, the output is quite generic and doesn't leverage our Angular-specific organizational structure. This is where our custom meta rule approach really shines.

Option 2: Prompts + Meta-rule

We are going to generate the rules directly on a cursor by relying on the meta rule we just created, but we are going to use two prompts. The first prompt is about using modern Angular application best practices and the second one is about complementing with libraries from the package.json

Prompt 1. Modern Angular Development

This uses the best practices outlined by the Angular team that can be found at angular.dev/ai/develop-with-ai

Here is the complete prompt:

Generate rules for each of the following using the @generating-rules-agent.mdc :

TypeScript Best Practices

Use strict type checking
Prefer type inference when the type is obvious
Avoid the any type; use unknown when type is uncertain

Angular Best Practices

Always use standalone components over NgModules
Don't use explicit standalone: true (it is implied by default)
Use signals for state management
Implement lazy loading for feature routes
Use NgOptimizedImage for all static images.

Components

Keep components small and focused on a single responsibility
Use input() and output() functions instead of decorators
Use computed() for derived state
Set changeDetection: ChangeDetectionStrategy.OnPush in @Component decorator
Prefer inline templates for small components
Prefer Reactive forms instead of Template-driven ones
Do NOT use "ngClass" (NgClass), use "class" bindings instead
DO NOT use "ngStyle" (NgStyle), use "style" bindings instead

State Management

Use signals for local component state
Use computed() for derived state
Keep state transformations pure and predictable

Templates

Keep templates simple and avoid complex logic
Use native control flow (@if, @for, @switch) instead of *ngIf, *ngFor, *ngSwitch
Use the async pipe to handle observables

Services

Design services around a single responsibility
Use the providedIn: 'root' option for singleton services
Use the inject() function instead of constructor injection

Output of Cursor after generating the rules

You can also opt-in for just using the rules as they come from the Angular team, but with the generated one, it will create a separate file for each that can be applied as needed and it will also have some examples that can also help developers understand what the rule is about.

Prompt 2. Using installed packages

The next prompt that we can use is one that, based on the installed packages, will get the best practices for each.

Here is the prompt that you can use:

Generate Cursor rules for significant libraries in @package.json
Create a file for each library covered focusing on:

Library Selection Criteria:
- DO NOT generate rules for libraries not in package.json
- DO NOT generate rules that already exist
- DO NOT include initialization/configuration code
Rule Content Requirements:
- DO NOT include library initialization/setup code
- DO NOT include configuration examples
- FOCUS on usage patterns and best practices
- INCLUDE common pitfalls
- INCLUDE performance considerations
For Each Library Rule:
- Integration patterns
- Best practices
- Common issues
- Performance optimization
- Security considerations
- Testing strategies
Rule Format:
- Clear metadata
- Glob patterns
- Descriptive sections
- Practical examples of USAGE only
- Error prevention guidelines
Specific Exclusions:
- Configuration code
- Setup instructions
- Initialization patterns
- Module imports
- Provider configurations

Library Categories and Rules

State Management

NgRx: Store architecture, effects patterns, entity management
NGXS: Action/state/selector patterns, async operations
TanStack Query: Query invalidation, caching strategies
Akita: Entity stores, query patterns
MobX: Observable state management

Component Libraries

Angular Material: Theming, accessibility, proper component usage
PrimeNG: Component configuration, theming
Nebular: Theme system, component integration
Clarity Design System: Design tokens, component patterns

Testing Libraries

Jest: Configuration, mocking patterns, coverage
Cypress: E2E patterns, page objects, custom commands
Playwright: Cross-browser testing, fixtures
Testing Library: User-centric testing approaches

Build & Architecture (DO NOT ADD ANYTHING)

Nx
Angular CLI
Module Federation

Forms Libraries

Formly: Field configuration, custom field types
Dynamic Forms: Form generation, validation patterns

Internationalization

Transloco: Translation management, lazy loading
ngx-translate: Translation patterns, runtime language switching

Data Visualization

D3: Chart patterns, data binding, animations
Chart.js: Configuration, responsive charts
NGX-Charts: Data formatting, theme integration

Authentication

Auth0: Authentication flows, guard patterns
Firebase Auth: Authentication state, security rules
JWT: Token management, refresh patterns

After generating rule add which metadata should be used. e.g.

accessibility-agent.mdc
description: (The description)
alwaysApply (true/false)
globs: (The glob pattern)
Example of what NOT to include (initialization/configuration code):

export const translocoLoader = {
  provide: TRANSLOCO_LOADER,
  useFactory: (http: HttpClient) => new TranslocoHttpLoader(http, './assets/i18n/', '.json')
};

@NgModule({
  imports: [TranslocoRootModule, TranslocoModule],
  providers: [
    translocoLoader,
    {
      provide: TRANSLOCO_CONFIG,
      useValue: {
        fallbackLang: 'en',
        reRenderOnLangChange: true,
        defaultLang: 'en'
      } as TranslocoConfig
    }
  ]
})

This is what Cursor does; note that it only picked three libraries and also checked for any existing rules:

Now, if you go to Cursor settings, and under the Rules section, you should see all the rules that were created:

Cursor Rules Settings with all the rules that were created

Troubleshooting

Sometimes things don't go as planned, and the rules might not turn out the way we expected. Before moving forward, I suggest checking a few things. You can either give the prompt another shot, try a new one that points to the meta-rule, or fix any issues that popped up.

Here are the things you should check:

Folder Structure
Metadata
File Suffix
Content

Pay special attention to the content, since AI tends to be verbose, and there might be a thing or two you can cut off.

Also, I recommend you set the following User Rules in Cursor to always use:

Verify Cursor was able to find the rules:

Verify you can read the rules from .cursor/rules/
and output 🟢 if you were able to read rules
or 🟥 if you did not find anything.

List all the rules used:

After using a rule, output:
⚡ Rules Used:

Bulleted list of Rule names

TLDR

Creating effective Cursor rules for Angular development doesn't have to start from scratch. By implementing a well-designed meta rule, you can:

Generate comprehensive starting points using prompts that understand your project's actual dependencies
Maintain consistent organization with Angular-focused folder structures that match how you think about development
Evolve rules iteratively as your team discovers new patterns and refines existing conventions

The most important success metric isn't perfect automation—it's team engagement with rule refinement. When developers actively suggest rule updates and modifications, it means they're using the system and finding value in the consistency it provides.

Remember that rule creation is fundamentally an iterative process. Your team might prefer more concise rule formats, different organizational structures, or additional examples. The meta-rule approach gives you a solid foundation to customize according to your specific needs.

To generate rules for your project, you just have to do the following:

Create the meta-rule in ./cursor/rules/global
Use the prompt to create rules from Angular Team recommended rules
Use the prompt to create rules based on your package.json

What's Next

In upcoming articles, we'll explore advanced rule generation techniques, including:

Rules maintenance. How to update rules as you develop and learn new patterns
Creating rules from external sources using tools like Notebook LLM, Gemini, and content from articles or YouTube videos
Using Cursor Notepads to create reusable templates and guides for specific application patterns
Integrating rule generation with existing code analysis and documentation tools

Try it yourself: Implement the Angular meta rule in your project and experiment with the generation prompts. Share your rule variations and let us know what works best for your team's specific Angular development workflow.

Create Cursor Rules for Angular

Alfredo Perez — Fri, 02 Jan 2026 17:46:03 +0000

Ever feel like you're fighting an uphill battle to maintain coding standards across your Angular project? Many of us have. You establish style guides, meticulously review PRs, and hold team meetings — yet, inconsistencies often creep in. Component structures vary, naming conventions drift, and that agreed-upon state management pattern? It can sometimes feel more like a suggestion than a firm rule.

What if your editor could help enforce these standards as your team codes? Enter Cursor AI's rules system — a significant advantage for Angular teams aiming to maintain consistency without constant manual oversight.

What Are Cursor Rules?

Cursor Rules are persistent, reusable instructions that guide Cursor's AI as it assists with your code. Think of them as "system prompts" active across your interactions, ensuring the AI consistently adheres to your team's standards and best practices.

For Angular developers, rules are particularly effective because the framework itself has many established opinions and patterns:

Component structure and lifecycle management
Naming conventions
Reactivity patterns
Forms
Tables
Use of signals vs observables
State management approaches

Without guidance, an AI assistant might generate technically correct code that clashes with your project's conventions. Rules address this by embedding your standards directly into the AI's decision-making process.

Crucially, these rules also benefit developers directly. They serve as a readable, up-to-date reference for team guidelines. It's a win-win: the AI performs more effectively, and your team has a clear, current source for coding standards.

Understanding the .mdc structure

Cursor stores project-specific rules as Markdown Component files (.mdc) within a .cursor/rules directory at the root of your project. This allows your rules to be version-controlled alongside your codebase — a major asset for team consistency.

Consider the basic structure of an .mdc rule file:

---
description: ""
globs:
alwaysApply: true
---

## Section
- Rule
- Rule

<example type="valid">
</example>

<example type="invalid">
</example>

- Rule
- Rules

This basic structure places metadata at the top — configuring where and when rules apply — followed by the rules themselves, with examples if necessary.

Rule Types

By working with the three metadata options ( description , globs, and alwaysApply), we can organize Cursor rules into four distinct types.

Next, I'll describe each type, its setup, and a suggested suffix for easy identification:

Auto Rule

These rules are automatically applied based on the file patterns you're working with.

For the metadata, only the globs needs to be configured, enabling Cursor to identify which files are being modified and apply the rules automatically.

---
description: # Optional: A brief note about the rule's purpose
globs: ["*.component.ts", "src/app/components/*.ts"]
alwaysApply: false # Default, can be omitted if false
---

For this type of rule, use the suffix auto, e.g., .cursor/rules/angular-component-auto.mdc.

An example of an Auto Rule for Angular components is shown below, enforcing standards whenever working on such files:

---
globs: ["*.component.ts", "src/app/components/*.ts"]
---

# Angular Component Standards

All components should follow these standards:

## Structure

- Use standalone components when applicable
- Property order:

Injected services (using `inject()`)
Inputs
Outputs
Signals

Other properties
Method order:
Public methods
Protected methods
Private methods

## Modern Angular Features

Use `input()` and `input.required()` instead of `@Input()`
Use `output()` instead of `@Output()`
Use `model()` for two-way binding
Use `inject()` for dependency injection
Avoid `public` accessor
Use `protected` when possible

## Event Handling

Output names should be the action (e.g., `click`, `submit`)

Handler methods should use `on` prefix (e.g., `onClick`, `onSubmit`)

Example: `<button (click)="onClick($event)">`

## Example:

```

typescript
@Component({
selector: 'app-feature',
templateUrl: './feature.component.html',
styleUrls: ['./feature.component.scss'],
changeDetection: ChangeDetectionStrategy.OnPush,
imports: [CommonModule, RouterModule, SharedModule],
standalone: true,
})
export class FeatureComponent implements OnInit {

// 1. Injected services (using inject())
private readonly featureService = inject(FeatureService);
private readonly cdr = inject(ChangeDetectorRef);

// 2. Inputs
data = input<FeatureData | null>(null);
requiredId = input.required();

// 3. Outputs
click = output();
submit = output();

// 4. Signals
loading = signal(false);
items = signal<Item[]>([]);

// Computed signals for derived state
hasItems = computed(() => this.items().length > 0);
itemCount = computed(() => this.items().length);

// 5. Other properties
// (none in this example)
constructor() {
// Use effects for reactive behavior with signals
effect(() => {
const currentData = this.data();
if (currentData) {
// Handle data changes
this.items.set(currentData.items || []);
}
});
}

ngOnInit(): void {
// Component initialization
}

// 1. Public methods
onClick(event: Event): void {
this.click.emit({ type: 'action', event });
}

onSubmit(formData: FormData): void {
this.submit.emit(formData);
}

// 2. Protected methods (when needed)
protected handleData(data: Item[]): void {
this.items.set(data);
}

// 3. Private methods
private updateLoadingState(isLoading: boolean): void {
this.loading.set(isLoading);
}
}

Always Rule

These rules establish foundational guidelines that apply to all AI interactions within your project. Since these are always applied, we don't need to set the globs or the `description fields.


markdown
---
alwaysApply: true
---

For this type of file, you can use the suffix of always, e.g., .cursor/rules/angular-always.mdc. Always Rules are particularly useful for enforcing core Angular practices across your project, such as consistent use of standalone components, proper dependency injection patterns, OnPush change detection strategy, and standardized error handling in HTTP interceptors.

Here is an example of an Always Rule for Global Angular conventions:


markdown
---
alwaysApply: true
---

# Global Angular Conventions
These conventions apply to all Angular code in this project:

## Core Principles
- Write clear, maintainable, and scalable code
- Apply immutability and pure functions
- Favor component composition for modularity
- Use meaningful variable names (e.g., `isActive`, `hasPermission`)
- Follow Angular's official style guide

## File Structure & Naming
- Use kebab-case for all files
- Components: PascalCase with Component suffix (UserProfileComponent)
- Services: PascalCase with Service suffix (AuthenticationService)
- Interfaces: PascalCase with prefix I (IUserProfile) or descriptive name (UserProfile)
- Enums: PascalCase (UserRole)
- Constants: UPPER_SNAKE_CASE (API_ENDPOINTS)

## Import Order
1. Angular core and common modules
2. RxJS modules
3. Other Angular modules
4. Application core imports
5. Shared module imports
6. Environment-specific imports
7. Relative path imports

## Code Style
- Use TypeScript strict mode
- No any types - use proper typing or unknown if necessary
- Prefer const over let, avoid var
- Use async/await when possible instead of Promise chains
- Document public APIs with JSDoc comments

## Structure
- Organize code by feature modules
- Keep components under 300 lines where possible
- Extract complex logic to services
- Use smart/dumb component pattern:

Smart (container) components handle data and state

Dumb (presentation) components receive inputs and emit outputs

## State Management
- Use NgRx for global application state
- Use component state for UI-only concerns
- Use services with signals for shared state within a feature

Agent Requested Rules

These are context-specific rules that the AI can intelligently pull in based on task relevance. The descriptionfield must provide comprehensive context about when to apply the rule, while globs should be left blank and alwaysApply should be false.


markdown
---
description: "Guidelines for implementing modern Angular patterns using signals and defer blocks"
---

For this type, use the suffix -agent.mdc, e.g. .cursor/rules/rxjs-state-agent.mdc .

Agent Requested Rules are perfect for specialized Angular patterns that only apply in certain contexts, such as implementing NgRx selectors, setting up complex RxJS operator chains, configuring route guards, or implementing custom form validators.

An example of an agent-requested rules could be to apply modern angular patterns to use signals, like the following:


`markdown
---
description: "Guidelines for implementing modern Angular patterns using signals and defer blocks"
alwaysApply: false
---

# Modern Component with Signals and Defer
## Core Rules

Use signals for all component state
Implement computed values for derived state
Use @defer for lazy loading heavy components
Leverage new control flow syntax (@if, @for)
Keep components standalone by default

## Best Practices

Use inject() for dependency injection
Implement proper cleanup in effects
Use proper typing for signals
Keep components focused and small
Use proper error boundaries

```ts
@Component({
  selector: 'app-user-list',
  standalone: true,
  imports: [CommonModule],
  template: `
    @if (loading()) {
      Loading…
    } @else {
      @for (user of users(); track user.id) {
        {{ user.name }}
        {{ user.email }}
      } @empty {
        No users found
      }
    }

    @defer (on viewport) {
      <app-user-stats />
    } @loading {
      Loading stats…
    }
  `
})
export class UserListComponent {
  private readonly userService = inject(UserService);

  // State with signals
  loading = signal(false);
  users = signal<User[]>([]);

  // Computed values
  userCount = computed(() => this.users().length);
  activeUsers = computed(() =>
    this.users().filter(user => user.status === 'active')
  );
}
```
`

Manual Rules

These are specialized rules intended for application only when explicitly requested. For this type, the description and globs fields should be left blank, and alwaysApply set to false. This approach is ideal for specific patterns in less common tasks, like internationalization setup or complex authentication flows.


markdown
---
# No metadata flags needed
alwaysApply: false # Explicitly set to false or omit
---

For this type, use the suffix -manual.mdc, e.g., .cursor/rules/i18n-setup-manual.mdc.

This approach is ideal for specific patterns in less common tasks, like implementing custom form validators with signals, setting up complex animations with the new animation API, or creating custom structural directives with modern Angular features.


`markdown
---
---
# Custom Form Validator with Signals

## Core Rules

Use signals for reactive form validation
Implement computed values for error messages
Use proper typing for form controls
Keep validation logic in separate methods

## Best Practices

Use inject() for dependency injection
Implement proper form cleanup
Use proper typing for validators
Keep validation rules focused and small

```ts
@Component({
  selector: 'app-password-form',
  standalone: true,
  imports: [CommonModule, ReactiveFormsModule],
  template: `
    @if (passwordError()) {
      {{ passwordError() }}
    }
  `
})
export class PasswordFormComponent {
  private readonly fb = inject(FormBuilder);

  form = this.fb.group({
    password: ['', [Validators.required, this.passwordStrengthValidator()]]
  });

  passwordError = computed(() => {
    const control = this.form.get('password');
    if (!control?.touched) return null;

    return control.errors?.['passwordStrength']?.message;
  });

  private passwordStrengthValidator(): ValidatorFn {
    return (control: AbstractControl) => {
      const value = control.value;
      if (!value) return null;

      const hasUpperCase = /[A-Z]/.test(value);
      const hasLowerCase = /[a-z]/.test(value);
      const hasNumber = /[0-9]/.test(value);
      if (!hasUpperCase || !hasLowerCase || !hasNumber) {
        return {
          passwordStrength: {
            message: 'Password must contain uppercase, lowercase, and numbers'
          }
        };
      }
      return null;
    };
  }
}
```
`

Lets see it in action

Okay, okay… we talked about the four rule types, but do they actually do anything? Let's see how AI generates a component both with and without rules. I used a prompt to generate a basic Users Page component that gets data from a user service.

First, here's a basic component without rules:


markdown
@Component({
 selector: "app-users",
 templateUrl: "./users.component.html",
 styleUrls: ["./users.component.scss"],
})
 export class UsersComponent implements OnInit {
 @Input() title: string = "Users";
 @Output() userAdded = new EventEmitter<User>();

 public users: User[] = [];
 public loading = false;
 private userService: UserService;

 constructor(userService: UserService) {
 this.userService = userService;
}

ngOnInit() {
 this.loadUsers();
}

loadUsers() {
 this.loading = true;
 this.userService.getUsers().subscribe({
 next: (users) => {
 this.users = users;
 this.loading = false;
},
error: (error) => {
 console.error("Error loading users:", error);
 this.loading = false;
 },
});
}

addUser() {
// Add user logic
 this.userAdded.emit(newUser);
}
}

Now, here's the same component following the rules about components that was shown in this article, and this is the result:


markdown
@Component({
selector: "app-users",
standalone: true,
imports: [CommonModule, MatTableModule, MatButtonModule],
templateUrl: "./users.component.html",
})
export class UsersComponent {
// 1. Injected services
private readonly userService = inject(UserService);
private readonly cdr = inject(ChangeDetectorRef);
// 2. Inputs
title = input("Users");
// 3. Outputs
userAdded = output();
// 4. Signals
loading = signal(false);
users = signal<User[]>([]);
// 5. Other properties
displayedColumns = ["name", "email"];
// Computed values
userCount = computed(() => this.users().length);
constructor() {
// Effect for data loading
effect(() => {
this.loading.set(true);
this.userService.getUsers().subscribe({
next: (users) => {
this.users.set(users);
this.loading.set(false);
},
error: (error) => {
console.error("Error loading users:", error);
this.loading.set(false);
},
});
});
}
// 1. Public methods
onAddUser(): void {
const newUser = { name: "New User", email: "new@example.com" };
this.userAdded.emit(newUser);
}
// 2. Protected methods (none in this example)
// 3. Private methods
private updateLoadingState(isLoading: boolean): void {
this.loading.set(isLoading);
}
}

The result? The code doesn't just look cleaner — it actually runs better and becomes far easier to maintain over time. But here's the real win: once you've established these rules, every component you build or refactor automatically follows the same patterns. No more style debates, no more inconsistent architectures across your team.

Of course, there's a learning curve. The system will occasionally drop in unnecessary comments or make decisions that feel off. In the next few articles, we'll dive into fine-tuning these rules and building safeguards to catch problematic output before it becomes a headache….and useless.

TL;DR

Thera are different rule types from Cursor that can be used in Angular projects to enhance AI assistance:

Auto rules are frequently applied automatically based on specific file patterns, making them perfect for file-specific tasks. These are useful for specific file like *.component.ts and can specified things like component structure, and service patterns.
Always rules are constant and apply across the entire project, triggered during every AI interaction to uphold core principles, naming conventions, and import order. This are useful for enforcing core Angular practices across your project, like core principles, naming conventions, and import order.
Agent rules are used with medium frequency and are context-specific, determined by the AI based on relevance, making them suitable for state management tasks like RxJS/Signals and NgRx setup.
Manual rules are less common and are used for specialized tasks that require explicit requests, such as migration guides, internationalization (i18n) setup, and complex authentication flows.

This hierarchy ensures the AI isn't overwhelmed with too much context while still providing the necessary guidance when needed.

Implementing custom Cursor rules for your Angular project establishes guidelines that gently guide both your team and the AI toward consistent, high-quality code. By codifying your standards directly within your development environment, you reduce cognitive load, minimize code review debates, and help maintain architectural integrity.

Rules become particularly valuable as your team grows or as you integrate AI more deeply into your workflow. They ensure that regardless of who (or what) is writing the code, it adheres to the same consistent patterns.

In the next article, we'll build on this foundation and explore how to create and maintain your rules for your angular project by providing a custom structure and an easy way to update them.

Faster Development with JetBrains AI

Alfredo Perez — Fri, 06 Sep 2024 15:42:00 +0000

It's safe to say that AI is everywhere these days, especially with all the coding options like GitHub Copilot, TabNine, and Cursor. So, I figured it was a good time to try out the AI features in my go-to IDE, WebStorm.

JetBrains AI Assistant is an integrated artificial intelligence feature within JetBrains' suite of IDEs, such as IntelliJ IDEA, PyCharm, and WebStorm. It provides various functionalities to enhance the coding experience, including:

Code Completion: offers intelligent code suggestions and autocompletion to speed up coding and reduce errors.
Documentation Generation: Automatically generates documentation for classes and methods based on the code context.
AI Chat: Allows developers to interact with an AI assistant directly within the IDE to ask questions, get code examples, and receive coding advice.
Code Refactoring: assists in refactoring code by providing suggestions and automating repetitive tasks.
Error Detection: Identifies potential errors and suggests fixes to improve code quality.

These features aim to improve developer productivity, code quality, and overall efficiency in the software development process, but please note that in order to get JetBrains AI Assistant, you will need to pay for a separate subscription on top of the WebStorm or IntelliJ subscription.

Here are the goals I aimed to achieve:

Write Documentation: The first task was to write JS Docs for all the public methods and the class itself.
Create Unit Tests: Next, I wanted to add some missing tests.
Improve Code: After completing the tests, I aimed to enhance the code for better readability and reduced cognitive load.
Commit the Code: Once all the refactoring was done, I just needed to create a commit message to make a pull request.

Write Documentation

OK, let’s get started. The first thing I want to do is write documentation for all the methods in this class, as well as for the class itself.

There are a couple of ways I could achieve this. I could start typing and see what the AI suggests, or open the chat and ask for the documentation. The route I took was to right-click on the method name and select the option to "Write Documentation."

Prompt Library

What's interesting about JetBrains AI is that it provides a set of actions that can be executed with just a right-click. It also has a prompt library where you can specify exactly what prompt to use while an action is being executed.

For example, when I click on "Generate Documentation," I can add a set of rules for how I want the documentation to be generated, such as not adding author, version, or any other tags I feel are unnecessary. This is really useful because I can teach JetBrains AI how I like things to be done.

Here is an example prompt I am currently using for my documentation:

- Do not use @author or @version or @since tags.
- DO NOT use html tag s such as <p>, <lu>, <li>.
- DO NOT add type for the params
- DO NOT add type for the return value
- If it is a method, DO NOT generate example usage.
- If it is a method, DO NOT generate usage example.
- When the method does not return anything, write "This method does not return any value."

Write JSDocs

Note that I had to specify what to write when the method doesn't return anything to keep things consistent. Since it's generated with AI, it might create different messages for the same situation.

Another interesting feature is that you can ask things directly in the code. For example, if you don’t like how the documentation was generated, you can open the AI tool next to the line where the documentation was created and ask to regenerate or add anything that is missing.

In the following example, you can see how I asked it to add the example field and it was able to event document how the service should be used.

Thanks to all this, I was able to generate the service, and now whenever I hover over in the IDE, I can see beautiful documentation. ✨

Creating tests

Adding documentation was easy enough and can be done with any AI tool. However, we discovered the Prompt library and that JetBrains AI tool is context-aware. Moving on to my next task, I needed to add some unit tests. To my surprise, there is also a prompt to generate unit tests. This time, I decided to modify the prompt to specify how I want the test structure and which testing tools I use.

Here is how the prompt ended up:

- Try to avoid brackets in arrow functions
- Use the ngMocks.faster(); before the first `beforeAll` or `beforeEach` statement, but inside the first `describe`
- Use the MockBuilder from ng-mocks and Mock every dependency 
- Add an extra `beforeEach` to define the current service tha is being tested

- Group tests by the public methods in the class and create a `describe` for each
- Add `it` statements of what should be tested 
- Test failing cases

- Add test implementation
- when using spies, make sure use `.toHaveBeenCalledWith`
- Put mock data should be under an object call `data`
- Use short names for the mocked data and assuming it is context aware
- Do NOT add urls and requests if the service doesnt make API requests
- Do NOT write code comments explaining the testss
- Add clear fail messages into the assertion calls.

So now, with the prompt created, I right-clicked on the class name and selected 'Generate Unit Tests.' It not only generated the tests but also created a file for them. This is a huge plus for me because, with a single click, I can generate tests and then just need to review them.

Improve Code

Now that I had the unit tests ready, it was time to find ways to improve the code, knowing I could re-run the tests to ensure nothing breaks. To do this, I opened the chat and typed the prompt to improve the code. I specified the file by using # and selecting the class I was working on.

I really like that I can use autocomplete inside the chat. This allows me to create more detailed prompts where I can ask about multiple files or classes.

Once the prompt ran, it showed me several ways to improve the code and explained how each improvement was made.

One thing I really liked is that the code is collapsible, has scrollbars, and even uses the same theme as the IDE. This makes it so easy to navigate and read.

Commit Code

The code was well-documented, tested, and improved; the next step was to commit and Let It Rip! And to accomplish this last step, I also utilized JetBrains AI, which also offers a method to generate commit messages directly from the "Commit" tool window, as you can see in the screenshot below:

Here is the prompt I used:

- Use Conventional Commit format
- Avoid overly verbose descriptions or unnecessary details.
- Start with a short sentence in imperative form, no more than 50 characters long.
- Then leave an empty line and continue with a more detailed explanation.
- Use bullet point for  multiple changes

Extra — Creating your own prompt

I was feeling inspired and liked the results so far, so I was thinking that I could extend my usage of JetBrains AI by creating a custom prompt to create StoryBook Story for a component.

Below, you can see the prompt I created. You might notice it includes "$Selection." This tells JetBrains AI to use the selected code as the context for the prompt:

- Create a StoryBook Story for $SELECTION
- The first story should be called `Default` and should not modify any input
- Avoid using template or HTML when defining a story
- Prefer modifying just inputs in the stories
- Add one story for each input 
- Do NOT add instructions about how to setup StoryBook
- Add all the stories

After selecting the component, right-clicking, and choosing the new prompt, an AI Chat tool window opened with the prompt and the story itself.

Once again, having a prompt library is a huge win since you can evolve it and generate the perfect results for your needs.

Wishlist

I enjoyed working with JetBrains AI and I am excited to see how it improves with future releases. Here are some things on my wishlist for JetBrains AI:

Specify File Name: I would like to specify the file name whenever the prompt generates a file. For example, when I generated unit tests, it used the prefix "tests.ts." It would be great to specify "specs.ts" or any other preferred name.
Create Files: Having a prompt library is fantastic, but it would be even better if the prompt could generate a new file with a specified name format by default. This would be very helpful for generating unit tests, mock data files, stories, component tests, etc.
Better Code Replacement: I would like it to be smarter about where to replace code. Sometimes, when you ask for something, it requires changes in multiple places. For example, it might need to add a new property in an interface, modify a method, and update the test. In these cases, it would be great to define which files to modify and which ones need more refinement.

Conclusion

Both JetBrains AI Assistant and GitHub Copilot are designed to make coding easier with AI, but they each bring something unique to the table.

JetBrains AI Assistant is tightly woven into JetBrains' suite of IDEs. It offers a smooth and powerful experience with features like smart code completion, automatic documentation, AI-driven chat support, code refactoring, and error detection. This deep integration means it’s more context-aware and customizable, giving developers a tailored development environment.

GitHub Copilot, on the other hand, shines when it comes to code completion and suggestions, especially in Visual Studio Code. It pulls from a vast library of public code repositories to help generate code snippets and complete lines of code. However, it doesn’t offer the same level of IDE-specific features that JetBrains AI Assistant does, like automatic documentation and advanced refactoring tools. Also, in my opinion, Copilot creates better code and understands the context really well.

In short, JetBrains AI Assistant offers a more comprehensive toolkit for developers working in JetBrains IDEs. It's a powerful companion, particularly for those who appreciate a highly customizable and context-sensitive coding assistant.

TanStack Query in Angular

Alfredo Perez — Mon, 06 May 2024 17:41:36 +0000

TanStack Query is a powerful data synchronization library that enables efficient handling of server state in web applications. It’s widely used in React applications, but lately it has been making noise in Angular since it is a library that can provide a lot of functionality out of the box to handle all the server state of our applications with a few lines of code and, with that, reduce the amount of boilerplate code.

Server State vs Client State

To fully appreciate TanStack's benefits, it is useful to have a basic understanding of the two types of states—server state and client state—that we must control while developing the UI.

Client State

This state is related to the state that is used in order to know what the user has been interacting with. For this state, I see that there are three levels: component, feature, and global state.

Component State: This is the most basic of the states, and it is used within one or multiple components that work together to achieve a specific goal. It is agnostic of the domain or context. This state helps to communicate with child or sibling components, and one example of this is the state of a data table where the pagination component and search input need to keep their states to communicate what is currently being displayed.
Feature State: This is the state that is shared among a group of container or presentational components in the same feature and helps to share state-related information that belongs to a specific domain or feature. An example of this is a multi-step form for an entity where we need to keep track of the current step the user is in, the selected item, or even the data needed for the form fields.
Global State: This is a state that is shared in all the applications and can be things like current user information and which features are enabled for them.

Server State

This is all the async data that comes from the API requests, GraphQL, or any kind of server. This state is usually kept in order to have a better UI since we have a single place where we can keep track of all the data that we get from the server.

From all these states that we need to keep track of, the server state tends to be the biggest one we need to keep track of since it might be needed for each entity, and for the component and feature states, you can use different strategies like services or container components before having to need a full-fledged state system like a component or signal store.

TanStack Query replaces the boilerplate code and related wiring used to manage cache data in your client-state and replaces it with just a few lines of code.*

In the following image, you can see how the request is done using TanStack Query and that will return us a signal that has the state of the request, which we will explore in more detail further down in the article.

TanStack Query provides tools for fetching, caching, synchronizing, and updating asynchronous data without having to manage the complexities of updating UIs, caching data, and managing errors or loading states manually.

Here is a list of all the features that TanStack Query offers from the official website:

but ENOUGH!… Let's see it in action 👀

In the following section, I will show you how you can install and use it while highlighting some of the features it offers that barely scratch the surface of the whole set of things you can do with it.

TanStack Query in Angular

There are currently two libraries for Angular that have implemented TansStack Query, one by ngneat that can be used with observables and signals, and the other by TanStack that is in the experimental phase and only works with signals. Both are good, but I will show you how to use the one by the TanStack team.

ngneat / query

🚀 Powerful asynchronous state management, server-state utilities and data fetching for Angular Applications

The TanStack Query (also known as react-query) adapter for Angular applications

Get rid of granular state management, manual refetching, and async spaghetti code. TanStack Query gives you declarative, always-up-to-date auto-managed queries and mutations that improve your developer experience.

Features

✅ Observable & Signal Support
✅ Backend agnostic
✅ Dedicated Devtools
✅ Auto Caching
✅ Auto Refetching
✅ Window Focus Refetching
✅ Polling/Realtime Queries
✅ Parallel Queries
✅ Dependent Queries
✅ Mutations API
✅ Automatic Garbage Collection
✅ Paginated/Cursor Queries
✅ Load-More/Infinite Scroll Queries
✅ Request Cancellation
✅ Prefetching
✅ Offline Support
✅ Data Selectors
✅ SSR Support

Motivation

Discover the innovative approach TanStack Query takes to state management, setting it apart from traditional methods. Learn about the motivation behind this design and explore its unique features here.

Installation

npm i @ngneat/query

Stackblitz Example

Please be aware that the @tanstack/query-core package must also be installed for the functionality to operate…

View on GitHub

TanStack / query

🤖 Powerful asynchronous state management, server-state utilities and data fetching for the web. TS/JS, React Query, Solid Query, Svelte Query and Vue Query.

Become a Sponsor!

TanStack Query

An async state management library built to simplify fetching, caching, synchronizing, and updating server state.

Protocol‑agnostic fetching (REST, GraphQL, promises, etc.)
Caching, refetching, pagination & infinite scroll
Mutations, dependent queries & background updates
Prefetching, cancellation & React Suspense support

Read the docs →

Get Involved

We welcome issues and pull requests!
Participate in GitHub discussions
Chat with the community on Discord
See CONTRIBUTING.md for setup instructions

Partners

We're looking for TanStack Query Partners to join our mission! Partner with us to push the boundaries of TanStack Query and build amazing things together.

LET'S CHAT

Explore the TanStack Ecosystem

TanStack Config – Tooling for JS/TS packages
TanStack DB – Reactive sync client store
TanStack DevTools – Unified devtools panel
TanStack Form – Type‑safe form state
TanStack Pacer – Debouncing, throttling, batching
TanStack Query – Async state & caching
TanStack Ranger – Range & slider primitives
TanStack…

View on GitHub

Getting started

To install the library and the developer tools, we will use the following commands:

Once you have it installed, you will need to add the provider to the application and developer tools to the main component

The developer tools are added to the main component, and they will show up as a floating button that enables and disables the developer tools.

To make a request, you have to construct a query that requires a queryKey that should be serializable and unique to the query’s data since it is the main thing that TanStack Query uses to cache the data. Also, it requires a query function to be used to make the API request and the returned data will be linked to the query key.

Once we have this, the usersQuery will have the state of the request as a signal, like usersQuery.isPending() or,usersQuery.isError() and the data will also be able to be accessed at the usersQuery.data() signal.

The developer tools are composed of three sections. In the left menu section, it displays all the queries and mutations that have been executed, and you also have some tooling to filter, sort and order them. At the top, you can see the state that they are in, and there are also some controls to remove all the data or even simulate offline mode.

Once you select a query, you will see in the top right section query details that go from the query that was used to its current state and how many observers are linked to this query. This is especially useful since every observer will be notified of any changes if the query data changes.

Also, you will see a set of controls to troubleshoot or see how the UI behaves by triggering different states for the query.

Finally, at the bottom part, you will find an explorer for the data and a query that will help a lot while debugging what data was used or is currently cached.

Mutations

Mutations are the way to update the data and can be used when updating, deleting, or creating new items. It requires a mutation key and function as well, but it can also take which query keys to invalidate, meaning that once the mutation is done, any observer that has a query with the same key will automatically re-fetch data.

In the following GIF, you can see how the data grid in the background is automatically updated after performing the mutation, and this is because it was specified which query key to invalidate, and the data grid has an observer for that key.

But this is not all! TanStack Query offers offline support, which means that all the mutations will be executed once it comes back online and it will also refresh all the observers for the related queries.

In the following GIF, you can see a demo of this, where, by using the developer tools offered by TanStack query, we can simulate offline mode and try to add a new user once we go back online. On the right side, you can see that the requests were executed, and now the data grid shows the updated list of users.

Conclusion

TanStack Query is a library that can be used to handle all the server-state and thanks to it, you will get a lot of benefits out-of-the-box without having to implement custom solutions or write a lot of boilerplate code.

Once you start using it, you will realize that there is not a lot of state to handle, and for the left-over, you might only need a light-weight and extensible solution like a Service with Signals or the Signal Store.

Stay tuned, since I am working on follow-up articles exploring how to integrate it with the API service pattern I previously talked about and other more advanced features like using local storage to create a bullet-proof offline solution.

For more articles and tips for better DevX and CX with Angular, Cypress, and Web Development, you can find me at:

https://twitter.com/alfrodo_perez

https://www.linkedin.com/in/alfredo-perez/

Learnings from Accessibility Workshop from Enterprise NG 2020

Alfredo Perez — Mon, 23 Nov 2020 15:57:15 +0000

Here are some of the interesting points from the Build for Accessibility with Angular workshop by Martine Dowden and Michael Dowden

Labels are only for form fields. Do not use labels anywhere else
Wave can be used to see the page structure

AXE provides detailed information and links about the problem and possible resolutions

Use unit tests that test for accessibility-related attributes like roles and aria labels

it('icon butttons should have aria labels', ( ) => {
 const iconButtons = fixture.debugElement.nativeElement.querySelectorAlK'button[mat-icon-button]'); 
 const missingLabels => Array.from(iconButtons).some((button: HTMLElement) => ¡button.getAttribute('aria-label'); 
 expect(missingLabels).toBeFalsy();
});

it('mat list should have a role of list', () => {
 const list = fixture.debugElement.nativeElement.querySelector('mat-list'); 
 expect(list.getAttribute('role*)).toEqual('list');
});

Prefer the use of the attribute type="submit" for the buttons in the form instead of calling the method to submit from the click handler

Prefer to enable/disable instead of showing/hiding when it is needed to show data depending on a condition. This helps to avoid confusing the user and having UI jumping around.
Links are links. Buttons are buttons. Div and spans are not buttons nor links. Divs and spans miss some accessibility features for example they are not focusable and cannot be disabled.
When having a link that is only an icon, use the aria-hidden="true" and add a label

<a href="profile" 
   aria-label="Profile">
 <i aria-hidden="true"
    classss="material-icons">
   Face
 </i>
</a>

You should always have the alt attribute on images, however, it can be blank. The alt should describe what the image is trying to convey.
Decorative images can have an empty alt attribute or have a role="presentation"
In alerts or notifications use role="alert", also use aria-live="polite" for status notifcaions and aria-live="assertive" for something that requires attention

Chrome Developer Tools

There is an option for accessibility in the "Audits" tab
There is an accessibility tab in Chrome that contains the accessibility tree, the ARIA attributes, and the accessibility-related computed attributes

Angular Material

Make sure that the custom color pass the contrast

Testing an Effect using observer-spy

Alfredo Perez — Fri, 25 Sep 2020 17:23:52 +0000

Updates

September 29 2020: refactor to use fakeTime and subscribeAndSpyOn as recommended by Shai Reznik 🎉
October 07 2020: reafactor to use subscribeSpyTo as recommended by Shai Reznik 🎉

Have you try theobserver-spy library by Shai Reznik?

It particularly makes testing ngrx effects an easy task and keeps them readable.

To demonstrate this, I refactored the tests from book.effects.spec.ts from the ngrx example application, and here are the differences...

Testing the success path

Using marbles:

 it('should return a book.SearchComplete, with the books, on success, after the de-bounce', () => {
    const book1 = { id: '111', volumeInfo: {} } as Book;
    const book2 = { id: '222', volumeInfo: {} } as Book;
    const books = [book1, book2];
    const action = FindBookPageActions.searchBooks({ query: 'query' });
    const completion = BooksApiActions.searchSuccess({ books });

    actions$ = hot('-a---', { a: action });
    const response = cold('-a|', { a: books });
    const expected = cold('-----b', { b: completion });
    googleBooksService.searchBooks = jest.fn(() => response);

    expect(
      effects.search$({
        debounce: 30,
        scheduler: getTestScheduler(),
      })
    ).toBeObservable(expected);
  });

Using observer-spy:

 it('should return a book.SearchComplete, with the books, on success, after the de-bounce', fakeTime((flush) => {
        const book1 = { id: '111', volumeInfo: {} } as Book;
        const book2 = { id: '222', volumeInfo: {} } as Book;
        const books = [book1, book2];

        actions$ = of(FindBookPageActions.searchBooks({ query: 'query' }));
        googleBooksService.searchBooks = jest.fn(() => of(books));

        const effectSpy = subscribeSpyTo(effects.search$());

        flush();
        expect(effectSpy.getLastValue()).toEqual(
          BooksApiActions.searchSuccess({ books })
        );
      })
    );

Testing the error path

Using marbles:

  it('should return a book.SearchError if the books service throws', () => {
      const action = FindBookPageActions.searchBooks({ query: 'query' });
      const completion = BooksApiActions.searchFailure({
        errorMsg: 'Unexpected Error. Try again later.',
      });
      const error = { message: 'Unexpected Error. Try again later.' };

      actions$ = hot('-a---', { a: action });
      const response = cold('-#|', {}, error);
      const expected = cold('-----b', { b: completion });
      googleBooksService.searchBooks = jest.fn(() => response);

      expect(
        effects.search$({
          debounce: 30,
          scheduler: getTestScheduler(),
        })
      ).toBeObservable(expected);
    });

Using observer-spy:

 it('should return a book.SearchError if the books service throws', fakeTime((flush) => {
        const error = { message: 'Unexpected Error. Try again later.' };
        actions$ = of(FindBookPageActions.searchBooks({ query: 'query' }));
        googleBooksService.searchBooks = jest.fn(() => throwError(error));

        const effectSpy = subscribeSpyTo(effects.search$());

        flush();
        expect(effectSpy.getLastValue()).toEqual(
          BooksApiActions.searchFailure({
            errorMsg: error.message,
          })
        );
      })
    );

Testing when the effect does not do anything

Using marbles:

   it(`should not do anything if the query is an empty string`, () => {
      const action = FindBookPageActions.searchBooks({ query: '' });

      actions$ = hot('-a---', { a: action });
      const expected = cold('---');

      expect(
        effects.search$({
          debounce: 30,
          scheduler: getTestScheduler(),
        })
      ).toBeObservable(expected);
    });

Using observer-spy:

 it(`should not do anything if the query is an empty string`, fakeTime((flush) => {
        actions$ = of(FindBookPageActions.searchBooks({ query: '' }));

        const effectSpy = subscribeSpyTo(effects.search$());

        flush();
        expect(effectSpy.getLastValue()).toBeUndefined();
      })

You can find the working test here:

https://github.com/alfredoperez/ngrx-observer-spy/blob/master/projects/example-app/src/app/books/effects/book.effects.spec.ts

What do you think? Which one do you prefer?

Where to initialize components selectors in Angular?

Alfredo Perez — Wed, 16 Sep 2020 13:51:39 +0000

TL;DR

When using the selector in the component, it is recommended not to initialize them in the declaration and instead initialize them in the constructor.

export class FindBookPageComponent {
  searchQuery$: Observable<string>;
  books$: Observable<Book[]>;
  loading$: Observable<boolean>;
  error$: Observable<string>;

  constructor(private store: Store<fromBooks.State>) {
    this.searchQuery$ = store.pipe(
      select(fromBooks.selectSearchQuery),
      take(1)
    );
    this.books$ = store.pipe(select(fromBooks.selectSearchResults));
    this.loading$ = store.pipe(select(fromBooks.selectSearchLoading));
    this.error$ = store.pipe(select(fromBooks.selectSearchError));
  }

  search(query: string) {
    this.store.dispatch(FindBookPageActions.searchBooks({ query }));
  }
}

Angular Type Safety

Initializing in the constructor helps because when using the strict mode in TypeScript, the compiler will not be able to know that the selectors were initialized on ngOnInit

The strictPropertyInitialization was added by default in the --strict mode in Angular 9.

The following checks where also added:

{
  "//": "tsconfig.json",
  "compilerOptions": {
    "noImplicitAny": true,
    "noImplicitReturns": true,
    "noImplicitThis": true,
    "noFallthroughCasesInSwitch": true,
    "strictNullChecks": true
  }
}

The strict-mode allows us to write much safe and robust application. Honestly, I think all Angular application should be written in strict-mode, but it is a little hard to understand every error messages caused by the compiler.

References

Angular 9 Strict Mode here
Angular Type safety here
Strict Property Initialization in TypeScript here

Angular 11 - Setting up Jest

Alfredo Perez — Mon, 06 Jul 2020 21:21:59 +0000

This is a quick guide to setup Jest in your new Angular 10 application

1. Install Jest

npm install jest @types/jest jest-preset-angular --save-dev

2. Uninstall Karma

npm uninstall karma karma-chrome-launcher karma-coverage-istanbul-reporter karma-jasmine karma-jasmine-html-reporter @types/jasmine @types/jasminewd2 jasmine-core jasmine-spec-reporter

3. Remove test from `angular.json`

Remove the test section from angular.json, this section looks like the following:

   "test": {
          "builder": "@angular-devkit/build-angular:karma",
          "options": {
            "main": "src/test.ts",
            "polyfills": "src/polyfills.ts",
            "tsConfig": "tsconfig.spec.json",
            "karmaConfig": "karma.conf.js",
            "assets": [
              "src/favicon.ico",
              "src/assets"
            ],
            "styles": [
              "src/styles.scss"
            ],
            "scripts": []
          }
        },

4. Remove `karma.conf.js` and `src/test.ts` files

5. Create `setupJest.ts` file

This file should have the following:

import 'jest-preset-angular';

6. Modify `tsconfig.spec.json`

{
  "extends": "./tsconfig.json",
  "compilerOptions": {
    "outDir": "./out-tsc/spec",
    "types": [
      "jest",
      "node"
    ]
  },
  "files": [
    "src/polyfills.ts"
  ],
  "include": [
    "src/**/*.spec.ts",
    "src/**/*.d.ts"
  ]
}

7. Modify `package.json` file

Modify the test scripts to the following:

 "test": "jest",
 "test:coverage": "jest --coverage",

Add Jest configuration to the end of this file:

"jest": {
    "preset": "jest-preset-angular",
    "setupFilesAfterEnv": [
      "<rootDir>/setupJest.ts"
    ],
    "testPathIgnorePatterns": [
      "<rootDir>/node_modules/",
      "<rootDir>/dist/"
    ],
    "globals": {
      "ts-jest": {
        "tsConfig": "<rootDir>/tsconfig.spec.json",
        "stringifyContentPathRegex": "\\.html$"
      }
    }
}

Forem: Alfredo Perez

Getting Started with Angular Toolbar

Quick Setup

How It Works

Feature Flags

Permissions

getValues() vs getForcedValues()

App Features

Combining for Realistic Scenarios

What's Next

Spec-Driven Development: Stop Vibe Coding

What is "Vibe Coding"?

The Solution: Spec-Driven Development

Getting Started

Step 1: Install Prerequisites

Step 2: Install spec-kit CLI

Step 3: Install SpecKit Companion (VS Code Extension)

Step 4: Initialize Your Project

The Spec-Driven Workflow: Building Plan Step Highlight

Phase 1: Constitution

Phase 2: Specify

Phase 3: Plan

Phase 4: Tasks

Phase 5: Implement

Project Structure

What's Different?

SpecKit Companion: More Than Workflow

Conclusion

Universal Knowledge Base for AI

Why do we need it?

Share Knowledge That Actually Gets Used

Stop Recreating AI Tool Configuration

Allow Developers to Choose Their Workflow

How do we create a Universal Knowledge Base?

Code Style

Project

Tools

Folder Structure Example

Links

Create Reliable Unit Tests with Claude Code

Why Does This Happen?

Teach Claude Code Your Team's Testing Style

Setting Up Your Testing Guides

The Basic Structure

testing-core.md

Example

Type-Specific Guides

Case-Specific Guides

Creating Agents and Commands in Claude Code

Creating Custom Slash Commands

Keep refining your rules

Generating Your First Rules with Cursor for Your Angular Project

Meta Rule Explanation

Example 1—BMAD Method

Example 2—Elie Steinbock Method

Cursor Meta Rule for Angular Development

Rule Generation Guidelines

Organizational Folders

Metadata

Always

Auto-Apply

Agent Select

Manual (-manual.mdc):

Glob Pattern Examples

Description

Rule Template Structure

Examples

Confirmation Response Format

Understanding the Meta Rule Structure

Rule Template Structure

Frontmatter Types in Angular Context

How to Generate Rules

Option 1: Cursor.directory Website

Option 2: Prompts + Meta-rule

TypeScript Best Practices

Angular Best Practices

Components

State Management

Templates

Services

Manual (`-manual.mdc`):

3. Remove test from `angular.json`

4. Remove `karma.conf.js` and `src/test.ts` files

5. Create `setupJest.ts` file

6. Modify `tsconfig.spec.json`

7. Modify `package.json` file