@harness-engineering/cli 1.24.0 → 1.24.1

package/dist/agents/skills/claude-code/perf-cdn-strategies/skill.yaml

@@ -0,0 +1,40 @@
+name: perf-cdn-strategies
+version: '1.0.0'
+description: CDN architecture — edge caching, origin shielding, cache tiers, edge compute, and multi-CDN strategies
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - perf-cdn-cache-control
+  - perf-browser-cache
+  - perf-connection-costs
+  - perf-compression
+  - perf-edge-rendering
+  - otel-performance-insights
+stack_signals: []
+keywords:
+  - cdn
+  - edge caching
+  - origin shielding
+  - cache tier
+  - edge compute
+  - pop
+  - anycast
+  - multi-cdn
+  - cache hit ratio
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/claude-code/perf-client-side-rendering/SKILL.md

@@ -0,0 +1,245 @@
+# Client-Side Rendering
+
+> Master client-side rendering performance — SPA rendering optimization, reducing unnecessary re-renders, skeleton screen patterns, progressive rendering strategies, virtual DOM efficiency, React performance profiling, and concurrent rendering features for responsive user interfaces.
+
+## When to Use
+
+- A SPA has slow initial render due to large JavaScript bundles
+- React DevTools Profiler shows components re-rendering unnecessarily
+- User interactions feel sluggish (INP > 200ms) in a client-rendered application
+- Skeleton screens are needed to improve perceived performance during data fetching
+- State changes in parent components cause expensive child re-renders
+- A dashboard with many widgets re-renders all widgets when one updates
+- Form inputs lag because typing triggers expensive renders in unrelated components
+- List rendering with hundreds of items causes visible frame drops
+- Transitioning between views in a SPA shows blank content instead of loading states
+- React concurrent features (useTransition, useDeferredValue) could improve responsiveness
+
+## Instructions
+
+1. **Profile rendering with React DevTools Profiler.** Identify which components render, why, and how long they take:
+
+   ```
+   1. Open React DevTools → Profiler tab
+   2. Click "Record" → interact with the application → "Stop"
+   3. Examine the flame chart:
+      - Gray components: did not render
+      - Colored components: rendered (warmer = slower)
+      - "Why did this render?" shows the trigger
+   4. Look for:
+      - Components rendering on unrelated state changes
+      - Large subtrees re-rendering for small changes
+      - Components rendering >16ms (frame budget)
+   ```
+
+2. **Prevent unnecessary re-renders with memoization.** Use React.memo, useMemo, and useCallback strategically:
+
+   ```typescript
+   // React.memo: skip re-render when props are unchanged
+   const ExpensiveList = React.memo(function ExpensiveList({
+     items,
+     onItemClick,
+   }: {
+     items: Item[];
+     onItemClick: (id: string) => void;
+   }) {
+     return (
+       <ul>
+         {items.map(item => (
+           <ListItem key={item.id} item={item} onClick={onItemClick} />
+         ))}
+       </ul>
+     );
+   });
+
+   // Parent: stabilize callback reference
+   function Dashboard() {
+     const [items, setItems] = useState<Item[]>([]);
+     const [selectedId, setSelectedId] = useState<string | null>(null);
+
+     // useCallback: stable reference across renders
+     const handleItemClick = useCallback((id: string) => {
+       setSelectedId(id);
+     }, []);
+
+     return (
+       <>
+         <Sidebar selectedId={selectedId} />
+         <ExpensiveList items={items} onItemClick={handleItemClick} />
+       </>
+     );
+   }
+   ```
+
+3. **Implement skeleton screens for data-loading states.** Skeletons reduce perceived load time by 15-30%:
+
+   ```typescript
+   function ProductGrid() {
+     const { data, isLoading } = useProducts();
+
+     if (isLoading) {
+       return (
+         <div className="grid">
+           {Array.from({ length: 12 }, (_, i) => (
+             <ProductCardSkeleton key={i} />
+           ))}
+         </div>
+       );
+     }
+
+     return (
+       <div className="grid">
+         {data.map(product => <ProductCard key={product.id} product={product} />)}
+       </div>
+     );
+   }
+   ```
+
+   Use a CSS shimmer animation (`background: linear-gradient(90deg, #f0f0f0 25%, #e0e0e0 50%, #f0f0f0 75%); background-size: 200% 100%; animation: shimmer 1.5s infinite`) on `.skeleton` elements with explicit dimensions matching the loaded content to prevent layout shift.
+
+4. **Use concurrent rendering for responsive interactions.** React 18 concurrent features prevent expensive renders from blocking user input:
+
+   ```typescript
+   import { useTransition, useDeferredValue } from 'react';
+
+   // useTransition: mark state updates as non-urgent
+   function SearchPage() {
+     const [query, setQuery] = useState('');
+     const [results, setResults] = useState<Result[]>([]);
+     const [isPending, startTransition] = useTransition();
+
+     function handleSearch(e: React.ChangeEvent<HTMLInputElement>) {
+       const value = e.target.value;
+       setQuery(value);  // urgent: update input immediately
+
+       startTransition(() => {
+         // non-urgent: can be interrupted by user input
+         const filtered = filterResults(allData, value);
+         setResults(filtered);
+       });
+     }
+
+     return (
+       <>
+         <input value={query} onChange={handleSearch} />
+         {isPending && <Spinner />}
+         <ResultsList results={results} />
+       </>
+     );
+   }
+
+   // useDeferredValue: defer expensive re-renders
+   function FilteredList({ filter }: { filter: string }) {
+     const deferredFilter = useDeferredValue(filter);
+     return (
+       <div style={{ opacity: filter !== deferredFilter ? 0.7 : 1 }}>
+         <ExpensiveList filter={deferredFilter} />
+       </div>
+     );
+   }
+   ```
+
+5. **Optimize list rendering.** Large lists are the most common CSR performance problem:
+
+   ```typescript
+   // Key stability: use stable IDs, not array index
+   // Bad: items.map((item, index) => <Item key={index} ... />)
+   // Good: items.map(item => <Item key={item.id} ... />)
+
+   // Avoid creating new objects/arrays in render
+   // Bad: <List items={data.filter(d => d.active)} />
+   // Good:
+   const activeItems = useMemo(
+     () => data.filter(d => d.active),
+     [data]
+   );
+   return <List items={activeItems} />;
+
+   // For very long lists (1000+), use virtualization
+   // See: perf-lazy-loading skill for virtual scrolling patterns
+   ```
+
+6. **Batch state updates for fewer renders.** React 18 automatically batches state updates in all contexts:
+
+   ```typescript
+   // React 18: all state updates are batched automatically
+   // This triggers ONE re-render, not three:
+   async function handleSubmit() {
+     const data = await fetchData();
+     setItems(data.items); // batched
+     setTotal(data.total); // batched
+     setLoading(false); // batched → single re-render
+   }
+
+   // When you need to force a synchronous update (rare):
+   import { flushSync } from 'react-dom';
+   flushSync(() => {
+     setMeasurement(value); // renders immediately
+   });
+   // DOM is updated here — safe to measure
+   const height = ref.current.offsetHeight;
+   ```
+
+7. **Profile with the Performance panel.** Beyond React DevTools, the Chrome Performance panel shows the full picture:
+
+   ```
+   1. Performance tab → Record → interact → Stop
+   2. Look for:
+      - Long Tasks (>50ms) in the Main thread
+      - Scripting vs Rendering vs Painting breakdown
+      - React commit phases (look for "React" in the call stack)
+   3. Common findings:
+      - Large component trees re-rendering: many short React frames
+      - Single expensive computation: one long scripting block
+      - Layout thrashing: alternating "Recalculate Style" and "Layout"
+   ```
+
+## Details
+
+### Virtual DOM Reconciliation Cost
+
+React's reconciliation algorithm diffs the previous and next virtual DOM trees to determine minimal DOM updates. The diffing itself is O(n) where n is the number of elements. For 1000 list items, the diff cost is ~1-5ms. The expensive part is DOM mutation: inserting, moving, or removing real DOM nodes costs ~0.1-0.5ms each. This is why stable keys are critical — they help React match elements across renders and minimize DOM mutations.
+
+### Worked Example: Figma File Browser
+
+Figma uses windowed rendering plus React.memo on file cards with Zustand selector-based subscriptions, so selecting a file does not re-render the grid. The search input uses useDeferredValue to keep typing responsive. Result: 60fps scrolling through 10,000+ files with <50ms INP.
+
+### Worked Example: Linear Issue Tracker
+
+Linear achieves instant-feeling interactions via: (1) optimistic updates before server confirmation, (2) fine-grained state subscriptions so status changes re-render only that row, (3) CSS transitions instead of React-driven animations, (4) skeleton screens matching loaded layout. Result: <50ms INP for status changes and zero layout shift.
+
+### Anti-Patterns
+
+**Premature memoization.** Only memoize components that receive complex props and render frequently, are expensive (>5ms), or sit below frequently-changing state. Profile first, memoize second.
+
+**State in the wrong component.** Lifting state too high causes entire subtrees to re-render. Keep state as close to where it is used as possible.
+
+**Creating objects in JSX props.** `<Child style={{ color: 'red' }} />` creates a new object every render, defeating React.memo. Extract constants or use useMemo.
+
+**Synchronous heavy computation during render.** Move heavy computation (sorting, filtering 10K+ items) to a Web Worker or use useDeferredValue.
+
+## Source
+
+- React: Performance — https://react.dev/learn/render-and-commit
+- React: useTransition — https://react.dev/reference/react/useTransition
+- React: Profiler — https://react.dev/reference/react/Profiler
+- web.dev: Rendering performance — https://web.dev/articles/rendering-performance
+
+## Process
+
+1. Read the instructions and examples in this document.
+2. Apply the patterns to your implementation, adapting to your specific context.
+3. Verify your implementation against the details and edge cases listed above.
+
+## Harness Integration
+
+- **Type:** knowledge — this skill is a reference document, not a procedural workflow.
+- **No tools or state** — consumed as context by other skills and agents.
+
+## Success Criteria
+
+- React DevTools Profiler shows no unnecessary re-renders on common interactions.
+- All loading states use skeleton screens that match loaded content dimensions.
+- useTransition or useDeferredValue is used for expensive filtering/sorting operations.
+- List rendering uses stable keys and memoized items where beneficial.
+- INP is under 200ms for all common user interactions.

