@harness-engineering/cli 1.23.2 → 1.24.0

package/dist/agents/skills/cursor/react-provider-pattern/SKILL.md

@@ -0,0 +1,72 @@
+# React Provider Pattern
+
+> Make data available to any component in the tree without prop drilling
+
+## When to Use
+
+- Multiple components at different nesting levels need the same data (theme, locale, current user, feature flags)
+- Prop drilling through 3+ levels creates maintenance burden
+- You want to decouple data consumers from data source location in the tree
+- Building a reusable component library that needs implicit configuration
+
+## Instructions
+
+1. Create a context with `createContext`, providing a typed default value.
+2. Create a Provider component that holds the state and wraps `Context.Provider`.
+3. Export a `useXxx()` hook that calls `useContext` and throws if used outside the Provider.
+4. Wrap the relevant subtree (or the entire app) with the Provider.
+5. Any component in the subtree can consume via the hook — no prop threading required.
+
+```typescript
+interface ThemeContextValue { theme: 'light' | 'dark'; toggle: () => void }
+
+const ThemeContext = createContext<ThemeContextValue | null>(null);
+
+export function ThemeProvider({ children }: { children: React.ReactNode }) {
+  const [theme, setTheme] = useState<'light' | 'dark'>('light');
+  return (
+    <ThemeContext.Provider value={{ theme, toggle: () => setTheme((t) => t === 'light' ? 'dark' : 'light') }}>
+      {children}
+    </ThemeContext.Provider>
+  );
+}
+
+export function useTheme(): ThemeContextValue {
+  const ctx = useContext(ThemeContext);
+  if (!ctx) throw new Error('useTheme must be used within ThemeProvider');
+  return ctx;
+}
+```
+
+## Details
+
+The Provider Pattern is React's built-in dependency injection mechanism. It solves prop drilling — the antipattern of threading props through intermediate components that do not use them.
+
+**Performance consideration:** Every component that calls `useContext` re-renders when the context value changes. For high-frequency updates, split contexts by concern (do not put both `user` and `notifications` in the same context) or use a state management library with selector support.
+
+**Context vs state management:**
+
+- Context is built-in and appropriate for low-frequency global data (theme, locale, auth)
+- For high-frequency or complex derived state, prefer Zustand, Jotai, or Redux Toolkit
+
+**Null safety pattern:** Passing `null` as default to `createContext` and throwing in the hook (`if (!ctx) throw new Error(...)`) gives better error messages than silent `undefined` access failures.
+
+## Source
+
+https://patterns.dev/react/provider-pattern
+
+## 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
+
+- The patterns described in this document are applied correctly in the implementation.
+- Edge cases and anti-patterns listed in this document are avoided.

package/dist/agents/skills/cursor/react-provider-pattern/skill.yaml

@@ -0,0 +1,37 @@
+name: react-provider-pattern
+version: '1.0.0'
+description: Make data available to any component in the tree without prop drilling
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths:
+  - '**/*.tsx'
+  - '**/*.jsx'
+related_skills:
+  - react-context-pattern
+  - react-hooks-pattern
+  - react-compound-pattern
+stack_signals:
+  - react
+  - typescript
+keywords:
+  - context
+  - provider
+  - prop-drilling
+  - global-state
+  - dependency-injection
+metadata:
+  author: patterns.dev
+  upstream: 'PatternsDev/skills/react/provider-pattern'
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/cursor/react-render-props-pattern/SKILL.md

@@ -0,0 +1,73 @@
+# React Render Props Pattern
+
+> Share stateful logic by passing a render function as a prop
+
+## When to Use
+
+- You need to share stateful behavior without coupling the rendering to the logic
+- The rendering of the shared state is highly variable between consumers
+- You are working with class components (pre-hooks) or third-party components that do not expose hooks
+- Building components for library distribution where render control must stay with consumers
+
+## Instructions
+
+1. Create a component that manages the shared state or behavior.
+2. Accept a `render` prop (or `children` as a function) that receives the state as arguments.
+3. Call the render prop inside the component's return, passing the managed state.
+4. Consumers control all rendering; the provider controls only the logic.
+
+```typescript
+interface MousePosition { x: number; y: number }
+
+function MouseTracker({ render }: { render: (pos: MousePosition) => React.ReactNode }) {
+  const [pos, setPos] = useState<MousePosition>({ x: 0, y: 0 });
+  return (
+    <div onMouseMove={(e) => setPos({ x: e.clientX, y: e.clientY })}>
+      {render(pos)}
+    </div>
+  );
+}
+
+// Usage
+<MouseTracker render={({ x, y }) => <p>Mouse at {x}, {y}</p>} />
+```
+
+## Details
+
+Render props were the dominant pattern for logic reuse before React hooks. With hooks available, most new render props use cases should be implemented as custom hooks instead. However, render props remain valuable in specific scenarios:
+
+- Third-party library integration where hooks are unavailable
+- Highly dynamic rendering decisions that benefit from explicit prop passing
+- Class component contexts
+
+**Children as function** is a common variant:
+
+```typescript
+<MouseTracker>{({ x, y }) => <p>At {x}, {y}</p>}</MouseTracker>
+```
+
+**Trade-offs vs hooks:**
+
+- Render props require wrapping in JSX; hooks are called inline — hooks are almost always simpler
+- Render props make the data flow explicit in JSX; hooks hide the data flow in function calls
+- Multiple render props create "wrapper hell" (the problem hooks solved)
+
+## Source
+
+https://patterns.dev/react/render-props-pattern
+
+## 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
+
+- The patterns described in this document are applied correctly in the implementation.
+- Edge cases and anti-patterns listed in this document are avoided.

