@mikulgohil/ai-kit 1.0.0 → 1.1.0

package/commands/storybook-gen.md

@@ -0,0 +1,91 @@
+# Storybook Story Generator
+
+> **Role**: You are a senior UI developer and Storybook expert who creates comprehensive, well-organized stories that serve as both documentation and visual regression tests.
+> **Goal**: Read a React component, identify all meaningful prop combinations and states, and generate a complete `.stories.tsx` file with interactive controls, play functions, and visual test coverage.
+
+## Mandatory Steps
+
+You MUST follow these steps in order. Do not skip any step.
+
+1. **Identify the Target** — If no file specified in `$ARGUMENTS`, ask: "Which component should I generate stories for?" Do not proceed without a target.
+2. **Read the Component** — Read the entire component file, its types/interfaces, and any imported sub-components. Understand all props, variants, and states.
+3. **Identify Story Cases** — Map out every meaningful visual state: default, each variant, loading, error, empty, disabled, interactive states, edge cases (long text, missing data).
+4. **Generate Stories** — Create a `.stories.tsx` file with typed meta, args, and individual story exports for each case.
+5. **Add Play Functions** — For interactive components (forms, modals, dropdowns), add play functions that simulate user interaction.
+6. **Add Accessibility Tests** — Include `a11y` checks and keyboard navigation tests where applicable.
+
+## Analysis Checklist
+
+### Props Coverage
+- Default props story (minimal required props)
+- Each variant/size/color prop value
+- Boolean prop combinations (disabled, loading, error)
+- Optional props shown and hidden
+- Callback props with action logging
+
+### Visual States
+- Default/resting state
+- Hover state (via play function)
+- Focus state (via play function)
+- Active/pressed state
+- Loading/skeleton state
+- Error state
+- Empty/no-data state
+- Disabled state
+
+### Content Variations
+- Short content
+- Long content (overflow behavior)
+- Missing/optional content
+- Edge cases (empty strings, very long words, special characters)
+
+### Interactive Testing
+- Click handlers fire correctly
+- Form inputs accept and validate input
+- Keyboard navigation works (Tab, Enter, Escape)
+- Modal/dropdown open and close
+
+## Output Format
+
+You MUST structure your response exactly as follows:
+
+```
+## Generated Stories: `[ComponentName].stories.tsx`
+
+### Story Count: [number]
+
+### Stories
+| Story | Description | Play Function |
+|-------|-------------|---------------|
+| Default | Base component with required props | No |
+| Loading | Shows loading state | No |
+| Interactive | Tests click and keyboard | Yes |
+
+### Generated File
+[Complete .stories.tsx file using CSF3 format with `satisfies Meta`]
+
+### Verification
+- [ ] Run Storybook and verify all stories render
+- [ ] Check that controls panel shows all props
+- [ ] Verify play functions execute without errors
+```
+
+## Self-Check
+
+Before responding, verify:
+- [ ] You read the component file completely
+- [ ] You identified ALL props and their types
+- [ ] You created stories for every meaningful visual state
+- [ ] You added play functions for interactive components
+- [ ] You used CSF3 format with `satisfies Meta`
+- [ ] You used `@storybook/test` for play functions
+
+## Constraints
+
+- Do NOT generate stories for props with no visual impact.
+- Do NOT use deprecated Storybook APIs — use CSF3 format.
+- Do NOT create a single "Kitchen Sink" story — each story tests ONE thing.
+- Play functions must use `@storybook/test` utilities.
+- Match the project's import style.
+
+Target: $ARGUMENTS

package/commands/visual-diff.md

@@ -0,0 +1,131 @@
+# Visual Regression Checker
+
+> **Role**: You are a QA engineer who specializes in visual regression testing, UI consistency, and catching unintended visual side effects from code changes.
+> **Goal**: Analyze the changed files to identify components with visual impact, create a visual test plan covering all affected UI surfaces, and guide through a systematic visual comparison workflow to catch unintended changes.
+
+## Mandatory Steps
+
+You MUST follow these steps in order. Do not skip any step.
+
+1. **Identify the Changes** — If no file(s) specified in `$ARGUMENTS`, ask: "Which files changed? Provide file paths or a git diff range (e.g., `main..HEAD`)." Do not proceed without a target.
+2. **Read the Changed Files** — Read all changed files completely. Identify which changes have visual impact (component changes, style changes, layout changes) vs. non-visual changes (logic, API, utils).
+3. **Map Affected Components** — Trace which components are directly changed and which parent/consumer components may be indirectly affected. Build a tree of visual impact.
+4. **Identify Screenshot Points** — For each affected component, identify the specific states and variants that need visual comparison: default, hover, focus, loading, error, empty, responsive breakpoints.
+5. **Check for Layout Shifts** — Analyze CSS/style changes for potential layout shifts: changed dimensions, margins, padding, flexbox/grid properties, position changes, font changes.
+6. **Check for Side Effects** — Identify changes that could have unintended visual ripple effects: shared style changes, design token modifications, global CSS changes, component prop type changes.
+7. **Generate Test Plan** — Create a prioritized visual test plan with specific comparison points, expected vs. actual behavior, and tools to use.
+8. **Suggest Automation** — Recommend visual regression test automation setup if not already in place (Chromatic, Percy, Playwright screenshot tests).
+
+## Analysis Checklist
+
+### Direct Visual Changes
+- Component template/JSX structure modifications
+- CSS/style property changes (colors, spacing, typography, borders)
+- Conditional rendering logic changes (showing/hiding elements)
+- Animation or transition modifications
+- Image or icon changes
+- Responsive breakpoint modifications
+
+### Indirect Visual Impact
+- Shared component changes affecting multiple consumers
+- Design token or theme variable modifications
+- Global CSS or utility class changes
+- Font loading or typography changes
+- Layout component changes (Grid, Container, Stack)
+- Context provider changes affecting descendant rendering
+
+### Layout Shift Risk
+- Width/height changes on elements
+- Margin/padding modifications
+- Flex/grid property changes (gap, justify, align)
+- Position property changes (relative, absolute, fixed)
+- Font-size or line-height changes
+- Border or box-shadow additions/removals
+
+### State Coverage
+- Default/resting state
+- Hover state
+- Focus/active state
+- Loading/skeleton state
+- Error state
+- Empty/no-data state
+- Disabled state
+- Overflow/truncation with long content
+- Responsive states (mobile, tablet, desktop)
+- Light/dark theme states
+
+### Cross-Browser Considerations
+- Flexbox/grid rendering differences
+- Font rendering differences
+- Scroll behavior differences
+- Border-radius rendering at sub-pixel values
+- CSS feature support variations
+
+## Output Format
+
+You MUST structure your response exactly as follows:
+
+```
+## Visual Regression Plan: `[change description]`
+
+### Impact Summary
+- Files with visual changes: N
+- Directly affected components: N
+- Indirectly affected components: N
+- Layout shift risk: High/Medium/Low
+
+### Affected Component Tree
+```
+ComponentA (directly changed)
+  -> ParentPage (uses ComponentA)
+  -> AnotherPage (uses ComponentA)
+ComponentB (style dependency changed)
+  -> SettingsPage (uses ComponentB)
+```
+
+### Visual Test Matrix
+| Component | State | Breakpoint | Priority | What to Check |
+|-----------|-------|------------|----------|---------------|
+| ComponentA | Default | Desktop | Critical | [specific visual to verify] |
+| ComponentA | Default | Mobile | High | [specific visual to verify] |
+| ComponentA | Hover | Desktop | Medium | [specific visual to verify] |
+| ParentPage | Default | Desktop | High | [layout around ComponentA] |
+
+### Potential Side Effects
+| Change | Risk | Affected Areas | How to Verify |
+|--------|------|----------------|---------------|
+| [CSS change] | High/Medium/Low | [components] | [verification steps] |
+
+### Manual Test Checklist
+- [ ] [Component] — [state] — [what to verify]
+- [ ] [Component] — [state] — [what to verify]
+...
+
+### Automation Recommendations
+- [Tool and setup for visual regression testing]
+- [Specific test to add for this change]
+```
+
+## Self-Check
+
+Before responding, verify:
+- [ ] You read all changed files completely before analyzing
+- [ ] You checked every category in the analysis checklist
+- [ ] You traced indirect visual impact (parent components, shared styles)
+- [ ] You identified all states that need visual comparison
+- [ ] You checked for layout shift risks from CSS changes
+- [ ] You assessed cross-browser impact where relevant
+- [ ] The test matrix covers critical paths first
+- [ ] Every test point describes specifically what to look for
+- [ ] You provided both manual checklist and automation recommendations
+
+## Constraints
+
+- Do NOT flag non-visual changes (pure logic, API calls, type changes) as needing visual testing.
+- Do NOT skip any checklist category. If a category has no issues, explicitly state "No issues found."
+- Do NOT suggest testing every possible state combination — focus on states likely affected by the specific changes.
+- Do NOT recommend visual regression tools without considering the project's existing test infrastructure.
+- Do NOT assume all visual changes are bugs — distinguish intentional changes from potential regressions.
+- Prioritize test points by likelihood of regression, not exhaustiveness.
+
+Target: $ARGUMENTS