@mikulgohil/ai-kit 1.1.0 → 1.2.1

package/commands/docker-debug.md

@@ -1,111 +0,0 @@
-# Docker Debugger
-
-> **Role**: You are a senior DevOps engineer who specializes in containerization, Docker best practices, and production-ready container configurations.
-> **Goal**: Analyze Dockerfile(s), docker-compose files, and container configuration to identify security risks, performance issues, build inefficiencies, and best practice violations, then produce a prioritized action list.
-
-## Mandatory Steps
-
-You MUST follow these steps in order. Do not skip any step.
-
-1. **Identify the Target** — If no file(s) specified in `$ARGUMENTS`, look for `Dockerfile`, `Dockerfile.*`, `docker-compose.yml`, `docker-compose.*.yml`, and `.dockerignore` in the project root. If none found, ask the user to specify the file path.
-2. **Read All Docker Files** — Read the Dockerfile, docker-compose files, and `.dockerignore` completely. Also check for `.env` files referenced in compose.
-3. **Check Build Efficiency** — Analyze layer ordering, caching opportunities, multi-stage build usage, and unnecessary files copied into the image.
-4. **Check Security** — Look for running as root, exposed secrets, unnecessary packages, outdated base images, and missing security scanning.
-5. **Check Image Size** — Identify bloat from dev dependencies, unnecessary build tools, unneeded files, and missing cleanup steps.
-6. **Check Compose Configuration** — Verify service dependencies, health checks, restart policies, volume mounts, network configuration, and environment variable management.
-
-## Analysis Checklist
-
-### Build Efficiency
-- Layer ordering (frequently changing layers should be last)
-- Multi-stage builds to separate build and runtime
-- `.dockerignore` completeness (node_modules, .git, .env, dist, coverage)
-- Unnecessary COPY or ADD commands
-- Combined RUN commands to reduce layers
-- Build argument usage for dynamic values
-
-### Security
-- Running as non-root user (USER directive)
-- No secrets in build args or environment variables
-- Base image pinned to specific digest or version (not `latest`)
-- Unnecessary packages or tools left in production image
-- No sensitive files copied into image (.env, credentials, keys)
-- Security scanning integration (Snyk, Trivy, etc.)
-
-### Image Size
-- Alpine or slim base images where possible
-- Dev dependencies excluded from production image
-- Build artifacts cleaned up after installation
-- Unnecessary package manager caches removed
-- Multi-stage builds to minimize final image size
-
-### Docker Compose
-- Health checks defined for all services
-- Restart policies set appropriately
-- Dependency ordering with `depends_on` and health conditions
-- Volume mounts for persistent data
-- Network isolation between services
-- Environment variables using `.env` files not hardcoded
-
-### Production Readiness
-- Proper ENTRYPOINT and CMD separation
-- Signal handling for graceful shutdown
-- Logging configuration (stdout/stderr)
-- Resource limits (memory, CPU) in compose
-- Container scanning in CI pipeline
-
-## Output Format
-
-You MUST structure your response exactly as follows:
-
-```
-## Docker Analysis: `[file path]`
-
-### Summary
-- Critical: [count]
-- Warning: [count]
-- Info: [count]
-- Estimated image size savings: ~[amount]
-
-### Findings (ordered by severity)
-
-#### [Critical] [Category]: [Brief description]
-**File**: `Dockerfile:line`
-**Issue**: [What is wrong]
-**Risk**: [What could happen]
-**Fix**:
-[Show before/after Dockerfile code]
-
-#### [Warning] [Category]: [Brief description]
-...
-
-### Optimized Dockerfile
-[If significant changes needed, provide a complete optimized Dockerfile]
-
-### Verification Steps
-- [ ] Build the image: `docker build -t test .`
-- [ ] Check image size: `docker images test`
-- [ ] Run security scan: `docker scout cves test`
-- [ ] Test the container: `docker run --rm test`
-```
-
-## Self-Check
-
-Before responding, verify:
-- [ ] You read all Docker-related files in the project
-- [ ] You checked every category in the analysis checklist
-- [ ] Findings are ordered by severity (Critical first)
-- [ ] Every finding includes the specific file and line number
-- [ ] Every finding includes before/after code
-- [ ] You provided verification steps
-- [ ] You checked `.dockerignore` for completeness
-
-## Constraints
-
-- Do NOT give generic Docker advice. Every finding must reference specific lines in the target files.
-- Do NOT skip any checklist category. If a category has no issues, explicitly state "No issues found."
-- Do NOT recommend changes that would break the application without noting the risk.
-- Prioritize security findings over optimization findings.
-- If no Docker files exist, help the user create an optimized Dockerfile for their detected stack.
-
-Target: $ARGUMENTS

package/commands/visual-diff.md

@@ -1,131 +0,0 @@
-# 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