@harness-engineering/cli 1.23.1 → 1.24.0

package/dist/agents/skills/cursor/js-decorator-pattern/SKILL.md

@@ -0,0 +1,73 @@
+# JS Decorator Pattern
+
+> Extend object behavior dynamically without modifying its source
+
+## When to Use
+
+- You need to add responsibilities to objects at runtime without subclassing
+- You want to compose behaviors (logging, caching, auth checks) around existing functions
+- Building higher-order functions that wrap existing logic with cross-cutting concerns
+
+## Instructions
+
+1. Write a decorator function that accepts a target function or object and returns an enhanced version.
+2. For class decorators (TC39 Stage 3): prefix the class or method declaration with `@decorator`.
+3. For functional decorators: wrap the original function — `const enhanced = decorate(original)`.
+4. The decorator should not modify the original — it returns a new function/object.
+
+```javascript
+// Functional decorator — adds logging
+function withLogging(fn) {
+  return function (...args) {
+    console.log(`Calling ${fn.name} with`, args);
+    const result = fn.apply(this, args);
+    console.log(`${fn.name} returned`, result);
+    return result;
+  };
+}
+
+function add(a, b) {
+  return a + b;
+}
+const loggedAdd = withLogging(add);
+loggedAdd(2, 3); // logs call and return
+```
+
+5. Stack decorators by composing them: `const fn = withAuth(withLogging(handler))`.
+6. Preserve the original function's `name` and `length` with `Object.defineProperty` if needed.
+
+## Details
+
+The Decorator pattern adds behavior to individual objects without affecting other objects of the same class. In JavaScript, this is most naturally expressed as higher-order functions — functions that take a function and return a new function with added behavior.
+
+**Trade-offs:**
+
+- Stacking many decorators makes stack traces deeper and harder to debug
+- Decorated functions lose the original's `.name` and `.length` unless explicitly preserved
+- Order of decoration matters — `withAuth(withLogging(fn))` logs before auth checks
+
+**When NOT to use:**
+
+- When the added behavior is always needed — just include it in the function directly
+- When a simple wrapper function is sufficient — do not over-engineer with a formal decorator abstraction
+- For complex object augmentation — consider mixins or composition instead
+
+## Source
+
+https://patterns.dev/javascript/decorator-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/js-decorator-pattern/skill.yaml

@@ -0,0 +1,35 @@
+name: js-decorator-pattern
+version: '1.0.0'
+description: Extend object behavior dynamically without modifying its source
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths:
+  - '**/*.js'
+  - '**/*.mjs'
+  - '**/*.cjs'
+related_skills:
+  - js-mixin-pattern
+  - js-proxy-pattern
+stack_signals:
+  - javascript
+keywords:
+  - decorator
+  - extend-behavior
+  - wrapping
+  - higher-order
+metadata:
+  author: patterns.dev
+  upstream: 'PatternsDev/skills/javascript/decorator-pattern'
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/cursor/js-dynamic-import/SKILL.md

@@ -0,0 +1,70 @@
+# JS Dynamic Import
+
+> Load ES modules on demand with import() to reduce initial bundle size and enable code splitting
+
+## When to Use
+
+- You want to load code only when it is needed (route-based splitting, feature flags, heavy libraries)
+- Reducing the initial JavaScript bundle size for faster page loads
+- Loading polyfills or locale data conditionally based on the runtime environment
+
+## Instructions
+
+1. Use `import('./module.js')` to load a module at runtime — it returns a Promise.
+2. Use dynamic import for routes, heavy libraries, or features behind flags.
+3. Combine with `await` in async functions or `.then()` for cleaner syntax.
+4. Bundlers (webpack, Vite, Rollup) automatically split dynamic imports into separate chunks.
+
+```javascript
+// Route-based code splitting
+async function loadPage(route) {
+  const module = await import(`./pages/${route}.js`);
+  module.render();
+}
+
+// Feature-flag gating
+if (user.hasFeature('charts')) {
+  const { renderChart } = await import('./charts.js');
+  renderChart(data);
+}
+```
+
+5. Add error handling — `import()` can fail (network error, missing module).
+6. Use `/* webpackChunkName: "name" */` comments for readable chunk names in webpack.
+
+## Details
+
+Dynamic `import()` is a function-like syntax (not a function — it is a language feature) that returns a Promise resolving to the module's namespace object. Unlike static `import`, it can be used anywhere: inside functions, conditionals, loops, and event handlers.
+
+**Trade-offs:**
+
+- Asynchronous — you must handle the loading state (spinner, skeleton, Suspense)
+- Each dynamic import creates a separate network request (chunk) — too many small chunks can hurt performance
+- Harder to analyze statically — bundlers may not tree-shake dynamically imported modules as effectively
+- Module is not available synchronously — cannot be used where a synchronous value is required
+
+**When NOT to use:**
+
+- For modules used on every page load — static import is simpler and avoids the loading delay
+- When the module is small — the overhead of a separate chunk outweighs the savings
+- In performance-critical synchronous paths — the async nature adds latency
+
+## Source
+
+https://patterns.dev/javascript/dynamic-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/js-dynamic-import/skill.yaml

