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

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

---

The Problem: AI That Forgets Everything

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

But reality hit quickly.

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

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

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

I was spending more time correcting the AI than coding.

Sound familiar?

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

Here's exactly how I did it.

---

The Solution: A Structured Rule System

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

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

My File Structure

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

Why split into multiple files?

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

---

Tip #1: Add Rules When AI Keeps Repeating Mistakes

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

Real Example: The Dark Mode Disaster

Claude kept generating Tailwind classes like this:

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

Or worse:

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

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

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

## ❌ What NOT to Do

### NEVER Use dark: Prefix

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

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


### NEVER Use var() in Tailwind Classes

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

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

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

The Rule-Adding Workflow

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

---

Tip #2: Structure Rules with Clear Examples

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

Here's my template for effective rules:

## [Pattern Name]

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

### ✅ Correct

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


### ❌ Wrong

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


### Why This Matters

[1-2 sentences explaining the reasoning]

Real Example from My Component Patterns

## Template Files (CRITICAL)

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

### ✅ CORRECT: Use separate template file

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


### ❌ WRONG: Inline template

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


### Why Separate Templates?

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

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

---

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

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

Key Sections in My CLAUDE.md

1. Project Overview - What we're building

## Project Overview

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

2. What NOT to Do - The most common mistakes

## Quick Reference: What NOT to Do

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

3. Rule File Index - Where to find detailed rules

## Rule Files

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

4. Code Review Checklist - Quality gates

## Code Review Checklist

Before considering code complete:

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

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

---

Tip #4: Track Progress with TODO Files

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

The Problem with Large Projects

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

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

My Solution: Phase-Based TODOs

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

# Phase 0.2 - Core Chat Components

## ✅ Completed Tasks

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

## 🔄 In Progress

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

## 📋 Pending

- [ ] TypingIndicator component
- [ ] StreamingText component

## 📊 Progress Summary

**Overall Progress:** 40% Complete

The Workflow

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

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

---

Tip #5: Use Path-Specific Rules

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

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

# Component Structure & Patterns

These rules apply specifically to Angular components...

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

My Path-Specific Rules

---

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

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

Weak rule:

Use `inject()` instead of constructor injection.

Strong rule:

## Service Injection

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

### Why?

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

### ✅ Correct

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

### ❌ Wrong

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

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

---

Tip #7: Include Technology Version Context

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

## Critical Context

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

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

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

---

The Results: Before vs. After

Before (Without Rule System)

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

After (With Rule System)

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

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

---

Getting Started: Your First Rule File

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

Step 1: Create .claude/CLAUDE.md

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

# Project Memory

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

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

Step 2: Add Rules When Mistakes Repeat

Every time you correct Claude twice for the same thing:

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

Step 3: Review and Refine Weekly

As your rule files grow:

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

---

Quick Reference: Rule File Best Practices

---

Conclusion

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

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

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

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

That's it. That's the system.

---

Resources

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

---

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

---

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