@mikulgohil/ai-kit 1.0.0

package/README.md

@@ -0,0 +1,73 @@
+# ai-kit
+
+AI-assisted development setup kit. Auto-detects your tech stack and generates tailored CLAUDE.md, .cursorrules, slash commands, and developer guides.
+
+## Installation
+
+```bash
+npx ai-kit init
+```
+
+Requires Node >= 18.
+
+## What Gets Generated
+
+Running `init` scans your project and produces:
+
+- **CLAUDE.md** — Project-aware rules and conventions for Claude Code
+- **.cursorrules** — Equivalent rules for Cursor AI
+- **.claude/commands/** — 25 slash commands across 5 categories: getting started, building, quality & review, maintenance, workflow
+- **ai-kit/guides/** — 5 developer guides: getting-started, prompt-playbook, when-to-use-ai, token-saving-tips, figma-workflow
+- **docs/** — 3 doc scaffolds: mistakes-log, decisions-log, time-log
+
+## Commands
+
+| Command | Description |
+|---------|-------------|
+| `ai-kit init [path]` | Scan project and generate all configs |
+| `ai-kit update [path]` | Re-scan and update existing generated files |
+| `ai-kit reset [path]` | Remove all AI Kit generated files |
+
+`path` defaults to the current directory if omitted.
+
+## Supported Stacks
+
+**Frameworks** — Next.js (App Router, Pages Router, Hybrid), React
+
+**CMS** — Sitecore XM Cloud, Sitecore JSS
+
+**Styling** — Tailwind CSS, SCSS, CSS Modules, styled-components
+
+**Language** — TypeScript (with strict mode detection)
+
+**Monorepos** — Turborepo, Nx, Lerna, pnpm workspaces
+
+**Design** — Figma MCP, design tokens, visual tests
+
+**Package managers** — npm, pnpm, yarn, bun
+
+## Updating and Resetting
+
+To pick up new dependencies or config changes after your stack evolves:
+
+```bash
+npx ai-kit update
+```
+
+To remove all generated files and start clean:
+
+```bash
+npx ai-kit reset
+```
+
+## Further Reading
+
+Detailed usage is covered in the generated guides under `ai-kit/guides/` after running `init`. Start with `getting-started.md`.
+
+## Repository
+
+[https://github.com/mikulgohil/ai-kit](https://github.com/mikulgohil/ai-kit)
+
+## License
+
+MIT

package/commands/accessibility-audit.md

@@ -0,0 +1,143 @@
+# Accessibility Audit
+
+> **Role**: You are a senior accessibility engineer, certified in WCAG 2.1 AA/AAA compliance. You have deep experience auditing React and Next.js applications for screen reader compatibility, keyboard navigation, and visual accessibility.
+> **Goal**: Scan the target file(s) for every accessibility violation, report each one with its WCAG reference, and provide the exact code fix.
+
+## Mandatory Steps
+
+You MUST follow these steps in order. Do not skip any step.
+
+1. **Read the target file(s)** — Use the Read tool to open and examine every file specified. Do not analyze from memory or assumptions.
+2. **Check Semantic HTML** — Look for `<div>` or `<span>` used as interactive elements (buttons, links, navigation), missing landmark elements (`<main>`, `<nav>`, `<header>`, `<footer>`), and heading levels that skip (e.g., `<h1>` then `<h3>` with no `<h2>`).
+3. **Check ARIA Attributes** — Look for interactive elements without accessible names, icon-only buttons missing `aria-label`, custom dropdowns/modals missing `role`/`aria-expanded`/`aria-haspopup`, and missing `aria-live` regions for dynamic content.
+4. **Check Keyboard Navigation** — Look for click handlers without keyboard equivalents, custom components that can't be focused, missing focus traps in modals, missing `:focus-visible` styles, and tab order that doesn't match visual order.
+5. **Check Images and Media** — Look for `<img>` and `next/image` without `alt` text, decorative images that should have `alt=""`, videos without captions, and SVG icons not hidden from screen readers.
+6. **Check Color and Contrast** — Look for text that doesn't meet 4.5:1 contrast ratio, large text that doesn't meet 3:1, information conveyed only through color, and Tailwind classes that produce low contrast (e.g., `text-gray-400` on white).
+7. **Check Forms** — Look for `<input>` fields without associated `<label>`, error messages not linked via `aria-describedby`, required fields not marked with `aria-required` or `required`, and form feedback not announced to screen readers.
+
+## What to Check — Reference Examples
+
+### Semantic HTML
+
+**Bad:**
+```tsx
+<div onClick={handleClick} className="btn">Submit</div>
+```
+
+**Good:**
+```tsx
+<button onClick={handleClick} className="btn">Submit</button>
+```
+
+### ARIA Attributes
+
+**Bad:**
+```tsx
+<button onClick={toggleMenu}>
+  <ChevronIcon />
+</button>
+```
+
+**Good:**
+```tsx
+<button onClick={toggleMenu} aria-label="Toggle navigation menu" aria-expanded={isOpen}>
+  <ChevronIcon aria-hidden="true" />
+</button>
+```
+
+### Images and Media
+
+**Bad:**
+```tsx
+<Image src="/hero.jpg" width={800} height={400} />
+```
+
+**Good:**
+```tsx
+<Image src="/hero.jpg" width={800} height={400} alt="Shipping container being loaded onto a cargo vessel at Dubai port" />
+```
+
+### Forms
+
+**Bad:**
+```tsx
+<input type="email" placeholder="Enter your email" />
+<span className="text-red-500">Invalid email</span>
+```
+
+**Good:**
+```tsx
+<label htmlFor="email">Email address</label>
+<input
+  id="email"
+  type="email"
+  aria-required="true"
+  aria-invalid={hasError}
+  aria-describedby={hasError ? "email-error" : undefined}
+/>
+{hasError && <span id="email-error" role="alert" className="text-red-500">Please enter a valid email address</span>}
+```
+
+## Common Mistakes Reference
+
+| Mistake | How Often | Impact |
+|---------|-----------|--------|
+| Missing alt text on images | Very common | Screen readers say "image" with no context |
+| Div used as button | Common | Keyboard users can't activate it |
+| No focus management in modals | Common | Keyboard users get trapped or lost |
+| Color-only error indication | Common | Colorblind users can't see errors |
+| Missing form labels | Very common | Screen readers don't know what the field is for |
+
+## Output Format
+
+You MUST structure your response exactly as follows:
+
+```
+## Accessibility Audit Results
+
+| # | What | Where | Why | Fix | WCAG Ref |
+|---|------|-------|-----|-----|----------|
+| 1 | [specific violation] | [file:line] | [who is affected and how] | [exact code change] | [e.g., WCAG 2.1 SC 1.1.1] |
+| 2 | ... | ... | ... | ... | ... |
+
+## Detailed Fixes
+
+### Issue 1: [title]
+**File:** `path/to/file.tsx` **Line:** XX
+
+**Current code:**
+```tsx
+// the problematic code
+```
+
+**Fixed code:**
+```tsx
+// the corrected code
+```
+
+### Issue 2: ...
+
+## Summary
+- Total issues: X
+- Critical (blocks access): X
+- Major (degrades experience): X
+- Minor (best practice): X
+```
+
+## Self-Check
+
+Before responding, verify:
+- [ ] You read the target file(s) before analyzing
+- [ ] You covered every section listed above (Semantic HTML, ARIA, Keyboard, Images, Contrast, Forms)
+- [ ] Your suggestions are specific to THIS code, not generic advice
+- [ ] You included file paths and line numbers for every issue
+- [ ] You provided fix code, not just descriptions
+- [ ] Every issue has a WCAG reference
+
+## Constraints
+
+- Do NOT give generic advice. Every suggestion must reference specific code in the target file.
+- Do NOT skip sections. If a section has no issues, explicitly say "No issues found."
+- Do NOT suggest changes outside the scope of accessibility.
+
+Target: $ARGUMENTS

package/commands/api-route.md

@@ -0,0 +1,203 @@
+# API Route Generator
+
+> **Role**: You are a senior backend engineer, specializing in Next.js API routes, server actions, TypeScript, and API security. You build production-ready endpoints with validation, error handling, and proper typing from the start.
+> **Goal**: Scaffold a complete, secure Next.js API route or server action based on the user's requirements.
+
+## Mandatory Steps
+
+You MUST follow these steps in order. Do not skip any step.
+
+1. **Ask clarifying questions** — Before generating any code, ask ALL of the following questions if the user hasn't already answered them:
+   - What HTTP method(s)? (GET, POST, PUT, DELETE, or multiple)
+   - What does this endpoint do? (1-2 sentence description)
+   - What data does it accept? (request body / query params)
+   - What does it return? (response shape)
+   - Does it need authentication? (public, logged-in user, admin only)
+   - Is it a Server Action or API Route?
+   - What external services does it call? (database, third-party API, etc.)
+2. **Generate the Zod validation schema** — Define the input schema with specific constraints (min/max lengths, regex patterns, enums). Infer the TypeScript type from the schema.
+3. **Generate the route handler** — Include input parsing, authentication check (if needed), business logic placeholder, typed response, and comprehensive error handling.
+4. **Generate response types** — Create shared `ApiSuccess<T>` and `ApiError` types if they don't already exist in the project.
+5. **Generate the server action alternative** — If the user requested a server action (or if it's appropriate for the use case), generate the `'use server'` version with `FormData` parsing.
+6. **Provide the file path** — Tell the user exactly where to place the file(s) in the project structure.
+
+## What Gets Generated — Reference Examples
+
+### 1. Input Validation Schema (Zod)
+
+```typescript
+import { z } from 'zod';
+
+const CreateOrderSchema = z.object({
+  items: z.array(z.object({
+    productId: z.string().uuid(),
+    quantity: z.number().int().min(1).max(100),
+  })).min(1, 'Order must have at least one item'),
+  shippingAddress: z.object({
+    street: z.string().min(1).max(200),
+    city: z.string().min(1).max(100),
+    zip: z.string().regex(/^\d{5}(-\d{4})?$/, 'Invalid ZIP code'),
+    country: z.string().length(2, 'Use ISO country code'),
+  }),
+  paymentMethod: z.enum(['credit_card', 'paypal', 'bank_transfer']),
+});
+
+type CreateOrderInput = z.infer<typeof CreateOrderSchema>;
+```
+
+### 2. Route Handler with Error Handling
+
+```typescript
+import { NextRequest, NextResponse } from 'next/server';
+
+export async function POST(request: NextRequest) {
+  try {
+    // 1. Parse and validate input
+    const body = await request.json();
+    const input = CreateOrderSchema.parse(body);
+
+    // 2. Check authentication
+    const session = await getSession(request);
+    if (!session) {
+      return NextResponse.json(
+        { error: 'Authentication required' },
+        { status: 401 }
+      );
+    }
+
+    // 3. Business logic
+    const order = await createOrder(input, session.userId);
+
+    // 4. Return typed response
+    return NextResponse.json(
+      { data: order },
+      { status: 201 }
+    );
+  } catch (error) {
+    // 5. Handle validation errors specifically
+    if (error instanceof z.ZodError) {
+      return NextResponse.json(
+        { error: 'Validation failed', details: error.errors },
+        { status: 400 }
+      );
+    }
+
+    // 6. Generic error (don't leak internals)
+    console.error('Order creation failed:', error);
+    return NextResponse.json(
+      { error: 'Internal server error' },
+      { status: 500 }
+    );
+  }
+}
+```
+
+### 3. Response Types
+
+```typescript
+// types/api.ts
+interface ApiSuccess<T> {
+  data: T;
+}
+
+interface ApiError {
+  error: string;
+  details?: unknown;
+}
+
+type ApiResponse<T> = ApiSuccess<T> | ApiError;
+```
+
+### 4. Server Action Alternative
+
+```typescript
+'use server';
+
+import { z } from 'zod';
+import { revalidatePath } from 'next/cache';
+
+const ContactFormSchema = z.object({
+  name: z.string().min(1, 'Name is required').max(100),
+  email: z.string().email('Invalid email address'),
+  message: z.string().min(10, 'Message must be at least 10 characters').max(1000),
+});
+
+export async function submitContactForm(formData: FormData) {
+  const input = ContactFormSchema.parse({
+    name: formData.get('name'),
+    email: formData.get('email'),
+    message: formData.get('message'),
+  });
+
+  await sendEmail(input);
+  revalidatePath('/contact');
+  return { success: true };
+}
+```
+
+## Common Mistakes This Prevents
+
+| Mistake | What happens | How this command prevents it |
+|---------|-------------|----------------------------|
+| No input validation | Attacker sends malicious data | Zod schema validates everything |
+| `any` typed request body | No TypeScript protection | Types inferred from Zod schema |
+| Generic `catch (e)` | Swallows real errors | Specific handlers for each error type |
+| Stack traces in response | Leaks internal details | Generic message for 500 errors |
+| Missing auth check | Unauthorized access | Auth check included by default |
+| No error status codes | Client can't handle failures | Proper HTTP status codes |
+
+## Output Format
+
+You MUST structure your response exactly as follows:
+
+```
+## API Route: [METHOD] [path]
+
+### Questions (if unanswered)
+1. [question]
+2. [question]
+
+### Generated Files
+
+#### 1. Validation Schema
+**File:** `src/app/api/[path]/schema.ts`
+```typescript
+// Zod schema here
+```
+
+#### 2. Route Handler
+**File:** `src/app/api/[path]/route.ts`
+```typescript
+// Route handler here
+```
+
+#### 3. Response Types
+**File:** `src/types/api.ts` (if not already present)
+```typescript
+// Types here
+```
+
+### Usage Example
+```typescript
+// How to call this endpoint from the client
+```
+```
+
+## Self-Check
+
+Before responding, verify:
+- [ ] You asked all clarifying questions (or they were already answered)
+- [ ] The Zod schema has specific constraints (not just `z.string()`)
+- [ ] Authentication is included if the endpoint is not public
+- [ ] Error handling covers validation errors, auth errors, and generic errors
+- [ ] Response types are consistent with the project's existing patterns
+- [ ] File paths follow Next.js App Router conventions
+
+## Constraints
+
+- Do NOT generate code without understanding the requirements first — ask questions.
+- Do NOT use `any` anywhere in the generated code.
+- Do NOT skip error handling — every route must have try-catch with specific error handlers.
+- Do NOT forget authentication — if in doubt, include it and let the user remove it.
+
+Target: $ARGUMENTS

package/commands/commit-msg.md

@@ -0,0 +1,127 @@
+# Commit Message Generator
+
+> **Role**: You are a senior developer who follows the Conventional Commits standard and writes clear, descriptive commit messages that make git history useful.
+> **Goal**: Analyze staged git changes and generate a properly formatted conventional commit message that is ready to use.
+
+## Mandatory Steps
+
+You MUST follow these steps in order. Do not skip any step.
+
+1. **Read Git Diff** — Run `git diff --cached` to see all staged changes. If nothing is staged, inform the developer and stop.
+
+2. **Determine Type and Scope** — Based on the diff, select the appropriate type and scope:
+
+   ### Types
+
+   | Type | When to Use | Example |
+   |------|------------|---------|
+   | `feat` | New feature or capability | `feat(cart): add quantity selector to cart items` |
+   | `fix` | Bug fix | `fix(auth): prevent session timeout on active users` |
+   | `refactor` | Code restructuring without behavior change | `refactor(api): extract validation into shared middleware` |
+   | `docs` | Documentation changes only | `docs(readme): add deployment instructions` |
+   | `test` | Adding or fixing tests | `test(checkout): add payment form validation tests` |
+   | `style` | Formatting, whitespace (no logic changes) | `style: fix import order across components` |
+   | `chore` | Build, tooling, dependency updates | `chore(deps): upgrade next.js to 15.1.0` |
+   | `perf` | Performance improvement | `perf(images): lazy load below-fold product images` |
+
+   **Scope** = the area of the codebase affected (component name, module, feature area). Optional but encouraged.
+
+3. **Write Subject Line** — Craft a concise subject following these rules:
+   - Under 72 characters
+   - Imperative mood ("add feature" not "added feature" or "adds feature")
+   - No period at the end
+   - Describes the *what* in minimal words
+
+4. **Optionally Write Body** — If the change is non-trivial (multi-file, behavior change, or breaking), add a body:
+   - Explains *why* the change was made, not *what* changed (the diff shows that)
+   - Use bullet points for multiple related changes
+   - Reference ticket numbers when applicable (`Refs: JIRA-123`)
+   - Note breaking changes with `BREAKING CHANGE:` footer
+
+## What to Check / Generate
+
+### Commit Format
+
+```
+<type>(<scope>): <short description>
+
+<body — what and why, not how>
+
+<footer — breaking changes, ticket references>
+```
+
+### Examples
+
+**Small change — one line:**
+```
+fix(header): correct mobile nav z-index overlapping content
+```
+
+**Medium change — with body:**
+```
+feat(search): add debounced search with typeahead suggestions
+
+- Debounce search input by 300ms to reduce API calls
+- Show top 5 matching suggestions in dropdown
+- Keyboard navigation (arrow keys + enter) for suggestions
+- Clear suggestions when input is empty
+```
+
+**Breaking change:**
+```
+feat(api)!: change order response format to include pagination
+
+The /api/orders endpoint now returns:
+{ data: Order[], meta: { page, total, perPage } }
+
+Previously returned a flat array. All consumers must update.
+
+BREAKING CHANGE: Order API response shape changed
+Refs: JIRA-456
+```
+
+### Common Mistakes to Avoid
+
+| Bad Message | Problem | Better Message |
+|-------------|---------|---------------|
+| `fix stuff` | No context | `fix(cart): prevent negative quantities on update` |
+| `WIP` | Not a real commit | Don't commit WIP — stash instead |
+| `updated files` | No information | `refactor(auth): move session logic to useAuth hook` |
+| `bug fix` | Which bug? | `fix(checkout): handle expired payment token gracefully` |
+| `asdf` | Meaningless | Stage only what's ready, write a real message |
+
+## Output Format
+
+You MUST structure your response exactly as follows:
+
+```
+## Suggested Commit Message
+
+[the complete commit message, ready to copy-paste]
+
+## Reasoning
+- Type: [type] — because [reason]
+- Scope: [scope] — because [reason]
+- Body: [included/omitted] — because [reason]
+```
+
+## Self-Check
+
+Before responding, verify:
+- [ ] You read the staged diff (`git diff --cached`) before writing the message
+- [ ] The subject line is under 72 characters
+- [ ] The subject uses imperative mood
+- [ ] The type accurately reflects the nature of the change
+- [ ] The scope identifies the affected area of the codebase
+- [ ] If the change is non-trivial, you included a body explaining *why*
+- [ ] Breaking changes are noted with `!` in the subject and `BREAKING CHANGE:` footer
+
+## Constraints
+
+- Do NOT write a commit message without first reading the staged diff.
+- Do NOT use past tense ("added", "fixed") — use imperative mood ("add", "fix").
+- Do NOT include a period at the end of the subject line.
+- Do NOT combine multiple unrelated changes in one message. If the diff contains unrelated changes, suggest splitting into multiple commits.
+- Do NOT write generic messages. The message must be specific to the actual changes in the diff.
+
+Target: $ARGUMENTS

package/commands/dep-check.md

@@ -0,0 +1,148 @@
+# Dependency Check
+
+> **Role**: You are a senior DevOps engineer who keeps projects lean, secure, and well-maintained through proactive dependency management.
+> **Goal**: Audit project dependencies to find unused packages, duplicates, security vulnerabilities, outdated versions, and bundle size opportunities, then produce a categorized report with specific action items.
+
+## Mandatory Steps
+
+You MUST follow these steps in order. Do not skip any step.
+
+1. **Scan package.json** — Read `package.json` (and `package-lock.json` if relevant) to catalog all `dependencies` and `devDependencies`. Note the total count.
+
+2. **Check Unused Dependencies** — Scan all `.ts`, `.tsx`, `.js`, `.jsx` files for imports from each dependency. Also check config files (PostCSS, Tailwind, ESLint plugins are used indirectly). Flag any dependency with zero import references.
+
+   **Example finding:**
+   ```
+   Possibly unused dependencies:
+     - lodash (0 imports found — you may have switched to native methods)
+     - moment (0 imports found — check if date-fns replaced it)
+
+   Note: Some packages are used indirectly (PostCSS plugins, ESLint configs).
+   Verify before removing.
+   ```
+
+   **How to remove safely:**
+   ```bash
+   npm uninstall lodash moment
+   npm run build  # verify nothing breaks
+   npm run test   # verify tests pass
+   ```
+
+3. **Check Duplicate Functionality** — Identify multiple packages doing the same thing:
+
+   | Duplication | Common Example | Recommendation |
+   |-------------|---------------|----------------|
+   | Date libraries | `moment` + `date-fns` | Pick one (prefer `date-fns` — tree-shakable) |
+   | HTTP clients | `axios` + `node-fetch` | Use native `fetch` (built into Node 18+) |
+   | Utility libraries | `lodash` + `underscore` | Pick one or use native methods |
+   | CSS solutions | `styled-components` + `tailwindcss` | Pick one per project |
+   | State management | `redux` + `zustand` + `jotai` | Pick one |
+
+4. **Check Security Vulnerabilities** — Review for known vulnerabilities. Reference what `npm audit` would find.
+
+   **Severity action guide:**
+   - **Critical/High**: Fix immediately with `npm audit fix` or upgrade the package
+   - **Moderate**: Plan to fix in the next sprint
+   - **Low**: Track but don't block releases
+
+   **Example finding:**
+   ```
+   Vulnerability found:
+     Package: nth-check < 2.0.1
+     Severity: High
+     Fix: npm audit fix
+     Or manually: npm install nth-check@latest
+   ```
+
+5. **Check Outdated Dependencies** — Identify packages significantly behind the latest version.
+
+   **Risk levels:**
+   - **Patch behind** (1.2.3 → 1.2.5): Safe to update, bug fixes only
+   - **Minor behind** (1.2.3 → 1.4.0): Usually safe, may have new features
+   - **Major behind** (1.2.3 → 3.0.0): Breaking changes — needs migration plan
+
+6. **Check Bundle Size Impact** — Identify packages that are disproportionately large and suggest lighter alternatives:
+
+   | Package | Typical Size | Lighter Alternative |
+   |---------|-------------|-------------------|
+   | `moment` | 290 KB | `date-fns` (tree-shakable, ~10 KB per function) |
+   | `lodash` | 530 KB | `lodash-es` (tree-shakable) or native methods |
+   | `axios` | 30 KB | Native `fetch` (0 KB) |
+   | `classnames` | 1 KB | Template literals or `clsx` (0.5 KB) |
+   | `uuid` | 12 KB | `crypto.randomUUID()` (0 KB, native) |
+
+7. **Check Dev/Prod Misplacement** — Verify that:
+   - No `devDependencies` are imported in source code (should be `dependencies`)
+   - No production `dependencies` are only used in tests (should be `devDependencies`)
+
+## Output Format
+
+You MUST structure your response exactly as follows:
+
+```
+## Dependency Audit Report
+
+### Summary
+- Total dependencies: X
+- Total devDependencies: X
+- Issues found: X
+
+### Unused (N)
+| Package | Imports Found | Confidence | Action |
+|---------|--------------|------------|--------|
+| ... | 0 | High/Low | `npm uninstall <pkg>` |
+
+### Duplicates (N)
+| Category | Packages | Recommendation |
+|----------|----------|---------------|
+| ... | ... | ... |
+
+### Security (N)
+| Package | Version | Severity | Fix |
+|---------|---------|----------|-----|
+| ... | ... | Critical/High/Moderate/Low | ... |
+
+### Outdated (N)
+| Package | Current | Latest | Risk | Action |
+|---------|---------|--------|------|--------|
+| ... | ... | ... | Patch/Minor/Major | ... |
+
+### Bundle Opportunities (N)
+| Package | Size | Alternative | Savings |
+|---------|------|-------------|---------|
+| ... | ... | ... | ... |
+
+### Dev/Prod Misplaced (N)
+| Package | Current Location | Should Be | Reason |
+|---------|-----------------|-----------|--------|
+| ... | ... | ... | ... |
+
+### Estimated Impact
+- Bundle size savings: ~X KB
+- Packages to remove: X
+- Security fixes needed: X
+
+### Recommended Actions (Priority Order)
+1. [action] — [reason]
+2. [action] — [reason]
+...
+```
+
+## Self-Check
+
+Before responding, verify:
+- [ ] You read the full `package.json` before analyzing
+- [ ] You scanned source files for actual import usage of each dependency
+- [ ] You checked config files for indirect dependency usage (ESLint, PostCSS, Tailwind plugins)
+- [ ] You covered all 6 check categories (unused, duplicates, security, outdated, bundle, dev/prod)
+- [ ] Every finding includes a specific action item with a command or next step
+- [ ] You noted which "unused" packages might be indirect dependencies (false positives)
+
+## Constraints
+
+- Do NOT recommend removing a package without checking config files for indirect usage.
+- Do NOT skip any check category. If a category has no issues, explicitly say "No issues found."
+- Do NOT guess package sizes — use the known typical sizes in the reference table or state "check bundlephobia.com."
+- Do NOT recommend major version upgrades without noting breaking change risk.
+
+Target: $ARGUMENTS