package/dist/agents/skills/cursor/react-render-props-pattern/skill.yaml

@@ -0,0 +1,35 @@
+name: react-render-props-pattern
+version: '1.0.0'
+description: Share stateful logic by passing a render function as a prop
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths:
+  - '**/*.tsx'
+  - '**/*.jsx'
+related_skills:
+  - react-hooks-pattern
+  - react-hoc-pattern
+stack_signals:
+  - react
+  - typescript
+keywords:
+  - render-props
+  - children-as-function
+  - inversion-of-control
+  - logic-sharing
+metadata:
+  author: patterns.dev
+  upstream: 'PatternsDev/skills/react/render-props-pattern'
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/cursor/react-server-components/SKILL.md

@@ -0,0 +1,81 @@
+# React Server Components
+
+> Run components on the server to eliminate client JavaScript and enable direct data access
+
+## When to Use
+
+- Components that fetch data and render it without client-side interactivity
+- Components that import large libraries (markdown parsers, date formatters) only needed for rendering
+- You need direct database or filesystem access without an API layer
+- Using Next.js App Router (RSC is the default) or another RSC-compatible framework
+
+## Instructions
+
+1. **Server Components are the default** in Next.js App Router. Do not add `'use client'` unless needed.
+2. Server Components can:
+   - `async/await` directly: `const data = await db.query(...)`
+   - Import server-only libraries without impacting bundle size
+   - Read environment variables and secrets directly
+3. Add `'use client'` directive at the top of a file when the component needs:
+   - `useState`, `useEffect`, or any hooks
+   - Browser APIs (`window`, `document`)
+   - Event handlers (`onClick`, `onChange`)
+4. **Composition rule:** Server Components can render Client Components, but Client Components cannot render Server Components (only pass them as `children` props).
+5. Pass data from Server to Client Components as serializable props (no functions, classes, or non-serializable objects).
+
+```typescript
+// Server Component (no 'use client')
+async function ProductPage({ id }: { id: string }) {
+  const product = await db.products.findById(id); // direct DB access
+  return (
+    <div>
+      <h1>{product.name}</h1>
+      <AddToCartButton productId={id} /> {/* Client Component */}
+    </div>
+  );
+}
+
+// Client Component
+'use client';
+function AddToCartButton({ productId }: { productId: string }) {
+  return <button onClick={() => addToCart(productId)}>Add to Cart</button>;
+}
+```
+
+## Details
+
+RSC introduces a server/client component split at the file level. The framework serializes server-rendered output as a JSON-like payload (RSC payload) and sends it to the client for React to reconcile.
+
+**What RSC eliminates:**
+
+- API routes for data fetching in many cases (direct DB access in server components)
+- Client-side waterfall requests (async server components fetch in parallel)
+- Bundle cost for render-only dependencies (they never reach the browser)
+
+**Common mistakes:**
+
+- Adding `'use client'` to every file "to be safe" — this negates RSC benefits
+- Trying to pass functions as props from server to client components — functions are not serializable
+- Using `useEffect` for data fetching in client components when a server component would work
+
+**Framework support (2024):** Next.js App Router is the primary production implementation. Remix, Waku, and other frameworks have RSC support in various stages.
+
+## Source
+
+https://patterns.dev/react/react-server-components
+
+## 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
+
+- The patterns described in this document are applied correctly in the implementation.
+- Edge cases and anti-patterns listed in this document are avoided.

package/dist/agents/skills/cursor/react-server-components/skill.yaml

