@harness-engineering/cli 1.23.2 → 1.24.0

package/dist/agents/skills/codex/gof-abstract-factory/SKILL.md

@@ -0,0 +1,193 @@
+# GOF Abstract Factory
+
+> Create families of related objects through factory interfaces without coupling to concrete types.
+
+## When to Use
+
+- You need to create multiple related objects that must work together (a UI theme, a cloud provider SDK, a DB + cache pair)
+- You want to swap an entire product family at runtime without changing client code
+- You have multiple variants of a product suite that must remain internally consistent
+- A simple factory method is insufficient because you're producing more than one related type
+
+## Instructions
+
+**Define the abstract factory and product interfaces first:**
+
+```typescript
+// Abstract product interfaces
+interface Button {
+  render(): string;
+  onClick(handler: () => void): void;
+}
+
+interface TextField {
+  render(): string;
+  getValue(): string;
+}
+
+// Abstract factory interface
+interface UIFactory {
+  createButton(label: string): Button;
+  createTextField(placeholder: string): TextField;
+}
+```
+
+**Implement concrete families:**
+
+```typescript
+// --- Dark theme family ---
+class DarkButton implements Button {
+  constructor(private label: string) {}
+  render() {
+    return `<button class="dark">${this.label}</button>`;
+  }
+  onClick(handler: () => void) {
+    /* attach event */
+  }
+}
+
+class DarkTextField implements TextField {
+  private value = '';
+  constructor(private placeholder: string) {}
+  render() {
+    return `<input class="dark" placeholder="${this.placeholder}" />`;
+  }
+  getValue() {
+    return this.value;
+  }
+}
+
+class DarkThemeFactory implements UIFactory {
+  createButton(label: string): Button {
+    return new DarkButton(label);
+  }
+  createTextField(placeholder: string): TextField {
+    return new DarkTextField(placeholder);
+  }
+}
+
+// --- Light theme family ---
+class LightButton implements Button {
+  constructor(private label: string) {}
+  render() {
+    return `<button class="light">${this.label}</button>`;
+  }
+  onClick(handler: () => void) {
+    /* attach event */
+  }
+}
+
+class LightTextField implements TextField {
+  private value = '';
+  constructor(private placeholder: string) {}
+  render() {
+    return `<input class="light" placeholder="${this.placeholder}" />`;
+  }
+  getValue() {
+    return this.value;
+  }
+}
+
+class LightThemeFactory implements UIFactory {
+  createButton(label: string): Button {
+    return new LightButton(label);
+  }
+  createTextField(placeholder: string): TextField {
+    return new LightTextField(placeholder);
+  }
+}
+```
+
+**Client code depends only on the abstract factory:**
+
+```typescript
+class LoginForm {
+  private submitButton: Button;
+  private emailField: TextField;
+
+  constructor(factory: UIFactory) {
+    this.submitButton = factory.createButton('Log In');
+    this.emailField = factory.createTextField('Email address');
+  }
+
+  render(): string {
+    return `<form>${this.emailField.render()}${this.submitButton.render()}</form>`;
+  }
+}
+
+// Swap families by changing the factory
+const theme = process.env.THEME === 'dark' ? new DarkThemeFactory() : new LightThemeFactory();
+const form = new LoginForm(theme);
+console.log(form.render());
+```
+
+**Cloud provider example (more realistic for backend):**
+
+```typescript
+interface StorageProvider {
+  upload(key: string, data: Buffer): Promise<string>;
+  download(key: string): Promise<Buffer>;
+}
+
+interface QueueProvider {
+  publish(topic: string, message: object): Promise<void>;
+  subscribe(topic: string, handler: (msg: object) => void): void;
+}
+
+interface CloudFactory {
+  createStorage(bucket: string): StorageProvider;
+  createQueue(): QueueProvider;
+}
+
+class AWSFactory implements CloudFactory {
+  createStorage(bucket: string): StorageProvider {
+    return new S3Storage(bucket);
+  }
+  createQueue(): QueueProvider {
+    return new SQSQueue();
+  }
+}
+
+class GCPFactory implements CloudFactory {
+  createStorage(bucket: string): StorageProvider {
+    return new GCSStorage(bucket);
+  }
+  createQueue(): QueueProvider {
+    return new PubSubQueue();
+  }
+}
+```
+
+## Details
+
+**Abstract Factory vs. Factory Method:** Factory Method uses inheritance — one factory method per subclass. Abstract Factory uses composition — inject a factory object that produces a whole family. Abstract Factory is the better choice when you have multiple products that vary together.
+
+**Adding a new product to an existing family breaks the Open/Closed Principle** — every concrete factory must implement the new method. This is the main drawback. Mitigate by providing a default implementation in an abstract base factory.
+
+**Anti-patterns:**
+
+- Abstract Factory that creates unrelated objects — the products must be a coherent family
+- Overusing when only one product variant exists — use a simple factory function instead
+- Mixing factory selection logic into the factory itself — the factory should only create, not decide
+
+**Testing tip:** Inject a `MockFactory` that returns stub implementations for every product type. This decouples all component tests from real infrastructure.
+
+## Source
+
+refactoring.guru/design-patterns/abstract-factory
+
+## 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/codex/gof-abstract-factory/skill.yaml