@@ -0,0 +1,36 @@
+name: js-dynamic-import
+version: '1.0.0'
+description: Load ES modules on demand with import() to reduce initial bundle size and enable code splitting
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths:
+  - '**/*.js'
+  - '**/*.mjs'
+  - '**/*.cjs'
+related_skills:
+  - js-static-import
+  - js-module-pattern
+stack_signals:
+  - javascript
+keywords:
+  - dynamic-import
+  - code-splitting
+  - lazy-loading
+  - import-on-demand
+  - bundle-size
+metadata:
+  author: patterns.dev
+  upstream: 'PatternsDev/skills/javascript/dynamic-import'
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/cursor/js-facade-pattern/SKILL.md

@@ -0,0 +1,73 @@
+# JS Facade Pattern
+
+> Provide a simplified interface to a complex subsystem
+
+## When to Use
+
+- A subsystem has many classes or functions that clients frequently use together
+- You want to hide complexity behind a single, easy-to-use API
+- Reducing the number of imports and calls a consumer needs to make
+
+## Instructions
+
+1. Identify a group of related subsystem calls that clients frequently combine.
+2. Create a facade module that exposes high-level functions composing those subsystem calls.
+3. The facade delegates to subsystem objects — it does not replace them.
+4. Keep the subsystem accessible for advanced callers who need fine-grained control.
+
+```javascript
+// Facade for a complex video conversion subsystem
+class VideoConverter {
+  convert(filename, format) {
+    const file = new VideoFile(filename);
+    const codec = CodecFactory.extract(file);
+    const compressor = new BitrateCompressor();
+    const mixer = new AudioMixer();
+
+    const result = codec.transcode(file, format);
+    compressor.compress(result);
+    mixer.normalize(result);
+    return result;
+  }
+}
+
+// Client uses one call instead of four subsystem interactions
+const converter = new VideoConverter();
+converter.convert('video.ogg', 'mp4');
+```
+
+## Details
+
+The Facade pattern is a structural pattern that provides a unified interface to a set of interfaces in a subsystem. In JavaScript, this is often a module that re-exports a curated subset of a library's API or orchestrates multiple service calls behind a single function.
+
+**Trade-offs:**
+
+- The facade can become a "god module" if it grows too large — keep it focused
+- Hiding subsystem details may prevent advanced users from accessing features they need
+- Changes to the underlying subsystem may require facade updates
+
+**When NOT to use:**
+
+- When the subsystem is already simple — adding a facade just adds indirection
+- When callers need full control over individual subsystem components
+- When the facade would just proxy every subsystem method — that is a wrapper, not a simplification
+
+## Source
+
+https://patterns.dev/javascript/facade-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/js-facade-pattern/skill.yaml

@@ -0,0 +1,35 @@
+name: js-facade-pattern
+version: '1.0.0'
+description: Provide a simplified interface to a complex subsystem
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths:
+  - '**/*.js'
+  - '**/*.mjs'
+  - '**/*.cjs'
+related_skills:
+  - js-adapter-pattern
+  - js-mediator-middleware-pattern
+stack_signals:
+  - javascript
+keywords:
+  - facade
+  - simplify
+  - abstraction
+  - subsystem-interface
+metadata:
+  author: patterns.dev
+  upstream: 'PatternsDev/skills/javascript/facade-pattern'
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/cursor/js-factory-pattern/SKILL.md

