How to Stress-Test Any AI System Using a Multi — Agent Task Force

A real-world case study of running multiple LLMs simultaneously to stress-test an AI agent skill system

Hi there 👋

A little context before we dive in 📖

This article is part of a series where I’m building an AI-powered skill system that automates Angular project setup — from linters and formatters to third-party library integration — so developers can skip the boring setup work and focus on shipping features.

This specific article was born out of Part 2 of that series, where I stress-tested the whole system using multiple LLMs running simultaneously in Cursor. The results were rich enough to deserve their own dedicated space.

But here’s the thing — the Angular part is just my real-world example that I want to share with you.

The real subject of this article is the technique itself: how to assemble a task force of LLMs, give them a structured review prompt, and extract findings that no single reviewer would catch alone. Whether you’re building agent skills, reviewing a complex codebase, stress-testing a prompt system, or validating any kind of technical decision — this approach applies.

If you want the full context before reading, here are the two previous articles 👇

• Part 1 — *Setting up the foundation: linters, formatters, git hooks*
• Part 2 — *The third-party integration sub-skill and the problems I ran into*

But if you just want to jump straight in, you’ll be fine. Everything you need is explained as you go. 🚀

🤖 What is Cursor’s Background Agents feature?

Cursor can run multiple AI agents simultaneously — each working independently on the same task, in parallel, without influencing each other.

Think of it like sending the same brief to four different consultants at the same time and comparing their reports. Each one brings a different perspective. Each one catches different things. The combination is far more powerful than any single review.

To use it, your project needs to be pushed to Git and up to date. The agents work directly on your repository — so make sure what they’re reviewing is the version you actually want feedback on.

And it looks like 👇

Using Cursor’s Parallel Agents Feature to Review my Meta-Skill

The review prompt 📋

Before launching the task force, I needed a prompt that would guide each model toward the kind of feedback I actually wanted — not generic suggestions, but deep, structured, actionable findings.

ℹ️ Here’s the prompt I used by the end of the artile.

A few things worth noting about this prompt:

• The overfitting check is the most unique section — it specifically hunts for instructions that are secretly just patches for past failures rather than real systematic solutions. This is the most common way skills quietly degrade over time, and most review prompts completely miss it.
• The system integrity check looks at the skills not in isolation but as a coherent system — contracts between skills, execution order, and whether adding a new sub-skill would break existing ones.
• And the Top 3 Priorities section forces the agent to synthesize rather than just list problems, so you get direction, not just a wall of feedback.

What each model found — and what made each perspective unique 🔍

Same prompt. Same system. Four different perspectives. Here’s where it gets really interesting.

🔵 Claude Opus 4.6 — the detail hunter

Opus went the deepest on specifics. It found implementation-level issues that would have been nearly impossible to catch manually:

• git reset --hard in angular-linters has a warning about clean working directory but no enforcement — the warning exists, the check doesn't actually run
• git clean -fd in the rollback destroys references/cache/ llms.txt files because they're untracked — the rollback erases the documentation work just done
• The test commit in Step 5 is permanent — it adds a commit to git history and the skill never undoes it
• The retry loop in angular-third-party-integration has no exit condition — it says "retry until it passes" with no maximum attempt count

The pattern across all of Opus’s findings: things that look fine on paper but fail in specific real-world conditions.

🟣 Claude Sonnet 4.6 — the architect

Sonnet focused on structure and long-term design:

• eslint-plugin-rxjs-x is added as a standard step for all projects — but Angular 21+ is signals-first. A green-field signals project may never use RxJS at all, making this plugin pure overhead
• Port 4200 is hardcoded for dev server verification — but angular.json can define a custom port, causing the browser check to fail silently
• The cache in references/cache/ is shared across all projects using the skill — two projects using different versions of the same library could serve stale content to one of them
• Both angular-linters and angular-third-party-integration depend on a clean git state but define "clean" inconsistently

Sonnet’s underlying question throughout: what happens at scale, across multiple projects and multiple teams?

🟡 GPT 5.4 — the principled reviewer

GPT pushed hardest on replacing assumptions with verified facts:

• Every hardcoded assertion — Angular defaults, ESLint wrappers, CLI flags — should be replaced with fetch-first verification. Don’t assert. Detect.
• git reset --hard makes the skills unsafe by default. A skill that can destroy user work is not production-ready, regardless of how good the rest is.
• // @ts-ignore for the import-x plugin should use // @ts-expect-error instead. It's stricter and self-documenting
• Bundle budgets should be configurable profiles (strict, balanced, permissive) rather than hardcoded numbers that reflect one team's past pain
• The expect tool for interactive CLIs assumes macOS/Linux — no Windows strategy exists anywhere in the system

GPT’s underlying message throughout: the skills make too many promises they can’t keep across different environments.

🟢 Cursor’s Composer 2 — the pragmatist

Composer focused on concrete, immediately actionable improvements:

• Generate a PROJECT_MANIFEST.json at the end of Phase 1 that all sub-skills MUST read — clean, simple, and solves the I/O contract problem in one step
• angular-third-party-integration runs lint/format assuming angular-linters already ran, if it didn't, commands fail with no guidance. The sub-skill should check for the lint script first
• Two execution modes worth adding: interactive (current) and CI/automation where user confirmation steps are replaced by automated build and test checks
• The sequential installation loop installs libraries in user-defined order — but some libraries depend on others. CDK must land before Material. Order should be derived from peer dependencies, not user input.

Composer’s angle: stop talking about problems, here’s exactly what to build.