@@ -0,0 +1,35 @@
+name: gof-abstract-factory
+version: "1.0.0"
+description: Create families of related objects through factory interfaces without coupling to concrete types
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths:
+  - "**/*.ts"
+  - "tsconfig.json"
+related_skills:
+  - gof-factory-method
+  - ts-class-patterns
+  - ts-generics-pattern
+stack_signals:
+  - typescript
+keywords:
+  - abstract-factory
+  - factory-family
+  - product-family
+  - swappable-implementations
+metadata:
+  author: community
+  upstream: refactoring.guru/design-patterns/abstract-factory
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/codex/gof-adapter-pattern/SKILL.md

@@ -0,0 +1,157 @@
+# GOF Adapter Pattern
+
+> Wrap incompatible interfaces to make them work together without modifying source code.
+
+## When to Use
+
+- You want to use an existing class but its interface doesn't match what you need
+- You're integrating a third-party library with a fixed interface into a system that expects a different one
+- You're wrapping a legacy component to work with new code
+- You need to keep the original class unchanged (read-only dependency, vendor code)
+
+## Instructions
+
+**Object adapter (composition — preferred in TypeScript):**
+
+```typescript
+// What your system expects
+interface Logger {
+  info(message: string, context?: object): void;
+  error(message: string, error?: Error): void;
+  warn(message: string, context?: object): void;
+}
+
+// What you have (third-party SDK, fixed interface)
+class PinoLogger {
+  log(level: 'info' | 'warn' | 'error', payload: { msg: string; [key: string]: unknown }): void {
+    console.log(JSON.stringify({ level, ...payload }));
+  }
+}
+
+// Adapter wraps PinoLogger to satisfy Logger interface
+class PinoLoggerAdapter implements Logger {
+  constructor(private readonly pino: PinoLogger) {}
+
+  info(message: string, context?: object): void {
+    this.pino.log('info', { msg: message, ...context });
+  }
+
+  error(message: string, error?: Error): void {
+    this.pino.log('error', {
+      msg: message,
+      err: error ? { message: error.message, stack: error.stack } : undefined,
+    });
+  }
+
+  warn(message: string, context?: object): void {
+    this.pino.log('warn', { msg: message, ...context });
+  }
+}
+
+// Usage — client depends only on Logger interface
+const logger: Logger = new PinoLoggerAdapter(new PinoLogger());
+logger.info('Server started', { port: 3000 });
+```
+
+**Adapting an async legacy API:**
+
+```typescript
+// Legacy callback-based interface
+interface LegacyStorage {
+  readFile(path: string, callback: (err: Error | null, data: Buffer) => void): void;
+  writeFile(path: string, data: Buffer, callback: (err: Error | null) => void): void;
+}
+
+// Modern promise-based interface expected by new code
+interface AsyncStorage {
+  read(path: string): Promise<Buffer>;
+  write(path: string, data: Buffer): Promise<void>;
+}
+
+class LegacyStorageAdapter implements AsyncStorage {
+  constructor(private readonly legacy: LegacyStorage) {}
+
+  read(path: string): Promise<Buffer> {
+    return new Promise((resolve, reject) => {
+      this.legacy.readFile(path, (err, data) => {
+        if (err) reject(err);
+        else resolve(data);
+      });
+    });
+  }
+
+  write(path: string, data: Buffer): Promise<void> {
+    return new Promise((resolve, reject) => {
+      this.legacy.writeFile(path, data, (err) => {
+        if (err) reject(err);
+        else resolve();
+      });
+    });
+  }
+}
+```
+
+**Two-way adapter (adapt in both directions):**
+
+```typescript
+// When you need to satisfy two incompatible interfaces simultaneously
+class BidirectionalAdapter implements InterfaceA, InterfaceB {
+  constructor(
+    private readonly a: ComponentA,
+    private readonly b: ComponentB
+  ) {}
+
+  // InterfaceA methods delegate to ComponentA
+  doSomethingA(): void {
+    this.a.operationA();
+  }
+
+  // InterfaceB methods delegate to ComponentB
+  doSomethingB(): void {
+    this.b.operationB();
+  }
+}
+```
+
+## Details
+
+**Adapter vs. Facade:** Both simplify usage, but serve different purposes. An Adapter makes one interface compatible with another — the client expects a specific interface. A Facade simplifies a complex subsystem — the client doesn't care about the interface, just wants it simpler. If you're translating interfaces, use Adapter. If you're hiding complexity, use Facade.
+
+**Adapter vs. Decorator:** Both wrap an object. An Adapter changes the interface. A Decorator adds behavior while keeping the same interface.
+
+**Anti-patterns:**
+
+- Leaky adapter — letting the adaptee's types bleed into the adapter's public API
+- Adapter that does too much business logic — adapters should translate, not transform
+- Multiple adapters stacked — signals you need a proper abstraction layer, not more wrapping
+
+**Testing with adapters:** Mock the target interface, not the adaptee. This is exactly the value of the pattern — tests use the interface, not the concrete third-party dependency.
+
+```typescript
+// In tests, use a mock Logger instead of PinoLoggerAdapter
+const mockLogger: Logger = {
+  info: jest.fn(),
+  error: jest.fn(),
+  warn: jest.fn(),
+};
+```
+
+## Source
+
+refactoring.guru/design-patterns/adapter
+
+## 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/codex/gof-adapter-pattern/skill.yaml