@@ -0,0 +1,39 @@
+name: react-server-components
+version: '1.0.0'
+description: Run components on the server to eliminate client JavaScript and enable direct data access
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths:
+  - '**/*.tsx'
+  - '**/*.jsx'
+related_skills:
+  - react-server-rendering
+  - react-client-rendering
+  - react-islands-pattern
+  - react-suspense-pattern
+stack_signals:
+  - react
+  - typescript
+  - next
+keywords:
+  - rsc
+  - server-components
+  - use-client
+  - zero-bundle
+  - data-access
+metadata:
+  author: patterns.dev
+  upstream: 'PatternsDev/skills/react/react-server-components'
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/cursor/react-server-rendering/SKILL.md

@@ -0,0 +1,63 @@
+# React Server Rendering
+
+> Pre-render React components on the server for improved SEO and initial load performance
+
+## When to Use
+
+- Public-facing pages where SEO and crawler indexability matter
+- Applications where First Contentful Paint performance is critical
+- You need personalized content rendered per-request (not suitable for static generation)
+- Using Next.js Pages Router (`getServerSideProps`), Remix (`loader`), or custom Express + `renderToString`
+
+## Instructions
+
+1. In Next.js Pages Router, export `getServerSideProps` to fetch data server-side:
+   ```typescript
+   export async function getServerSideProps(context: GetServerSidePropsContext) {
+     const data = await fetchData(context.params.id);
+     return { props: { data } };
+   }
+   ```
+2. In Remix, export a `loader` function:
+   ```typescript
+   export async function loader({ params }: LoaderFunctionArgs) {
+     return json(await fetchData(params.id));
+   }
+   ```
+3. The server renders the full HTML; the browser displays it immediately (no blank page flash).
+4. React hydrates the server-rendered HTML on the client, attaching event handlers.
+5. Use `cache` headers appropriately — per-request SSR bypasses CDN caching.
+
+## Details
+
+SSR sends fully-rendered HTML from the server. The browser displays content immediately while React hydrates in the background, making the UI interactive.
+
+**SSR vs SSG:**
+
+- **SSG (Static Generation):** HTML generated at build time. Fast, cacheable, but requires rebuild for updates.
+- **SSR:** HTML generated per-request. Always fresh, but has server cost and latency.
+- **ISR (Next.js):** Static with time-based revalidation — best of both for many cases.
+
+**Hydration mismatch:** If server-rendered HTML differs from what client React would render, React throws a hydration error. Common causes: `Date.now()`, `Math.random()`, browser-only APIs in render paths. Suppress with `suppressHydrationWarning` for known-safe mismatches.
+
+**React 18 streaming:** `renderToPipeableStream` streams HTML to the browser progressively, enabling Suspense boundaries to stream in chunks. Improves TTFB for slow data.
+
+## Source
+
+https://patterns.dev/react/server-side-rendering
+
+## 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
+
+- The patterns described in this document are applied correctly in the implementation.
+- Edge cases and anti-patterns listed in this document are avoided.

package/dist/agents/skills/cursor/react-server-rendering/skill.yaml

@@ -0,0 +1,39 @@
+name: react-server-rendering
+version: '1.0.0'
+description: Pre-render React components on the server for improved SEO and initial load performance
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths:
+  - '**/*.tsx'
+  - '**/*.jsx'
+related_skills:
+  - react-client-rendering
+  - react-server-components
+  - react-progressive-hydration
+stack_signals:
+  - react
+  - typescript
+  - next
+  - remix
+keywords:
+  - ssr
+  - server-rendering
+  - hydration
+  - seo
+  - initial-load
+metadata:
+  author: patterns.dev
+  upstream: 'PatternsDev/skills/react/server-side-rendering'
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/cursor/react-state-management-pattern/SKILL.md