The findings everyone agreed on — no debate, no exceptions 🎯

Those were the unique perspectives. But beyond what each model saw differently, six issues came up across all four reviews independently. When four different LLMs flag the same thing without seeing each other’s output — that’s as close to certainty as you can get. 👂

1. Package manager hardcoded as pnpm throughout angular-linters

The skill accepts --package-manager as input, but I forgot to review all existing pnpm run in every single command. Any npm or yarn user gets broken instructions immediately.

✅ Fix: Replace every pnpm run with [pkg-manager] run and resolve it once from the passed argument.

2. Angular 21 assumptions will age badly

Version-specific facts are baked in as universal truths. Angular 22 will ship and silently break them.

✅ Fix: Run ng version first. Parse the major version. Derive flags dynamically instead of hardcoding them. (⚠️ However, the skill still assumes that the user wants to use their currently installed version. This should be improved, as the user might want to use a different version from the one that is installed)

3. git reset --hard is destructive and unsafe

Both skills use it as a default failure recovery. If the user had uncommitted work before starting, it destroys it silently.

✅ Fix: Hard precondition — check git status --porcelain before starting. If not clean, STOP. On failure, scope rollback to files touched by the skill only — not a blanket reset.

4. No compatibility matrix exists anywhere

Libraries get installed sequentially with zero pre-screening for conflicts. The only detection is a broken build, after one library is already committed.

✅ Fix: Create references/compatibility-matrix.md. Run the guard before the sequential loop starts, not after something breaks.

5. Missing referenced files break the system

references/common-integrations-edge-cases.md and references/cache/ are referenced as mandatory read/write targets, but neither exists. First run will either hard fail or silently skip.

✅ Fix: Create both with initial structure, or add explicit “create if missing” instructions as the very first step.

6. No explicit I/O contract between skills

“Invoke angular-linters” means different things to different agents in different environments. What inputs? What does success look like? What happens on failure?

✅ Fix: Define a system contract section in angular-setup-project. Write a PROJECT_MANIFEST.json in Phase 1, and require all sub-skills to read it.

What I improved after the review 🔧

Based on all findings, here are the concrete changes I made:

In angular-setup-projectmeta skill:

• Added version detection step — ng version now runs first, and the major version is stored and passed to all sub-skills
• Added PROJECT_MANIFEST.json generation at the end of Phase 1 — package manager, Angular version, style format, SSR choice, all captured in one place
• Replaced hardcoded skill invocation with an explicit system contract — inputs, outputs, success condition, and failure behavior defined for each sub-skill

In angular-linters sub skill:

• Replaced every pnpm run with [pkg-manager] run resolved from the manifest
• Added hard git pre-condition — git status --porcelain must return empty before starting
• Scoped rollback to files touched by the skill only — no more blanket git reset --hard
• Made eslint-plugin-rxjs-x conditional — only added if RxJS is in package.json dependencies
• Fixed test commit in Step 5 — now uses a disposable file and undoes the commit immediately after verification
• Added bounded retry limit to any lint/build loop — no more “retry until it passes”

In angular-third-party-integration sub skill:

• Added references/compatibility-matrix.md with initial structure
• Created references/common-integrations-edge-cases.md with initial structure
• Created references/cache/ directory with .gitkeep
• Added topological sort step — installation order now derived from peer dependencies, not user input order
• Scoped git clean rollback to exclude references/cache/ files
• Added port detection from angular.json before starting dev server

So — should you try this? 🤔

If you’re building anything complex enough that a single review might miss things — yes. Absolutely.

The Angular skill system was a good candidate because it had multiple moving parts, cross-skill dependencies, and edge cases that only appear in specific environments. But the same technique applies to any system where you want real confidence before shipping.

A few things to keep in mind before you try it:

• The prompt is everything. A vague “review this” produces vague feedback. Give the agents specific lenses to look through — genericity, robustness, hallucination risk, overfitting, and system integrity. The more structured the prompt, the more actionable the output.
• Push to Git first. The agents work on your repo directly. Make sure what they’re reviewing is exactly the version you want feedback on.
• Let each model work independently. The value comes from genuinely different perspectives — not models influencing each other.
• Synthesize after. Once you have all the reviews, ask one model (that handles complex tasks) to consolidate them into a prioritized improvement plan. That’s where the real actionable output lives.

The whole process took a few hours. The confidence it gave me in the system? Worth every minute. 🎯

💡 One more thing worth mentioning

Beyond the external review, the meta-skill itself has a built-in auto-reflection mechanism. Throughout the process — not just at the end — it continuously captures failures, unexpected behaviors, and improvement opportunities as they happen. Every integration, every edge case, every hiccup feeds back into the system automatically.

This means the skill is never static. It learns from its own runs, flags what didn’t go perfectly, and builds a growing knowledge base that makes every future run a little smarter than the last.

So the multi-agent review wasn’t replacing that — it was complementing it. Two layers of improvement working together: the skill reflecting on itself from the inside, and four independent LLMs stress-testing it from the outside. 🔥

The repo and the prompt 👇

Everything is open — the skills, the review prompt, and the full findings. Grab them, adapt them to your own system.

• 🔗 Skills repo
• 📋 Review prompt

Curious what you think. Did this spark any ideas for your own projects? And if there’s something specific you’d like to do, drop it in the comments. I read everything. 👇

See you in the next one 👋

Let’s stay connected! You can find me on **LinkedIn, Instagram, YouTube, or X.**

Thank you ❤️