@@ -0,0 +1,74 @@
+# JS Factory Pattern
+
+> Create objects via a factory function without exposing instantiation logic to callers
+
+## When to Use
+
+- Object creation logic is complex and should be encapsulated
+- The exact type of object to create is determined at runtime
+- You want to return different implementations based on input without exposing `new` to callers
+
+## Instructions
+
+1. Write a factory function (or static class method) that accepts configuration and returns the correct object.
+2. The caller never uses `new` directly — they call the factory.
+3. Validate inputs inside the factory before creating the object.
+4. Return a consistent interface regardless of which concrete type was created.
+
+```javascript
+function createUser(type, name) {
+  const roles = {
+    admin: { permissions: ['read', 'write', 'delete'] },
+    editor: { permissions: ['read', 'write'] },
+    viewer: { permissions: ['read'] },
+  };
+
+  if (!roles[type]) throw new Error(`Unknown user type: ${type}`);
+
+  return {
+    name,
+    type,
+    ...roles[type],
+    greet() {
+      return `Hi, I'm ${name} (${type})`;
+    },
+  };
+}
+
+const admin = createUser('admin', 'Alice');
+console.log(admin.permissions); // ['read', 'write', 'delete']
+```
+
+## Details
+
+The Factory pattern is one of the most common patterns in JavaScript. Unlike `new ClassName()`, a factory function can return different types, apply caching, run validation, or perform async initialization.
+
+**Trade-offs:**
+
+- Callers cannot use `instanceof` to check the type (unless the factory returns a class instance)
+- Can become a large switch/if-else block if not maintained
+
+**When NOT to use:**
+
+- When all instances are always the same type — just use `new` directly
+- For very simple objects with no creation logic — plain object literals are sufficient
+
+## Source
+
+https://patterns.dev/javascript/factory-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/js-factory-pattern/skill.yaml

@@ -0,0 +1,35 @@
+name: js-factory-pattern
+version: '1.0.0'
+description: Create objects via a factory function without specifying the exact class
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths:
+  - '**/*.js'
+  - '**/*.mjs'
+  - '**/*.cjs'
+related_skills:
+  - js-abstract-factory-pattern
+  - js-constructor-pattern
+stack_signals:
+  - javascript
+keywords:
+  - factory
+  - creational
+  - object-creation
+  - encapsulate-instantiation
+metadata:
+  author: patterns.dev
+  upstream: 'PatternsDev/skills/javascript/factory-pattern'
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/cursor/js-flyweight-pattern/SKILL.md

@@ -0,0 +1,79 @@
+# JS Flyweight Pattern
+
+> Share common state across many fine-grained objects to reduce memory usage
+
+## When to Use
+
+- You have a very large number of similar objects (thousands+) and memory usage is a concern
+- Objects share most of their state (intrinsic) and only differ in a small extrinsic portion
+- Creating new objects per item is prohibitively expensive
+
+## Instructions
+
+1. Separate **intrinsic state** (shared, immutable) from **extrinsic state** (unique per instance).
+2. Store intrinsic state in a factory/cache indexed by a key.
+3. Pass extrinsic state as parameters to methods rather than storing it on the flyweight.
+4. Use a `FlyweightFactory` with a `Map` to return cached instances.
+
+```javascript
+class BookFlyweight {
+  constructor(title, author) {
+    this.title = title; // intrinsic — shared
+    this.author = author; // intrinsic — shared
+  }
+}
+
+class BookFactory {
+  constructor() {
+    this._books = new Map();
+  }
+
+  getBook(title, author) {
+    const key = `${title}-${author}`;
+    if (!this._books.has(key)) {
+      this._books.set(key, new BookFlyweight(title, author));
+    }
+    return this._books.get(key);
+  }
+}
+
+const factory = new BookFactory();
+const b1 = factory.getBook('JS Patterns', 'Stoyan');
+const b2 = factory.getBook('JS Patterns', 'Stoyan');
+console.log(b1 === b2); // true — same instance
+```
+
+## Details
+
+The Flyweight pattern is a structural memory optimization. It trades CPU time (factory lookup) for memory savings by sharing object instances. JavaScript's garbage collector normally handles short-lived objects efficiently, so Flyweight is only necessary at extreme scale.
+
+**Trade-offs:**
+
+- Increases code complexity — factory and separation of state
+- Thread-safety concerns in worker-based environments if the cache is mutated
+- Only beneficial when the number of objects is very large (thousands to millions)
+
+**When NOT to use:**
+
+- For typical web UI objects — the browser's memory management handles them fine
+- When objects differ significantly from each other — flyweight savings are minimal
+
+## Source
+
+https://patterns.dev/javascript/flyweight-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/js-flyweight-pattern/skill.yaml

@@ -0,0 +1,36 @@
+name: js-flyweight-pattern
+version: '1.0.0'
+description: Share common state across many fine-grained objects to reduce memory usage
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths:
+  - '**/*.js'
+  - '**/*.mjs'
+  - '**/*.cjs'
+related_skills:
+  - js-factory-pattern
+  - js-singleton-pattern
+stack_signals:
+  - javascript
+keywords:
+  - flyweight
+  - memory-optimization
+  - shared-state
+  - intrinsic
+  - extrinsic
+metadata:
+  author: patterns.dev
+  upstream: 'PatternsDev/skills/javascript/flyweight-pattern'
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/cursor/js-iterator-pattern/SKILL.md

@@ -0,0 +1,78 @@
+# JS Iterator Pattern
+
+> Traverse a collection sequentially without exposing its internal structure
+
+## When to Use
+
+- You need to iterate over a custom data structure (tree, graph, linked list) with `for...of`
+- You want to provide lazy, on-demand values without generating the entire collection upfront
+- Building data pipelines that compose iterables (filter, map, take)
+
+## Instructions
+
+1. Implement the iterator protocol: an object with a `next()` method returning `{ value, done }`.
+2. Make a collection iterable by adding `[Symbol.iterator]()` that returns an iterator.
+3. Use generator functions (`function*`) for the cleanest iterator implementation.
+4. Use `for...of` to consume iterables.
+
+```javascript
+class Range {
+  constructor(start, end) {
+    this.start = start;
+    this.end = end;
+  }
+
+  [Symbol.iterator]() {
+    let current = this.start;
+    const end = this.end;
+    return {
+      next() {
+        return current <= end
+          ? { value: current++, done: false }
+          : { value: undefined, done: true };
+      },
+    };
+  }
+}
+
+for (const n of new Range(1, 3)) {
+  console.log(n); // 1, 2, 3
+}
+```
+
+5. Generator shorthand: `*[Symbol.iterator]() { for (let i = this.start; i <= this.end; i++) yield i; }`.
+
+## Details
+
+JavaScript has a built-in iteration protocol. Any object with a `[Symbol.iterator]()` method is iterable and works with `for...of`, spread (`...`), destructuring, `Array.from()`, and `Promise.all()`. Generators (`function*`) are the simplest way to create custom iterators.
+
+**Trade-offs:**
+
+- Custom iterators add complexity — only worthwhile for non-trivial data structures
+- Infinite iterators (no `done: true`) will hang `for...of` loops unless guarded
+- Generator objects are single-use — once exhausted, they cannot be reset
+
+**When NOT to use:**
+
+- For arrays and built-in collections — they are already iterable
+- When you need random access — iterators are sequential by design
+
+## Source
+
+https://patterns.dev/javascript/iterator-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/js-iterator-pattern/skill.yaml

@@ -0,0 +1,36 @@
+name: js-iterator-pattern
+version: '1.0.0'
+description: Traverse a collection sequentially without exposing its internal structure
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths:
+  - '**/*.js'
+  - '**/*.mjs'
+  - '**/*.cjs'
+related_skills:
+  - js-command-pattern
+  - js-composite-pattern
+stack_signals:
+  - javascript
+keywords:
+  - iterator
+  - iterable
+  - symbol-iterator
+  - for-of
+  - generator
+metadata:
+  author: patterns.dev
+  upstream: 'PatternsDev/skills/javascript/iterator-pattern'
+state:
+  persistent: false
+  files: []
+depends_on: []