@@ -0,0 +1,72 @@
+# React State Management Pattern
+
+> Choose the right state management approach for your React application scale
+
+## When to Use
+
+- You are deciding how to manage state in a new React application
+- Local component state is no longer sufficient (multiple components need the same data)
+- Context re-render performance is becoming a problem
+- You need derived state, selectors, or middleware (Redux DevTools, undo/redo)
+
+## Instructions
+
+**Decision tree:**
+
+1. **Local state first:** Start with `useState` / `useReducer`. Do not reach for global state until you have a specific problem.
+2. **Shared low-frequency state:** Use React Context + `useContext` for data that rarely changes (theme, auth, locale).
+3. **Shared high-frequency state (small apps):** Use Zustand for minimal boilerplate, selector-based subscriptions, and devtools support.
+4. **Complex domain state (large apps):** Use Redux Toolkit for predictable state machines, time-travel debugging, and team consistency.
+5. **Server state:** Use React Query or SWR — not client state management — for data that comes from an API.
+
+```typescript
+// Zustand: minimal setup
+import { create } from 'zustand';
+interface BearStore {
+  count: number;
+  increment: () => void;
+}
+const useBearStore = create<BearStore>((set) => ({
+  count: 0,
+  increment: () => set((s) => ({ count: s.count + 1 })),
+}));
+```
+
+## Details
+
+**State categories:**
+
+- **UI state:** Open/closed, selected tab, scroll position — local state or URL params
+- **Server state:** API data — React Query, SWR, RTK Query
+- **Global app state:** User session, theme, cart — Context or Zustand
+- **Complex domain state:** Multi-entity updates, undo/redo, optimistic updates — Redux Toolkit
+
+**Library comparison (2024):**
+| Library | Bundle | Boilerplate | DevTools | Selectors |
+|---------|--------|-------------|----------|-----------|
+| Context | 0KB | Low | No | No |
+| Zustand | ~1KB | Very low | Yes | Yes |
+| Jotai | ~3KB | Low | Yes | Atoms |
+| Redux Toolkit | ~12KB | Medium | Excellent | Yes |
+
+**React 19 note:** With the React compiler, many manual performance optimizations in Zustand/Redux become less necessary as React auto-memoizes.
+
+## Source
+
+https://patterns.dev/react/state-management
+
+## 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
+
+- The patterns described in this document are applied correctly in the implementation.
+- Edge cases and anti-patterns listed in this document are avoided.

package/dist/agents/skills/cursor/react-state-management-pattern/skill.yaml

@@ -0,0 +1,40 @@
+name: react-state-management-pattern
+version: '1.0.0'
+description: Choose the right state management approach for your React application scale
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths:
+  - '**/*.tsx'
+  - '**/*.jsx'
+related_skills:
+  - react-context-pattern
+  - react-provider-pattern
+  - react-hooks-pattern
+stack_signals:
+  - react
+  - typescript
+  - redux
+  - zustand
+keywords:
+  - state-management
+  - zustand
+  - redux
+  - jotai
+  - useState
+  - global-state
+metadata:
+  author: patterns.dev
+  upstream: 'PatternsDev/skills/react/state-management'
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/cursor/react-static-import/SKILL.md

@@ -0,0 +1,61 @@
+# React Static Import
+
+> Bundle all dependencies at build time for predictable loading performance
+
+## When to Use
+
+- The imported module is needed immediately on component mount
+- The module is small or used everywhere in the app (no benefit to splitting)
+- You want tree-shaking to eliminate unused exports (only works with static imports)
+- Importing types, constants, utilities, or always-needed components
+
+## Instructions
+
+1. Use ES module static `import` syntax at the top of the file.
+2. Import only what you need — named imports enable tree-shaking.
+3. Avoid barrel files (`index.ts` re-exporting everything) when tree-shaking matters.
+4. Group imports: external libraries first, then internal modules, then relative imports.
+
+```typescript
+// Good: named import, tree-shakeable
+import { formatDate } from 'date-fns';
+
+// Good: specific internal module
+import { Button } from '@/components/Button';
+
+// Avoid for large libraries when only one function is needed
+import _ from 'lodash'; // pulls entire lodash into bundle
+import { debounce } from 'lodash'; // only debounce
+```
+
+## Details
+
+Static imports are resolved at build time by the bundler (Webpack, Vite, esbuild). The bundler builds a dependency graph and includes all statically imported modules in the bundle.
+
+**Tree-shaking:** Dead code elimination — if you import a named export but never use it, the bundler can eliminate it (with `sideEffects: false` in package.json and named imports). Side-effecting imports (CSS, polyfills) should not be tree-shaken.
+
+**When to switch to dynamic import:**
+
+- The module is only needed after a user interaction
+- The module is large and not needed on the initial route
+- You want to reduce initial bundle size
+
+## Source
+
+https://patterns.dev/react/static-import
+
+## 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
+
+- The patterns described in this document are applied correctly in the implementation.
+- Edge cases and anti-patterns listed in this document are avoided.

package/dist/agents/skills/cursor/react-static-import/skill.yaml

@@ -0,0 +1,37 @@
+name: react-static-import
+version: '1.0.0'
+description: Bundle all dependencies at build time for predictable loading performance
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths:
+  - '**/*.tsx'
+  - '**/*.jsx'
+  - '**/*.ts'
+related_skills:
+  - react-dynamic-import
+stack_signals:
+  - react
+  - typescript
+  - webpack
+  - vite
+keywords:
+  - static-import
+  - bundling
+  - tree-shaking
+  - module-loading
+metadata:
+  author: patterns.dev
+  upstream: 'PatternsDev/skills/react/static-import'
+state:
+  persistent: false
+  files: []
+depends_on: []