shmakk 1.1.0 → 1.2.0

package/skills/frontend-web-design-reviewer.md

@@ -0,0 +1,369 @@
+---
+name: web-design-reviewer
+description: 'This skill enables visual inspection of websites running locally or remotely to identify and fix design issues. Triggers on requests like "review website design", "check the UI", "fix the layout", "find design problems". Detects issues with responsive design, accessibility, visual consistency, and layout breakage, then performs fixes at the source code level.'
+category: frontend
+---
+
+# Web Design Reviewer
+
+This skill enables visual inspection and validation of website design quality, identifying and fixing issues at the source code level.
+
+## Scope of Application
+
+- Static sites (HTML/CSS/JS)
+- SPA frameworks such as React / Vue / Angular / Svelte
+- Full-stack frameworks such as Next.js / Nuxt / SvelteKit
+- CMS platforms such as WordPress / Drupal
+- Any other web application
+
+## Prerequisites
+
+### Required
+
+1. **Target website must be running**
+   - Local development server (e.g., `http://localhost:3000`)
+   - Staging environment
+   - Production environment (for read-only reviews)
+
+2. **Browser automation must be available**
+   - Screenshot capture
+   - Page navigation
+   - DOM information retrieval
+
+3. **Access to source code (when making fixes)**
+   - Project must exist within the workspace
+
+## Workflow Overview
+
+```mermaid
+flowchart TD
+    A[Step 1: Information Gathering] --> B[Step 2: Visual Inspection]
+    B --> C[Step 3: Issue Fixing]
+    C --> D[Step 4: Re-verification]
+    D --> E{Issues Remaining?}
+    E -->|Yes| B
+    E -->|No| F[Completion Report]
+```
+
+---
+
+## Step 1: Information Gathering Phase
+
+### 1.1 URL Confirmation
+
+If the URL is not provided, ask the user:
+
+> Please provide the URL of the website to review (e.g., `http://localhost:3000`)
+
+### 1.2 Understanding Project Structure
+
+When making fixes, gather the following information:
+
+| Item | Example Question |
+|------|------------------|
+| Framework | Are you using React / Vue / Next.js, etc.? |
+| Styling Method | CSS / SCSS / Tailwind / CSS-in-JS, etc. |
+| Source Location | Where are style files and components located? |
+| Review Scope | Specific pages only or entire site? |
+
+### 1.3 Automatic Project Detection
+
+Attempt automatic detection from files in the workspace:
+
+```
+Detection targets:
+├── package.json     → Framework and dependencies
+├── tsconfig.json    → TypeScript usage
+├── tailwind.config  → Tailwind CSS
+├── next.config      → Next.js
+├── vite.config      → Vite
+├── nuxt.config      → Nuxt
+└── src/ or app/     → Source directory
+```
+
+### 1.4 Identifying Styling Method
+
+| Method | Detection | Edit Target |
+|--------|-----------|-------------|
+| Pure CSS | `*.css` files | Global CSS or component CSS |
+| SCSS/Sass | `*.scss`, `*.sass` | SCSS files |
+| CSS Modules | `*.module.css` | Module CSS files |
+| Tailwind CSS | `tailwind.config.*` | className in components |
+| styled-components | `styled.` in code | JS/TS files |
+| Emotion | `@emotion/` imports | JS/TS files |
+| CSS-in-JS (other) | Inline styles | JS/TS files |
+
+---
+
+## Step 2: Visual Inspection Phase
+
+### 2.1 Page Traversal
+
+1. Navigate to the specified URL
+2. Capture screenshots
+3. Retrieve DOM structure/snapshot (if possible)
+4. If additional pages exist, traverse through navigation
+
+### 2.2 Inspection Items
+
+#### Layout Issues
+
+| Issue | Description | Severity |
+|-------|-------------|----------|
+| Element Overflow | Content overflows from parent element or viewport | High |
+| Element Overlap | Unintended overlapping of elements | High |
+| Alignment Issues | Grid or flex alignment problems | Medium |
+| Inconsistent Spacing | Padding/margin inconsistencies | Medium |
+| Text Clipping | Long text not handled properly | Medium |
+
+#### Responsive Issues
+
+| Issue | Description | Severity |
+|-------|-------------|----------|
+| Non-mobile Friendly | Layout breaks on small screens | High |
+| Breakpoint Issues | Unnatural transitions when screen size changes | Medium |
+| Touch Targets | Buttons too small on mobile | Medium |
+
+#### Accessibility Issues
+
+| Issue | Description | Severity |
+|-------|-------------|----------|
+| Insufficient Contrast | Low contrast ratio between text and background | High |
+| No Focus State | Cannot determine state during keyboard navigation | High |
+| Missing alt Text | No alternative text for images | Medium |
+
+#### Visual Consistency
+
+| Issue | Description | Severity |
+|-------|-------------|----------|
+| Font Inconsistency | Mixed font families | Medium |
+| Color Inconsistency | Non-unified brand colors | Medium |
+| Spacing Inconsistency | Non-uniform spacing between similar elements | Low |
+
+### 2.3 Viewport Testing (Responsive)
+
+Test at the following viewports:
+
+| Name | Width | Representative Device |
+|------|-------|----------------------|
+| Mobile | 375px | iPhone SE/12 mini |
+| Tablet | 768px | iPad |
+| Desktop | 1280px | Standard PC |
+| Wide | 1920px | Large display |
+
+---
+
+## Step 3: Issue Fixing Phase
+
+### 3.1 Issue Prioritization
+
+```mermaid
+block-beta
+    columns 1
+    block:priority["Priority Matrix"]
+        P1["P1: Fix Immediately\n(Layout issues affecting functionality)"]
+        P2["P2: Fix Next\n(Visual issues degrading UX)"]
+        P3["P3: Fix If Possible\n(Minor visual inconsistencies)"]
+    end
+```
+
+### 3.2 Identifying Source Files
+
+Identify source files from problematic elements:
+
+1. **Selector-based Search**
+   - Search codebase by class name or ID
+   - Explore style definitions with `grep_search`
+
+2. **Component-based Search**
+   - Identify components from element text or structure
+   - Explore related files with `semantic_search`
+
+3. **File Pattern Filtering**
+   ```
+   Style files: src/**/*.css, styles/**/*
+   Components: src/components/**/*
+   Pages: src/pages/**, app/**
+   ```
+
+### 3.3 Applying Fixes
+
+#### Framework-specific Fix Guidelines
+
+See [references/framework-fixes.md](references/framework-fixes.md) for details.
+
+#### Fix Principles
+
+1. **Minimal Changes**: Only make the minimum changes necessary to resolve the issue
+2. **Respect Existing Patterns**: Follow existing code style in the project
+3. **Avoid Breaking Changes**: Be careful not to affect other areas
+4. **Add Comments**: Add comments to explain the reason for fixes where appropriate
+
+---
+
+## Step 4: Re-verification Phase
+
+### 4.1 Post-fix Confirmation
+
+1. Reload browser (or wait for development server HMR)
+2. Capture screenshots of fixed areas
+3. Compare before and after
+
+### 4.2 Regression Testing
+
+- Verify that fixes haven't affected other areas
+- Confirm responsive display is not broken
+
+### 4.3 Iteration Decision
+
+```mermaid
+flowchart TD
+    A{Issues Remaining?}
+    A -->|Yes| B[Return to Step 2]
+    A -->|No| C[Proceed to Completion Report]
+```
+
+**Iteration Limit**: If more than 3 fix attempts are needed for a specific issue, consult the user
+
+---
+
+## Output Format
+
+### Review Results Report
+
+```markdown
+# Web Design Review Results
+
+## Summary
+
+| Item | Value |
+|------|-------|
+| Target URL | {URL} |
+| Framework | {Detected framework} |
+| Styling | {CSS / Tailwind / etc.} |
+| Tested Viewports | Desktop, Mobile |
+| Issues Detected | {N} |
+| Issues Fixed | {M} |
+
+## Detected Issues
+
+### [P1] {Issue Title}
+
+- **Page**: {Page path}
+- **Element**: {Selector or description}
+- **Issue**: {Detailed description of the issue}
+- **Fixed File**: `{File path}`
+- **Fix Details**: {Description of changes}
+- **Screenshot**: Before/After
+
+### [P2] {Issue Title}
+...
+
+## Unfixed Issues (if any)
+
+### {Issue Title}
+- **Reason**: {Why it was not fixed/could not be fixed}
+- **Recommended Action**: {Recommendations for user}
+
+## Recommendations
+
+- {Suggestions for future improvements}
+```
+
+---
+
+## Required Capabilities
+
+| Capability | Description | Required |
+|------------|-------------|----------|
+| Web Page Navigation | Access URLs, page transitions | ✅ |
+| Screenshot Capture | Page image capture | ✅ |
+| Image Analysis | Visual issue detection | ✅ |
+| DOM Retrieval | Page structure retrieval | Recommended |
+| File Read/Write | Source code reading and editing | Required for fixes |
+| Code Search | Code search within project | Required for fixes |
+
+---
+
+## Reference Implementation
+
+### Implementation with Playwright MCP
+
+[Playwright MCP](https://github.com/microsoft/playwright-mcp) is recommended as the reference implementation for this skill.
+
+| Capability | Playwright MCP Tool | Purpose |
+|------------|---------------------|---------|
+| Navigation | `browser_navigate` | Access URLs |
+| Snapshot | `browser_snapshot` | Retrieve DOM structure |
+| Screenshot | `browser_take_screenshot` | Images for visual inspection |
+| Click | `browser_click` | Interact with interactive elements |
+| Resize | `browser_resize` | Responsive testing |
+| Console | `browser_console_messages` | Detect JS errors |
+
+#### Configuration Example (MCP Server)
+
+```json
+{
+  "mcpServers": {
+    "playwright": {
+      "command": "npx",
+      "args": ["-y", "@playwright/mcp@latest", "--caps=vision"]
+    }
+  }
+}
+```
+
+### Other Compatible Browser Automation Tools
+
+| Tool | Features |
+|------|----------|
+| Selenium | Broad browser support, multi-language support |
+| Puppeteer | Chrome/Chromium focused, Node.js |
+| Cypress | Easy integration with E2E testing |
+| WebDriver BiDi | Standardized next-generation protocol |
+
+The same workflow can be implemented with these tools. As long as they provide the necessary capabilities (navigation, screenshot, DOM retrieval), the choice of tool is flexible.
+
+---
+
+## Best Practices
+
+### DO (Recommended)
+
+- ✅ Always save screenshots before making fixes
+- ✅ Fix one issue at a time and verify each
+- ✅ Follow the project's existing code style
+- ✅ Confirm with user before major changes
+- ✅ Document fix details thoroughly
+
+### DON'T (Not Recommended)
+
+- ❌ Large-scale refactoring without confirmation
+- ❌ Ignoring design systems or brand guidelines
+- ❌ Fixes that ignore performance
+- ❌ Fixing multiple issues at once (difficult to verify)
+
+---
+
+## Troubleshooting
+
+### Problem: Style files not found
+
+1. Check dependencies in `package.json`
+2. Consider the possibility of CSS-in-JS
+3. Consider CSS generated at build time
+4. Ask user about styling method
+
+### Problem: Fixes not reflected
+
+1. Check if development server HMR is working
+2. Clear browser cache
+3. Rebuild if project requires build
+4. Check CSS specificity issues
+
+### Problem: Fixes affecting other areas
+
+1. Rollback changes
+2. Use more specific selectors
+3. Consider using CSS Modules or scoped styles
+4. Consult user to confirm impact scope

package/skills/frontend-web-perf.md

@@ -0,0 +1,202 @@
+---
+name: web-perf
+description: Analyzes web performance using Chrome DevTools MCP. Measures Core Web Vitals (FCP, LCP, TBT, CLS, Speed Index), identifies render-blocking resources, network dependency chains, layout shifts, caching issues, and accessibility gaps. Use when asked to audit, profile, debug, or optimize page load performance, Lighthouse scores, or site speed. Biases towards retrieval from current documentation over pre-trained knowledge.
+category: frontend
+---
+
+# Web Performance Audit
+
+Your knowledge of web performance metrics, thresholds, and tooling APIs may be outdated. **Prefer retrieval over pre-training** when citing specific numbers or recommendations.
+
+## Retrieval Sources
+
+| Source | How to retrieve | Use for |
+|--------|----------------|---------|
+| web.dev | `https://web.dev/articles/vitals` | Core Web Vitals thresholds, definitions |
+| Chrome DevTools docs | `https://developer.chrome.com/docs/devtools/performance` | Tooling APIs, trace analysis |
+| Lighthouse scoring | `https://developer.chrome.com/docs/lighthouse/performance/performance-scoring` | Score weights, metric thresholds |
+
+## FIRST: Verify MCP Tools Available
+
+**Run this before starting.** Try calling `navigate_page` or `performance_start_trace`. If unavailable, STOP—the chrome-devtools MCP server isn't configured.
+
+Ask the user to add this to their MCP config:
+
+```json
+"chrome-devtools": {
+  "type": "local",
+  "command": ["npx", "-y", "chrome-devtools-mcp@latest"]
+}
+```
+
+## Key Guidelines
+
+- **Be assertive**: Verify claims by checking network requests, DOM, or codebase—then state findings definitively.
+- **Verify before recommending**: Confirm something is unused before suggesting removal.
+- **Quantify impact**: Use estimated savings from insights. Don't prioritize changes with 0ms impact.
+- **Skip non-issues**: If render-blocking resources have 0ms estimated impact, note but don't recommend action.
+- **Be specific**: Say "compress hero.png (450KB) to WebP" not "optimize images".
+- **Prioritize ruthlessly**: A site with 200ms LCP and 0 CLS is already excellent—say so.
+
+## Quick Reference
+
+| Task | Tool Call |
+|------|-----------|
+| Load page | `navigate_page(url: "...")` |
+| Start trace | `performance_start_trace(autoStop: true, reload: true)` |
+| Analyze insight | `performance_analyze_insight(insightSetId: "...", insightName: "...")` |
+| List requests | `list_network_requests(resourceTypes: ["Script", "Stylesheet", ...])` |
+| Request details | `get_network_request(reqid: <id>)` |
+| A11y snapshot | `take_snapshot(verbose: true)` |
+
+## Workflow
+
+Copy this checklist to track progress:
+
+```
+Audit Progress:
+- [ ] Phase 1: Performance trace (navigate + record)
+- [ ] Phase 2: Core Web Vitals analysis (includes CLS culprits)
+- [ ] Phase 3: Network analysis
+- [ ] Phase 4: Accessibility snapshot
+- [ ] Phase 5: Codebase analysis (skip if third-party site)
+```
+
+### Phase 1: Performance Trace
+
+1. Navigate to the target URL:
+   ```
+   navigate_page(url: "<target-url>")
+   ```
+
+2. Start a performance trace with reload to capture cold-load metrics:
+   ```
+   performance_start_trace(autoStop: true, reload: true)
+   ```
+
+3. Wait for trace completion, then retrieve results.
+
+**Troubleshooting:**
+- If trace returns empty or fails, verify the page loaded correctly with `navigate_page` first
+- If insight names don't match, inspect the trace response to list available insights
+
+### Phase 2: Core Web Vitals Analysis
+
+Use `performance_analyze_insight` to extract key metrics.
+
+**Note:** Insight names may vary across Chrome DevTools versions. If an insight name doesn't work, check the `insightSetId` from the trace response to discover available insights.
+
+Common insight names:
+
+| Metric | Insight Name | What to Look For |
+|--------|--------------|------------------|
+| LCP | `LCPBreakdown` | Time to largest contentful paint; breakdown of TTFB, resource load, render delay |
+| CLS | `CLSCulprits` | Elements causing layout shifts (images without dimensions, injected content, font swaps) |
+| Render Blocking | `RenderBlocking` | CSS/JS blocking first paint |
+| Document Latency | `DocumentLatency` | Server response time issues |
+| Network Dependencies | `NetworkRequestsDepGraph` | Request chains delaying critical resources |
+
+Example:
+```
+performance_analyze_insight(insightSetId: "<id-from-trace>", insightName: "LCPBreakdown")
+```
+
+**Key thresholds (good/needs-improvement/poor):**
+- TTFB: < 800ms / < 1.8s / > 1.8s
+- FCP: < 1.8s / < 3s / > 3s
+- LCP: < 2.5s / < 4s / > 4s
+- INP: < 200ms / < 500ms / > 500ms
+- TBT: < 200ms / < 600ms / > 600ms
+- CLS: < 0.1 / < 0.25 / > 0.25
+- Speed Index: < 3.4s / < 5.8s / > 5.8s
+
+### Phase 3: Network Analysis
+
+List all network requests to identify optimization opportunities:
+```
+list_network_requests(resourceTypes: ["Script", "Stylesheet", "Document", "Font", "Image"])
+```
+
+**Look for:**
+
+1. **Render-blocking resources**: JS/CSS in `<head>` without `async`/`defer`/`media` attributes
+2. **Network chains**: Resources discovered late because they depend on other resources loading first (e.g., CSS imports, JS-loaded fonts)
+3. **Missing preloads**: Critical resources (fonts, hero images, key scripts) not preloaded
+4. **Caching issues**: Missing or weak `Cache-Control`, `ETag`, or `Last-Modified` headers
+5. **Large payloads**: Uncompressed or oversized JS/CSS bundles
+6. **Unused preconnects**: If flagged, verify by checking if ANY requests went to that origin. If zero requests, it's definitively unused—recommend removal. If requests exist but loaded late, the preconnect may still be valuable.
+
+For detailed request info:
+```
+get_network_request(reqid: <id>)
+```
+
+### Phase 4: Accessibility Snapshot
+
+Take an accessibility tree snapshot:
+```
+take_snapshot(verbose: true)
+```
+
+**Flag high-level gaps:**
+- Missing or duplicate ARIA IDs
+- Elements with poor contrast ratios (check against WCAG AA: 4.5:1 for normal text, 3:1 for large text)
+- Focus traps or missing focus indicators
+- Interactive elements without accessible names
+
+## Phase 5: Codebase Analysis
+
+**Skip if auditing a third-party site without codebase access.**
+
+Analyze the codebase to understand where improvements can be made.
+
+### Detect Framework & Bundler
+
+Search for configuration files to identify the stack:
+
+| Tool | Config Files |
+|------|--------------|
+| Webpack | `webpack.config.js`, `webpack.*.js` |
+| Vite | `vite.config.js`, `vite.config.ts` |
+| Rollup | `rollup.config.js`, `rollup.config.mjs` |
+| esbuild | `esbuild.config.js`, build scripts with `esbuild` |
+| Parcel | `.parcelrc`, `package.json` (parcel field) |
+| Next.js | `next.config.js`, `next.config.mjs` |
+| Nuxt | `nuxt.config.js`, `nuxt.config.ts` |
+| SvelteKit | `svelte.config.js` |
+| Astro | `astro.config.mjs` |
+
+Also check `package.json` for framework dependencies and build scripts.
+
+### Tree-Shaking & Dead Code
+
+- **Webpack**: Check for `mode: 'production'`, `sideEffects` in package.json, `usedExports` optimization
+- **Vite/Rollup**: Tree-shaking enabled by default; check for `treeshake` options
+- **Look for**: Barrel files (`index.js` re-exports), large utility libraries imported wholesale (lodash, moment)
+
+### Unused JS/CSS
+
+- Check for CSS-in-JS vs. static CSS extraction
+- Look for PurgeCSS/UnCSS configuration (Tailwind's `content` config)
+- Identify dynamic imports vs. eager loading
+
+### Polyfills
+
+- Check for `@babel/preset-env` targets and `useBuiltIns` setting
+- Look for `core-js` imports (often oversized)
+- Check `browserslist` config for overly broad targeting
+
+### Compression & Minification
+
+- Check for `terser`, `esbuild`, or `swc` minification
+- Look for gzip/brotli compression in build output or server config
+- Check for source maps in production builds (should be external or disabled)
+
+## Output Format
+
+Present findings as:
+
+1. **Core Web Vitals Summary** - Table with metric, value, and rating (good/needs-improvement/poor)
+2. **Top Issues** - Prioritized list of problems with estimated impact (high/medium/low)
+3. **Recommendations** - Specific, actionable fixes with code snippets or config changes
+4. **Codebase Findings** - Framework/bundler detected, optimization opportunities (omit if no codebase access)

package/skills/frontend.md

@@ -0,0 +1,125 @@
+---
+name: frontend
+version: 1
+category: frontend
+---
+
+# Frontend Engineering
+
+Build, review, and debug frontend code across React, Vue, Angular, Svelte, HTML/CSS, and TypeScript.
+
+## When to use this skill
+
+- User is building or fixing UI components, pages, or layouts
+- User mentions React, Vue, Angular, Svelte, Next.js, Nuxt, Astro, or similar
+- User asks about state management (Redux, Zustand, Pinia, MobX)
+- User wants to fix styling, layout, or responsiveness issues
+- User mentions "component", "hook", "props", "CSS", "SCSS", "Tailwind"
+- User asks about bundle size, lazy loading, or frontend performance
+- User wants to improve accessibility (a11y) or keyboard navigation
+
+## Procedure
+
+### Step 1: Understand the stack
+
+Before writing any code, check:
+- What framework is in use? (package.json dependencies)
+- What styling approach? (CSS modules, Tailwind, styled-components, SCSS, plain CSS)
+- What state management? (Redux, Zustand, Context, Pinia, Vuex)
+- What build tool? (Vite, webpack, Parcel, Turbopack)
+- What TypeScript version and strictness?
+
+```bash
+cat package.json | grep -E '"(react|vue|angular|svelte|next|nuxt|vite|webpack)"'
+```
+
+### Step 2: Inspect existing conventions
+
+Match the patterns already in use — do not introduce a new pattern if one exists:
+- Read 2–3 existing components before creating a new one
+- Check how props are typed (interfaces vs. types, optional vs. required)
+- Check how events/callbacks are named (onClick, handleClick, onSubmit)
+- Check import paths and alias conventions
+
+### Step 3: Component design
+
+- **Single responsibility**: each component does one thing. If it needs a title, a helper, break it up.
+- **Props API**: prefer explicit over implicit. Avoid spreading `...rest` unless building a wrapper.
+- **Co-location**: keep styles, tests, and types near the component they belong to.
+- **Composition over configuration**: prefer composable children over complex prop-driven logic.
+
+### Step 4: Styling
+
+- Never use inline styles for layout or theme values — use tokens or utility classes.
+- Check for hardcoded pixel values that should reference spacing/typography tokens.
+- Verify responsive breakpoints match the project's grid system.
+- Test dark mode if the project supports it.
+
+### Step 5: Accessibility (a11y)
+
+Every interactive element must:
+- Be reachable via keyboard (Tab, Enter, Space, Escape)
+- Have an accessible name (aria-label, aria-labelledby, or visible text)
+- Have correct ARIA roles if using non-semantic elements
+- Maintain visible focus state (no `outline: none` without alternative)
+
+Color contrast: minimum 4.5:1 for normal text, 3:1 for large text (WCAG AA).
+
+### Step 6: Performance
+
+Check for:
+- Components re-rendering unnecessarily (missing `React.memo`, `useMemo`, `useCallback`)
+- Large lists rendered without virtualization (use `react-virtual`, `vue-virtual-scroll`)
+- Images without explicit width/height causing layout shift
+- Heavy dependencies imported at the top level (use dynamic import for lazily needed code)
+- Event listeners attached without cleanup in `useEffect`/`onUnmounted`
+
+### Step 7: Testing
+
+For any new component, add at minimum:
+- A smoke test (renders without crashing)
+- A behavior test (key interaction works)
+- An accessibility test (axe or jest-axe)
+
+Check test coverage:
+```bash
+npx jest --coverage --collectCoverageFrom='src/components/**' 2>&1 | tail -20
+```
+
+## Common patterns
+
+### React: data fetching with error/loading states
+```tsx
+function UserProfile({ userId }: { userId: string }) {
+  const { data, isLoading, error } = useUser(userId);
+  if (isLoading) return <Skeleton />;
+  if (error) return <ErrorMessage error={error} />;
+  return <ProfileCard user={data} />;
+}
+```
+
+### Vue 3: composable for async state
+```ts
+export function useAsync<T>(fn: () => Promise<T>) {
+  const data = ref<T | null>(null);
+  const error = ref<Error | null>(null);
+  const loading = ref(false);
+  const execute = async () => {
+    loading.value = true;
+    try { data.value = await fn(); }
+    catch (e) { error.value = e as Error; }
+    finally { loading.value = false; }
+  };
+  return { data, error, loading, execute };
+}
+```
+
+## Red flags to report
+
+- `any` types in TypeScript without justification
+- `dangerouslySetInnerHTML` or `v-html` with user-supplied content (XSS risk)
+- Direct DOM manipulation inside framework components
+- `useEffect` with missing or incorrect dependency arrays
+- Global state mutated directly (not via store actions)
+- Console logs left in production code
+- Bundle importing entire libraries when only one function is needed (e.g., `import _ from 'lodash'`)