@@ -0,0 +1,36 @@
+name: gof-adapter-pattern
+version: "1.0.0"
+description: Wrap incompatible interfaces to make them work together without modifying source code
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths:
+  - "**/*.ts"
+  - "tsconfig.json"
+related_skills:
+  - ts-class-patterns
+  - gof-facade-pattern
+  - gof-decorator-pattern
+stack_signals:
+  - typescript
+keywords:
+  - adapter
+  - interface-compatibility
+  - legacy-wrapping
+  - object-adapter
+  - class-adapter
+metadata:
+  author: community
+  upstream: refactoring.guru/design-patterns/adapter
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/codex/gof-bridge-pattern/SKILL.md

@@ -0,0 +1,183 @@
+# GOF Bridge Pattern
+
+> Separate abstraction from implementation to allow them to vary independently.
+
+## When to Use
+
+- You have a class that needs to vary along two independent dimensions (e.g., shape + renderer, notification + channel)
+- You want to avoid a class explosion from combining multiple orthogonal hierarchies
+- You need to switch implementations at runtime without changing the abstraction
+- You're applying composition over inheritance to eliminate deep inheritance chains
+
+## Instructions
+
+**Classic shape + renderer bridge:**
+
+```typescript
+// Implementation interface — can vary independently
+interface Renderer {
+  renderCircle(radius: number): string;
+  renderRectangle(width: number, height: number): string;
+}
+
+// Concrete implementations
+class SVGRenderer implements Renderer {
+  renderCircle(radius: number): string {
+    return `<circle r="${radius}" />`;
+  }
+  renderRectangle(width: number, height: number): string {
+    return `<rect width="${width}" height="${height}" />`;
+  }
+}
+
+class CanvasRenderer implements Renderer {
+  renderCircle(radius: number): string {
+    return `ctx.arc(0, 0, ${radius}, 0, Math.PI * 2)`;
+  }
+  renderRectangle(width: number, height: number): string {
+    return `ctx.fillRect(0, 0, ${width}, ${height})`;
+  }
+}
+
+// Abstraction — holds a reference to the implementation
+abstract class Shape {
+  constructor(protected renderer: Renderer) {}
+  abstract draw(): string;
+  abstract resize(factor: number): void;
+}
+
+// Refined abstractions
+class Circle extends Shape {
+  constructor(
+    renderer: Renderer,
+    private radius: number
+  ) {
+    super(renderer);
+  }
+  draw(): string {
+    return this.renderer.renderCircle(this.radius);
+  }
+  resize(factor: number): void {
+    this.radius *= factor;
+  }
+}
+
+class Rectangle extends Shape {
+  constructor(
+    renderer: Renderer,
+    private width: number,
+    private height: number
+  ) {
+    super(renderer);
+  }
+  draw(): string {
+    return this.renderer.renderRectangle(this.width, this.height);
+  }
+  resize(factor: number): void {
+    this.width *= factor;
+    this.height *= factor;
+  }
+}
+
+// Four combinations without four classes
+const svgCircle = new Circle(new SVGRenderer(), 10);
+const canvasCircle = new Circle(new CanvasRenderer(), 10);
+const svgRect = new Rectangle(new SVGRenderer(), 20, 10);
+```
+
+**Notification + channel bridge (practical backend example):**
+
+```typescript
+// Implementation axis: delivery channel
+interface MessageChannel {
+  send(recipient: string, subject: string, body: string): Promise<void>;
+}
+
+class EmailChannel implements MessageChannel {
+  async send(recipient: string, subject: string, body: string): Promise<void> {
+    console.log(`Email → ${recipient}: [${subject}] ${body}`);
+  }
+}
+
+class SlackChannel implements MessageChannel {
+  async send(recipient: string, subject: string, body: string): Promise<void> {
+    console.log(`Slack → #${recipient}: ${body}`);
+  }
+}
+
+// Abstraction axis: notification type
+abstract class Notification {
+  constructor(protected channel: MessageChannel) {}
+  abstract notify(userId: string, data: Record<string, unknown>): Promise<void>;
+
+  // Swap channel at runtime
+  setChannel(channel: MessageChannel): void {
+    this.channel = channel;
+  }
+}
+
+class OrderShippedNotification extends Notification {
+  async notify(userId: string, data: Record<string, unknown>): Promise<void> {
+    await this.channel.send(
+      userId,
+      'Your order has shipped',
+      `Order #${data.orderId} is on its way. Tracking: ${data.tracking}`
+    );
+  }
+}
+
+class PaymentFailedNotification extends Notification {
+  async notify(userId: string, data: Record<string, unknown>): Promise<void> {
+    await this.channel.send(
+      userId,
+      'Payment failed',
+      `Your payment of $${data.amount} failed. Please update your payment method.`
+    );
+  }
+}
+```
+
+## Details
+
+**Why Bridge prevents class explosion:** Without Bridge, combining 3 shapes × 3 renderers requires 9 classes. With Bridge, 3 shape classes + 3 renderer classes = 6 classes total. The number of combinations grows multiplicatively without the pattern.
+
+**Bridge vs. Adapter:** Adapter works with existing classes to make them compatible. Bridge is designed upfront to allow variation. If you find yourself introducing Bridge after the fact, you might actually want Adapter.
+
+**Bridge vs. Strategy:** Bridge separates a class hierarchy along two dimensions. Strategy encapsulates a single algorithm. Bridge is architectural; Strategy is behavioral. A bridge can contain multiple strategy-like injections.
+
+**Anti-patterns:**
+
+- Using Bridge when there's only one implementation — adds needless complexity
+- Implementation that calls back into the abstraction — creates coupling in both directions
+- Abstraction that exposes implementation details — defeats the purpose of separation
+
+**Runtime switching:**
+
+```typescript
+let channel: MessageChannel = new EmailChannel();
+const notification = new OrderShippedNotification(channel);
+
+// Switch to Slack at runtime
+notification.setChannel(new SlackChannel());
+await notification.notify('ops-team', { orderId: '123', tracking: 'UPS1234' });
+```
+
+## Source
+
+refactoring.guru/design-patterns/bridge
+
+## 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/codex/gof-bridge-pattern/skill.yaml

@@ -0,0 +1,35 @@
+name: gof-bridge-pattern
+version: "1.0.0"
+description: Separate abstraction from implementation to allow them to vary independently
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths:
+  - "**/*.ts"
+  - "tsconfig.json"
+related_skills:
+  - ts-class-patterns
+  - gof-adapter-pattern
+stack_signals:
+  - typescript
+keywords:
+  - bridge
+  - abstraction
+  - implementation
+  - class-explosion
+  - composition-over-inheritance
+metadata:
+  author: community
+  upstream: refactoring.guru/design-patterns/bridge
+state:
+  persistent: false
+  files: []
+depends_on: []