package/dist/agents/skills/claude-code/perf-client-side-rendering/skill.yaml

@@ -0,0 +1,40 @@
+name: perf-client-side-rendering
+version: '1.0.0'
+description: Client-side rendering — SPA rendering optimization, skeleton screens, progressive rendering, and virtual DOM performance
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - perf-server-side-rendering
+  - perf-code-splitting
+  - perf-critical-rendering-path
+  - perf-interaction-to-next-paint
+  - perf-long-tasks
+  - perf-event-loop
+stack_signals: []
+keywords:
+  - client-side rendering
+  - CSR
+  - SPA
+  - skeleton screen
+  - progressive rendering
+  - virtual DOM
+  - React performance
+  - re-render
+  - memoization
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/claude-code/perf-code-splitting/SKILL.md

@@ -0,0 +1,185 @@
+# Code Splitting
+
+> Master code splitting strategies — route-based splitting, component-based splitting, vendor chunk optimization, and dynamic imports to reduce initial bundle size and improve Time to Interactive across single-page applications and server-rendered frameworks.
+
+## When to Use
+
+- Initial JavaScript bundle exceeds 200KB gzipped and blocks first render
+- Lighthouse flags "Reduce unused JavaScript" with significant savings potential
+- Users on mobile or slow networks experience long Time to Interactive
+- Routes load large libraries (charting, editors, maps) that most users never visit
+- Webpack Bundle Analyzer shows a single monolithic chunk with all application code
+- Build times are increasing because every change rebuilds the entire application
+- Third-party vendor libraries are bundled with application code and invalidate on every deploy
+- A dashboard application loads admin-only components for all users
+- You need to implement progressive loading for a feature-rich SPA
+- Coverage tab in DevTools shows >50% unused JavaScript on initial page load
+
+## Instructions
+
+1. **Measure the current bundle.** Before splitting, establish a baseline. Use the Coverage tab in Chrome DevTools (Ctrl+Shift+P, "Coverage") to identify unused bytes on page load. Run `npx webpack-bundle-analyzer` or `npx vite-bundle-visualizer` to see the composition of each chunk.
+
+2. **Implement route-based splitting.** This is the highest-impact, lowest-risk form of code splitting. Each route becomes its own chunk, loaded only when the user navigates there:
+
+   ```javascript
+   // React with React.lazy
+   import { lazy, Suspense } from 'react';
+
+   const Dashboard = lazy(() => import('./pages/Dashboard'));
+   const Settings = lazy(() => import('./pages/Settings'));
+   const Analytics = lazy(() => import('./pages/Analytics'));
+
+   function App() {
+     return (
+       <Suspense fallback={<PageSkeleton />}>
+         <Routes>
+           <Route path="/" element={<Dashboard />} />
+           <Route path="/settings" element={<Settings />} />
+           <Route path="/analytics" element={<Analytics />} />
+         </Routes>
+       </Suspense>
+     );
+   }
+   ```
+
+   ```javascript
+   // Next.js — automatic route-based splitting via file-system routing
+   // pages/dashboard.tsx → separate chunk automatically
+   // pages/settings.tsx → separate chunk automatically
+
+   // For dynamic routes with heavy components:
+   import dynamic from 'next/dynamic';
+   const HeavyChart = dynamic(() => import('../components/HeavyChart'), {
+     loading: () => <ChartSkeleton />,
+     ssr: false, // skip server rendering for client-only components
+   });
+   ```
+
+3. **Split component-level heavy dependencies.** When a component imports a large library, split it at the component boundary:
+
+   ```javascript
+   // Before: monaco-editor (5MB) loaded on every page
+   import MonacoEditor from '@monaco-editor/react';
+
+   // After: loaded only when CodeEditor mounts
+   const CodeEditor = lazy(() => import('./CodeEditor'));
+   // CodeEditor.tsx imports monaco-editor internally
+   ```
+
+4. **Configure vendor chunk splitting.** Separate rarely-changing vendor code from frequently-changing application code so deploys only invalidate app chunks:
+
+   ```javascript
+   // webpack.config.js
+   optimization: {
+     splitChunks: {
+       chunks: 'all',
+       cacheGroups: {
+         framework: {
+           test: /[\\/]node_modules[\\/](react|react-dom|scheduler)[\\/]/,
+           name: 'framework',
+           priority: 40,
+           enforce: true,
+         },
+         vendor: {
+           test: /[\\/]node_modules[\\/]/,
+           name: 'vendor',
+           priority: 20,
+           minSize: 20000,
+         },
+         common: {
+           minChunks: 2,
+           priority: 10,
+           reuseExistingChunk: true,
+         },
+       },
+     },
+   }
+   ```
+
+5. **Use named chunk comments for debugging.** Webpack magic comments give chunks readable names in the Network panel:
+
+   ```javascript
+   const AdminPanel = lazy(() => import(/* webpackChunkName: "admin" */ './pages/AdminPanel'));
+   const PDFViewer = lazy(
+     () => import(/* webpackChunkName: "pdf-viewer" */ './components/PDFViewer')
+   );
+   ```
+
+6. **Prefetch predictable navigation targets.** After initial load completes, prefetch chunks the user is likely to visit next:
+
+   ```javascript
+   // Webpack magic comment for prefetch
+   const Settings = lazy(() => import(/* webpackPrefetch: true */ './pages/Settings'));
+   // Emits <link rel="prefetch" href="settings.chunk.js"> in <head>
+
+   // Manual prefetch on hover/focus for fine control
+   function NavLink({ to, component, children }) {
+     const prefetch = () => component.preload?.();
+     return (
+       <Link to={to} onMouseEnter={prefetch} onFocus={prefetch}>
+         {children}
+       </Link>
+     );
+   }
+   ```
+
+7. **Set chunk size budgets.** Configure warnings and errors when chunks exceed size limits:
+
+   ```javascript
+   // webpack.config.js
+   performance: {
+     maxEntrypointSize: 250000,  // 250KB
+     maxAssetSize: 200000,       // 200KB
+     hints: 'error',             // fail the build if exceeded
+   }
+   ```
+
+## Details
+
+### How Bundlers Implement Code Splitting
+
+Webpack, Rollup, and esbuild all recognize dynamic `import()` expressions as split points. When the bundler encounters `import('./Module')`, it creates a separate chunk containing that module and its unique dependencies. Shared dependencies are either duplicated or extracted into a common chunk depending on configuration. At runtime, the framework's chunk loading mechanism (webpack's `__webpack_require__.e`, Vite's native ESM imports) fetches the chunk via a network request and resolves the promise.
+
+### Granularity Trade-offs
+
+Splitting too aggressively creates many small chunks, increasing HTTP request overhead (especially on HTTP/1.1) and reducing compression efficiency. Splitting too conservatively leaves large monolithic bundles. The optimal strategy depends on the application: content sites benefit from aggressive route splitting (users visit 1-2 pages), while dashboards with frequent navigation benefit from larger shared chunks that amortize loading across views.
+
+### Worked Example: Shopify Checkout
+
+Shopify's checkout splits into three tiers: a critical shell chunk (React + routing, ~40KB gzipped) that loads instantly, route chunks for each checkout step (shipping, payment, confirmation at ~15-25KB each), and deferred chunks for optional features (address autocomplete, payment method animations). This achieves a 1.2s TTI on 3G for the first step, with subsequent steps loading in <200ms from prefetched chunks. The vendor chunk (React, Polaris) changes only on framework upgrades, maintaining >95% cache hit rate across deploys.
+
+### Anti-Patterns
+
+**Splitting every component individually.** Wrapping every component in `lazy()` creates dozens of tiny chunks that generate waterfall requests. Split at meaningful boundaries — routes, heavy feature modules, conditional features — not individual UI components.
+
+**Dynamic imports inside hot loops or render functions.** Calling `import()` inside a component body without memoization triggers a new chunk load on every render. Always hoist lazy components to module scope or memoize them.
+
+**Ignoring the loading state.** A `Suspense` fallback of `null` or a tiny spinner causes layout shift when the chunk loads. Use skeleton screens that match the loaded component's dimensions.
+
+**Not accounting for chunk load failures.** Network failures during chunk loading crash the application. Wrap lazy components in an Error Boundary that offers a retry mechanism.
+
+## Source
+
+- webpack: Code Splitting — https://webpack.js.org/guides/code-splitting/
+- React: React.lazy — https://react.dev/reference/react/lazy
+- web.dev: Reduce JavaScript payloads with code splitting — https://web.dev/articles/reduce-javascript-payloads-with-code-splitting
+- Vite: Code Splitting — https://vitejs.dev/guide/features.html#async-chunk-loading-optimization
+
+## Process
+
+1. Read the instructions and examples in this document.
+2. Apply the patterns to your implementation, adapting to your specific context.
+3. Verify your implementation against the details and edge cases listed above.
+
+## Harness Integration
+
+- **Type:** knowledge — this skill is a reference document, not a procedural workflow.
+- **No tools or state** — consumed as context by other skills and agents.
+
+## Success Criteria
+
+- Route-based splitting is implemented with each route in its own chunk.
+- Initial bundle size is under 200KB gzipped for the entry point.
+- Vendor libraries are in separate chunks that persist across application deploys.
+- Coverage tab shows <30% unused JavaScript on initial page load.
+- Suspense fallbacks provide meaningful loading states (skeleton screens, not spinners).

package/dist/agents/skills/claude-code/perf-code-splitting/skill.yaml

@@ -0,0 +1,39 @@
+name: perf-code-splitting
+version: '1.0.0'
+description: Code splitting — Route-based, component-based, and vendor splitting with dynamic imports for reduced initial bundle size
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - perf-tree-shaking
+  - perf-lazy-loading
+  - perf-bundle-analysis
+  - perf-module-federation
+  - perf-critical-rendering-path
+  - perf-largest-contentful-paint
+stack_signals: []
+keywords:
+  - code splitting
+  - dynamic import
+  - route splitting
+  - vendor chunk
+  - webpack splitChunks
+  - React.lazy
+  - loadable components
+  - chunk optimization
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []