@mikulgohil/ai-kit 1.3.1 → 1.4.0

package/commands/standup.md

@@ -0,0 +1,131 @@
+# Morning Standup Summary
+
+> **Role**: You are a team lead preparing a concise standup update. You extract meaningful work summaries from git history, identify what components were touched, flag any work in progress, and surface blockers from TODO comments and uncommitted changes.
+> **Goal**: Generate a structured standup report covering yesterday's completed work, current in-progress items, and any blockers or TODOs found in the codebase.
+
+## Mandatory Steps
+
+You MUST follow these steps in order. Do not skip any step.
+
+1. **Determine Time Range** — If `$ARGUMENTS` specifies a date range (e.g., "since Monday", "last 3 days"), use that. Otherwise default to `--since="yesterday"` for daily standup.
+2. **Get Recent Commits** — Run `git log --since="yesterday" --oneline --no-merges --all` to get all recent commits. Also run `git log --since="yesterday" --format="%h %an %s" --no-merges` to include author info.
+3. **Identify Changed Components** — Run `git diff --name-only HEAD~$(git rev-list --count --since="yesterday" HEAD)..HEAD 2>/dev/null || git diff --name-only HEAD~5..HEAD` to get all files changed in the time range. Group by directory/component.
+4. **Check Uncommitted Work** — Run `git status --short` to find any staged or unstaged changes that represent work in progress.
+5. **Read Uncommitted Changes** — Run `git diff --stat` for unstaged changes and `git diff --cached --stat` for staged changes. Read modified files to understand what is being worked on.
+6. **Scan for Blockers** — Search for TODO, FIXME, HACK, and XXX comments in recently changed files. Run a targeted search:
+   - `git diff HEAD~5..HEAD -U0` and look for added lines containing TODO/FIXME
+   - Check for any failing test indicators in recent commits
+7. **Check Branch Context** — Run `git branch --show-current` and `git log --oneline -1` to identify the current feature/task context.
+8. **Produce the Standup Report** — Generate the output in the exact format specified below.
+
+## Analysis Checklist
+
+### Commit Analysis
+- Group commits by feature/scope (from conventional commit prefixes or branch names)
+- Identify whether work was feature development, bug fixing, refactoring, or maintenance
+- Note any reverts or fix-up commits (indicates struggles or issues)
+- Count commits per author if multiple contributors
+
+### Work Classification
+- **Completed**: Commits with clear completion signals (feat:, fix: that close an issue)
+- **In Progress**: Uncommitted changes, WIP commits, partial implementations
+- **Blocked**: TODO/FIXME comments added recently, failing tests, unresolved merge conflicts
+
+### Component Mapping
+- Map changed files to their component/module names
+- Identify cross-cutting changes (shared utils, types, configs)
+- Note if changes span multiple features (might indicate scope creep)
+
+## Output Format
+
+You MUST structure your response exactly as follows:
+
+```
+## Standup Summary — [YYYY-MM-DD]
+
+**Branch**: `feature/JIRA-123-order-page`
+**Period**: [Yesterday | Last 3 days | Since Monday]
+**Commits**: X commits by [author(s)]
+
+---
+
+## Yesterday (Completed Work)
+
+### [Feature/Scope from commit prefix]
+- [Human-readable summary of what was done — not raw commit message]
+- [Another completed item]
+  - Commits: `abc1234`, `def5678`
+  - Files: `OrderForm.tsx`, `useOrder.ts`, `orders.api.ts`
+
+### [Bug Fixes]
+- Fixed [description of bug fix]
+  - Commits: `ghi9012`
+  - Files: `Cart.tsx`
+
+### [Maintenance/Refactoring]
+- [Description of refactoring or chore work]
+
+---
+
+## Changed Components
+
+| Component / Module | Files Changed | Type of Change |
+|--------------------|--------------|----------------|
+| OrderForm | 3 files | New feature (form + hook + API) |
+| Cart | 1 file | Bug fix (quantity calc) |
+| Shared Types | 1 file | Added `OrderStatus` enum |
+
+---
+
+## In Progress (Uncommitted Changes)
+
+| File | Status | What's Being Worked On |
+|------|--------|----------------------|
+| `src/components/Checkout/Payment.tsx` | Modified | Adding Stripe integration |
+| `src/lib/api/payments.ts` | New file | Payment API client (partially implemented) |
+
+> [If no uncommitted changes: "Working tree is clean — no in-progress items."]
+
+---
+
+## Blockers & TODOs
+
+### New TODOs Added
+- `src/components/OrderForm.tsx:45` — `// TODO(JIRA-456): Add address validation`
+- `src/lib/api/orders.ts:23` — `// FIXME: Race condition when rapid-fire submissions`
+
+### Potential Blockers
+- [e.g., "Payment.tsx is half-implemented — may need Stripe API keys in .env"]
+- [e.g., "2 TODO items without ticket numbers — need to file tickets"]
+
+> [If no blockers: "No blockers identified."]
+
+---
+
+## Today's Suggested Focus
+1. [Based on in-progress work: "Complete Stripe payment integration"]
+2. [Based on TODOs: "Address FIXME in orders.ts — race condition"]
+3. [Based on context: "Add tests for OrderForm before PR"]
+```
+
+## Self-Check
+
+Before responding, verify:
+- [ ] You ran `git log` with the correct time range
+- [ ] You summarized commits in human-readable language, not raw commit messages
+- [ ] You checked for uncommitted changes (both staged and unstaged)
+- [ ] You scanned for TODO/FIXME/HACK comments in recently changed files
+- [ ] You grouped changes by component/module, not just listed files
+- [ ] You included the current branch name for context
+- [ ] Today's suggested focus is based on actual in-progress work, not generic advice
+
+## Constraints
+
+- Do NOT dump raw commit messages — translate them into human-readable summaries.
+- Do NOT include merge commits in the summary — use `--no-merges`.
+- Do NOT fabricate work items — if there are no commits in the time range, say so clearly.
+- Do NOT list every file individually when they belong to the same component — group them.
+- If the git history is empty for the time range, adjust: try `--since="2 days ago"` and note the adjustment.
+- Keep the report scannable — a team lead should be able to read it in under 60 seconds.
+
+Target: $ARGUMENTS

package/commands/test-gaps.md

@@ -0,0 +1,182 @@
+# Test Gap Finder
+
+> **Role**: You are a QA engineer with deep knowledge of React testing patterns. You systematically identify untested code, missing edge case coverage, and components that have no test files at all — then prioritize what to test first based on risk and complexity.
+> **Goal**: Scan the target directory for components and utilities, check which ones have corresponding test files, analyze existing tests for coverage gaps, and produce a prioritized action plan with test stubs for the most critical untested code.
+
+## Mandatory Steps
+
+You MUST follow these steps in order. Do not skip any step.
+
+1. **Identify Scope** — If `$ARGUMENTS` specifies a directory or file, use that. Otherwise default to `src/components/` and `src/lib/`. List all `.tsx`, `.ts` files (excluding test files, stories, and type-only files).
+2. **Map Test Files** — For each source file, check if a corresponding `.test.tsx`, `.test.ts`, `.spec.tsx`, or `.spec.ts` file exists in the same directory or a `__tests__/` subdirectory.
+3. **Check Coverage Report** — Run `npx vitest run --coverage --reporter=json` or check for an existing `coverage/` directory. If a coverage report exists, read it. If not, note that coverage data is unavailable.
+4. **Analyze Existing Tests** — For files that DO have tests, read the test file and check:
+   - Are all exported functions/components tested?
+   - Are error states tested?
+   - Are edge cases covered (empty arrays, null values, boundary conditions)?
+   - Are user interactions tested (clicks, form submissions, keyboard events)?
+5. **Identify Critical Gaps** — Prioritize untested code by:
+   - **P0**: Components with user interaction (forms, buttons, modals) and no tests
+   - **P0**: Utility functions used by 3+ files and no tests
+   - **P1**: Components with complex conditional rendering and no tests
+   - **P1**: API integration code with no tests
+   - **P2**: Simple presentational components with no tests
+   - **P2**: Type-only files or config files
+6. **Generate Test Stubs** — Create ready-to-use test stubs for the top 5 highest-priority untested files.
+7. **Produce the Report** — Generate the output in the exact format specified below.
+
+## Analysis Checklist
+
+### Test File Detection
+- `.test.tsx` / `.test.ts` adjacent to source file
+- `.spec.tsx` / `.spec.ts` adjacent to source file
+- `__tests__/` subdirectory with matching filename
+- Test files in a top-level `tests/` directory matching the source path
+
+### Coverage Quality (for existing tests)
+- Happy path: Does the test verify the primary use case?
+- Error handling: Does the test verify error/failure states?
+- Edge cases: Empty data, null/undefined, boundary values, long strings
+- User interaction: Click handlers, form submissions, keyboard navigation
+- Async behavior: Loading states, API call mocking, race conditions
+- Props variations: Required vs optional, different combinations
+
+### Risk Assessment
+- How many files import this module? (wider usage = higher risk)
+- Does it handle user input? (forms, search, filters)
+- Does it make API calls? (data integrity risk)
+- Does it manage state? (complex state = more edge cases)
+- Is it a shared utility? (bug here affects everything)
+
+## Output Format
+
+You MUST structure your response exactly as follows:
+
+```
+## Test Gap Analysis
+
+**Scope**: [directory or files analyzed]
+**Coverage Data**: [Available — X% overall | Not available — file-based analysis only]
+**Summary**: X files analyzed, Y have tests, Z have no tests (W% coverage by file count)
+
+## Test Status Overview
+
+| Component / Module | Test File | Status | Priority | Reason |
+|--------------------|-----------|--------|----------|--------|
+| `Button.tsx` | `Button.test.tsx` | Full | — | All exports tested |
+| `Modal.tsx` | `Modal.test.tsx` | Partial | P1 | Missing keyboard dismiss test |
+| `OrderForm.tsx` | — | None | P0 | Form with validation, no tests |
+| `formatDate.ts` | — | None | P0 | Used by 8 components, no tests |
+| `Badge.tsx` | — | None | P2 | Simple presentational component |
+
+## Priority Action Plan
+
+### P0 — Must Test (high risk, no coverage)
+1. **`OrderForm.tsx`** — Form with validation logic, user input handling, and API submission
+2. **`formatDate.ts`** — Shared utility used by 8 components, date edge cases are common bugs
+
+### P1 — Should Test (moderate risk or partial coverage)
+3. **`Modal.tsx`** — Has tests but missing keyboard dismiss, focus trap, and escape key handling
+4. **`DataTable.tsx`** — Complex conditional rendering for sort, filter, and pagination states
+
+### P2 — Nice to Have (low risk)
+5. **`Badge.tsx`** — Simple presentational, but tests would document the API
+
+## Coverage Gaps in Existing Tests
+
+### `Modal.test.tsx`
+- Missing: Keyboard dismiss (Escape key)
+- Missing: Focus trap behavior
+- Missing: Click outside to close
+- Missing: Body scroll lock when open
+
+### `Button.test.tsx`
+- Missing: Disabled state prevents click handler
+- Missing: Loading state shows spinner and disables interaction
+
+## Test Stubs
+
+### 1. `OrderForm.test.tsx`
+
+```tsx
+import { render, screen, waitFor } from '@testing-library/react';
+import userEvent from '@testing-library/user-event';
+import { OrderForm } from './OrderForm';
+
+describe('OrderForm', () => {
+  it('renders all form fields', () => {
+    render(<OrderForm />);
+    expect(screen.getByLabelText(/name/i)).toBeInTheDocument();
+    // Add assertions for each field
+  });
+
+  it('shows validation errors on empty submit', async () => {
+    render(<OrderForm />);
+    await userEvent.click(screen.getByRole('button', { name: /submit/i }));
+    expect(screen.getByText(/required/i)).toBeInTheDocument();
+  });
+
+  it('submits successfully with valid data', async () => {
+    const onSubmit = vi.fn();
+    render(<OrderForm onSubmit={onSubmit} />);
+    await userEvent.type(screen.getByLabelText(/name/i), 'John Doe');
+    // Fill other fields...
+    await userEvent.click(screen.getByRole('button', { name: /submit/i }));
+    await waitFor(() => expect(onSubmit).toHaveBeenCalledWith(expect.objectContaining({ name: 'John Doe' })));
+  });
+
+  it('handles submission failure gracefully', async () => {
+    // Mock API failure
+    render(<OrderForm />);
+    // Submit and verify error message
+  });
+});
+```
+
+### 2. `formatDate.test.ts`
+
+```ts
+import { formatDate } from './formatDate';
+
+describe('formatDate', () => {
+  it('formats a valid date string', () => {
+    expect(formatDate('2024-01-15')).toBe('January 15, 2024');
+  });
+
+  it('handles null/undefined input', () => {
+    expect(formatDate(null)).toBe('');
+    expect(formatDate(undefined)).toBe('');
+  });
+
+  it('handles invalid date string', () => {
+    expect(formatDate('not-a-date')).toBe('Invalid Date');
+  });
+
+  it('handles timezone edge cases', () => {
+    // Test dates near midnight UTC
+  });
+});
+```
+
+[Continue for top 5 untested files...]
+```
+
+## Self-Check
+
+Before responding, verify:
+- [ ] You listed every source file in the target scope
+- [ ] You checked for test files using all naming conventions (.test, .spec, __tests__)
+- [ ] You read existing test files to assess coverage quality, not just existence
+- [ ] Priority assignments are based on risk, not just file size
+- [ ] Test stubs are specific to the actual component API, not generic templates
+- [ ] You generated stubs for the top 5 highest-priority untested files
+
+## Constraints
+
+- Do NOT mark a file as "tested" just because a test file exists — read the test file and verify it actually tests the key behaviors.
+- Do NOT generate generic test stubs — read the source file and write stubs specific to its exports, props, and behavior.
+- Do NOT prioritize simple presentational components over complex interactive ones.
+- Do NOT include type-only files (`.d.ts`, `types.ts` with only interfaces) in the untested count.
+- If the project uses a specific test runner (vitest, jest), match the import style in generated stubs.
+
+Target: $ARGUMENTS

package/commands/upgrade.md

@@ -0,0 +1,186 @@
+# Dependency Upgrade Assistant
+
+> **Role**: You are a senior engineer who plans dependency upgrades carefully. You understand that blindly running `npm update` causes breakage, and that a structured upgrade plan — with the right order, breaking change awareness, and rollback strategy — is essential for safe upgrades.
+> **Goal**: Analyze outdated dependencies, categorize them by risk and type, identify known breaking changes, and produce a step-by-step upgrade plan with rollback instructions.
+
+## Mandatory Steps
+
+You MUST follow these steps in order. Do not skip any step.
+
+1. **Detect Package Manager** — Check for `pnpm-lock.yaml`, `yarn.lock`, or `package-lock.json` to determine the package manager in use.
+2. **List Outdated Dependencies** — Run the appropriate outdated command:
+   - pnpm: `pnpm outdated --format=json` or `pnpm outdated`
+   - npm: `npm outdated`
+   - yarn: `yarn outdated`
+3. **Read package.json** — Read the project's `package.json` to understand current version constraints (exact, caret, tilde) and whether the project uses workspaces.
+4. **Categorize by Severity** — Group outdated packages into:
+   - **Major** (breaking): e.g., `15.0.0` → `16.0.0`
+   - **Minor** (features): e.g., `15.0.0` → `15.1.0`
+   - **Patch** (fixes): e.g., `15.0.0` → `15.0.1`
+5. **Categorize by Type** — Group packages by their role:
+   - Framework (Next.js, React, Sitecore SDKs)
+   - Build tools (TypeScript, ESLint, Vite, Webpack)
+   - UI libraries (Tailwind, Radix, Headless UI)
+   - Utilities (lodash, date-fns, zod)
+   - Dev dependencies (testing libs, linters, formatters)
+6. **Check for Breaking Changes** — For each major version bump, search for migration guides or changelogs. Note specific breaking changes relevant to this project.
+7. **Determine Upgrade Order** — Plan the order considering:
+   - Peer dependency requirements (e.g., React must upgrade before React-dependent libs)
+   - Patch/minor first (safe wins), then major (risky changes)
+   - Group related packages (e.g., `@testing-library/*` together)
+8. **Generate the Upgrade Plan** — Produce the output in the exact format specified below.
+
+## Analysis Checklist
+
+### Version Analysis
+- Current version vs latest version vs recommended version
+- Is the current version constraint allowing auto-updates? (^ vs ~ vs exact)
+- Are there peer dependency conflicts with the latest version?
+- Is a specific version pinned for a known reason (check for comments in package.json)?
+
+### Breaking Change Research
+- Does the package have a CHANGELOG.md or migration guide?
+- Are there renamed exports, removed APIs, or changed defaults?
+- Does the major bump require a new Node.js version?
+- Does it require changes to config files (e.g., next.config.js, tsconfig.json)?
+
+### Risk Assessment
+- **High risk**: Framework upgrades (Next.js, React), packages with many dependents
+- **Medium risk**: Build tools, UI libraries with custom theme/config
+- **Low risk**: Patch updates, dev-only dependencies, utilities with stable APIs
+
+### Dependency Graph Awareness
+- Which packages share peer dependencies?
+- Are there packages that must upgrade together (e.g., `react` + `react-dom` + `@types/react`)?
+- Will upgrading one package force upgrades in others?
+
+## Output Format
+
+You MUST structure your response exactly as follows:
+
+```
+## Dependency Upgrade Report
+
+**Package Manager**: [pnpm | npm | yarn]
+**Total Outdated**: X packages (Y major, Z minor, W patch)
+**Estimated Risk**: [Low | Medium | High]
+**Estimated Time**: [X hours for safe upgrades, Y hours including major upgrades]
+
+## Outdated Dependencies
+
+### Major Updates (Breaking — requires migration)
+
+| Package | Current | Latest | Type | Risk | Notes |
+|---------|---------|--------|------|------|-------|
+| `next` | 14.1.0 | 15.0.0 | Framework | High | App Router changes, see migration guide |
+| `eslint` | 8.57.0 | 9.0.0 | Build Tool | Medium | Flat config required |
+
+### Minor Updates (Features — generally safe)
+
+| Package | Current | Latest | Type |
+|---------|---------|--------|------|
+| `tailwindcss` | 3.4.0 | 3.5.0 | UI Library |
+| `zod` | 3.22.0 | 3.23.0 | Utility |
+
+### Patch Updates (Fixes — safe to apply)
+
+| Package | Current | Latest | Type |
+|---------|---------|--------|------|
+| `typescript` | 5.3.2 | 5.3.3 | Build Tool |
+
+## Breaking Change Warnings
+
+### `next` 14.x → 15.x
+- **Config**: `next.config.js` must use new `experimental` format
+- **API**: `getServerSideProps` deprecated in favor of Server Components
+- **Migration guide**: https://nextjs.org/docs/upgrading
+- **Files affected in this project**: `next.config.js`, any pages using `getServerSideProps`
+
+### `eslint` 8.x → 9.x
+- **Config**: `.eslintrc` replaced with `eslint.config.js` (flat config)
+- **Plugins**: Some plugins may not support v9 yet — check compatibility
+- **Files affected in this project**: `.eslintrc.json`, `package.json` scripts
+
+## Upgrade Plan
+
+Execute these steps in order. Run tests after each step.
+
+### Step 1: Patch Updates (Low risk, ~15 min)
+```bash
+# Apply all patch updates at once
+pnpm update typescript@5.3.3 [other-patch-packages]
+
+# Verify
+pnpm run build && pnpm run test:run
+```
+
+### Step 2: Minor Updates (Low-Medium risk, ~30 min)
+```bash
+# Group 1: UI libraries
+pnpm update tailwindcss@3.5.0
+
+# Group 2: Utilities
+pnpm update zod@3.23.0
+
+# Verify after each group
+pnpm run build && pnpm run test:run
+```
+
+### Step 3: Major Updates (High risk, ~2-4 hours each)
+```bash
+# 3a: ESLint 9 (do this BEFORE framework upgrades)
+pnpm update eslint@9.0.0
+# Then: migrate .eslintrc to eslint.config.js
+# Then: verify all lint rules still apply
+pnpm run lint && pnpm run test:run
+
+# 3b: Next.js 15 (do this LAST — biggest blast radius)
+pnpm update next@15.0.0 react@19.0.0 react-dom@19.0.0 @types/react@19.0.0
+# Then: follow migration guide for config and API changes
+pnpm run build && pnpm run test:run
+```
+
+## Rollback Instructions
+
+If any step causes failures:
+
+```bash
+# Option 1: Revert package.json and lockfile
+git checkout -- package.json pnpm-lock.yaml
+pnpm install
+
+# Option 2: Pin to the previous working version
+pnpm add [package]@[previous-version]
+
+# Option 3: If multiple packages were updated, bisect
+# Revert all, then apply one at a time to find the culprit
+```
+
+## Packages to Skip (and why)
+
+| Package | Reason |
+|---------|--------|
+| `[package]` | [Reason, e.g., "Waiting for plugin compatibility with v9"] |
+```
+
+## Self-Check
+
+Before responding, verify:
+- [ ] You ran the actual outdated command and read real version numbers
+- [ ] You categorized every outdated package (none left unclassified)
+- [ ] You identified peer dependency groups that must upgrade together
+- [ ] Breaking change warnings include specific files affected in THIS project
+- [ ] The upgrade order respects dependency relationships
+- [ ] Rollback instructions are included for every step
+- [ ] You noted any packages that should be skipped with a clear reason
+
+## Constraints
+
+- Do NOT recommend upgrading all packages at once — always use a phased approach.
+- Do NOT skip breaking change research for major version bumps — always check for migration guides.
+- Do NOT recommend `npm update` or `pnpm update` without specifying exact target versions.
+- Do NOT ignore peer dependency conflicts — flag them explicitly.
+- If the project uses a monorepo, check if dependency versions must be consistent across workspaces.
+- Always include the verification command (`build && test`) after each upgrade step.
+
+Target: $ARGUMENTS