@harness-engineering/cli 1.23.2 → 1.24.0

package/dist/agents/skills/cursor/angular-testing-patterns/SKILL.md

@@ -0,0 +1,180 @@
+# Angular Testing Patterns
+
+> Test Angular components, services, directives, and pipes with TestBed, ComponentFixture, fakeAsync, and service mocks
+
+## When to Use
+
+- Writing unit tests for Angular components with shallow or deep rendering
+- Mocking service dependencies in component and service tests
+- Testing asynchronous code (HTTP, timers, observables) with `fakeAsync` + `tick`
+- Using `spectator` to reduce `TestBed` boilerplate for component tests
+- Testing standalone components without NgModule ceremony
+
+## Instructions
+
+1. Use `TestBed.configureTestingModule({ imports: [MyStandaloneComponent] })` for standalone components — import, not declare.
+2. Mock services with `{ provide: MyService, useValue: mockService }` in the `providers` array. Define mocks as `jasmine.createSpyObj` (Jasmine) or `jest.fn()` (Jest) objects.
+3. Always call `fixture.detectChanges()` after setup and after state mutations to trigger change detection before asserting on the DOM.
+4. Use `fakeAsync` + `tick()` for timer-based code. Use `fakeAsync` + `flush()` for promise-based code. Use `fakeAsync` + `flushMicrotasks()` for microtasks.
+5. Query DOM elements with `fixture.debugElement.query(By.css('selector'))` or `fixture.nativeElement.querySelector()`. Prefer `By.css` — it returns a `DebugElement` with Angular context.
+6. Test outputs by subscribing to the `EventEmitter` or signal output directly: `component.myOutput.subscribe(spy)`.
+7. For HTTP services, use `HttpClientTestingModule` and `HttpTestingController` to verify requests and flush mock responses.
+8. Use the `spectator` library (`@ngneat/spectator`) to reduce boilerplate — it wraps `TestBed` and adds ergonomic query helpers.
+
+```typescript
+// product-card.component.spec.ts
+import { ComponentFixture, TestBed } from '@angular/core/testing';
+import { By } from '@angular/platform-browser';
+import { signal } from '@angular/core';
+import { ProductCardComponent } from './product-card.component';
+import { CartService } from '../cart.service';
+
+describe('ProductCardComponent', () => {
+  let component: ProductCardComponent;
+  let fixture: ComponentFixture<ProductCardComponent>;
+  let mockCartService: jasmine.SpyObj<CartService>;
+
+  beforeEach(async () => {
+    mockCartService = jasmine.createSpyObj('CartService', ['addItem']);
+
+    await TestBed.configureTestingModule({
+      imports: [ProductCardComponent], // standalone component
+      providers: [{ provide: CartService, useValue: mockCartService }],
+    }).compileComponents();
+
+    fixture = TestBed.createComponent(ProductCardComponent);
+    component = fixture.componentInstance;
+
+    // Set required signal input
+    fixture.componentRef.setInput('product', {
+      id: '1',
+      name: 'Widget',
+      price: 9.99,
+    });
+
+    fixture.detectChanges();
+  });
+
+  it('should display the product name', () => {
+    const heading = fixture.debugElement.query(By.css('h2'));
+    expect(heading.nativeElement.textContent).toBe('Widget');
+  });
+
+  it('should emit addToCart when button clicked', () => {
+    const addSpy = jasmine.createSpy();
+    component.addToCart.subscribe(addSpy);
+
+    fixture.debugElement.query(By.css('button')).nativeElement.click();
+    expect(addSpy).toHaveBeenCalledWith({ id: '1', name: 'Widget', price: 9.99 });
+  });
+});
+```
+
+```typescript
+// product.service.spec.ts — HTTP service test
+import { TestBed } from '@angular/core/testing';
+import { HttpClientTestingModule, HttpTestingController } from '@angular/common/http/testing';
+import { ProductService } from './product.service';
+
+describe('ProductService', () => {
+  let service: ProductService;
+  let httpMock: HttpTestingController;
+
+  beforeEach(() => {
+    TestBed.configureTestingModule({
+      imports: [HttpClientTestingModule],
+      providers: [ProductService],
+    });
+    service = TestBed.inject(ProductService);
+    httpMock = TestBed.inject(HttpTestingController);
+  });
+
+  afterEach(() => httpMock.verify()); // assert no pending requests
+
+  it('should fetch products', () => {
+    const mockProducts = [{ id: '1', name: 'Widget', price: 9.99 }];
+    let result: Product[] | undefined;
+
+    service.getProducts().subscribe((p) => (result = p));
+
+    const req = httpMock.expectOne('/api/products');
+    expect(req.request.method).toBe('GET');
+    req.flush(mockProducts);
+
+    expect(result).toEqual(mockProducts);
+  });
+});
+```
+
+```typescript
+// async test with fakeAsync
+import { fakeAsync, tick } from '@angular/core/testing';
+
+it('should debounce search input', fakeAsync(() => {
+  component.searchControl.setValue('widget');
+  tick(300); // advance timer by 300ms (debounce time)
+  fixture.detectChanges();
+
+  expect(mockSearchService.search).toHaveBeenCalledWith('widget');
+}));
+```
+
+```typescript
+// spectator usage — reduces boilerplate significantly
+import { createComponentFactory, Spectator } from '@ngneat/spectator';
+
+describe('ProductCardComponent', () => {
+  let spectator: Spectator<ProductCardComponent>;
+  const createComponent = createComponentFactory({
+    component: ProductCardComponent,
+    mocks: [CartService],
+  });
+
+  beforeEach(() => {
+    spectator = createComponent({ props: { product: mockProduct } });
+  });
+
+  it('shows product name', () => {
+    expect(spectator.query('h2')).toHaveText('Widget');
+  });
+
+  it('calls addItem on click', () => {
+    spectator.click('button');
+    expect(spectator.inject(CartService).addItem).toHaveBeenCalled();
+  });
+});
+```
+
+## Details
+
+**Setting signal inputs in tests:** Signal inputs (`input()`) cannot be set directly via `component.myInput = value` because they are read-only signals. Use `fixture.componentRef.setInput('inputName', value)` instead — this is the supported API for setting signal inputs in tests.
+
+**`compileComponents()` requirement:** In tests that use `templateUrl` or `styleUrls`, call `await TestBed.configureTestingModule({...}).compileComponents()` to compile the external resources asynchronously. For inline templates, it is not strictly required but harmless.
+
+**Testing `OnPush` components:** `OnPush` components only update when inputs change, an async pipe resolves, or signals emit. In tests, `fixture.detectChanges()` triggers a change detection cycle. If you mutate state without changing a signal or input reference, the template won't update. Set signal values with `.set()` and call `fixture.detectChanges()` afterward.
+
+**Test isolation:** Each `TestBed.configureTestingModule` call in `beforeEach` creates a fresh Angular testing environment. Avoid sharing mutable state across tests — reset spies in `afterEach` if reused.
+
+**Avoiding real HTTP calls:** Always provide `HttpClientTestingModule` or mock the service. `HttpTestingController.verify()` in `afterEach` ensures no unexpected HTTP requests were made.
+
+**Signal stores in tests:** Provide a test version of the store or override state with `patchState` if the store is provided in the component.
+
+## Source
+
+https://angular.dev/guide/testing
+
+## 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/angular-testing-patterns/skill.yaml

@@ -0,0 +1,45 @@
+name: angular-testing-patterns
+version: '1.0.0'
+description: Test Angular components, services, and pipes with TestBed, ComponentFixture, and service mocks
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths:
+  - angular.json
+  - '**/*.component.ts'
+  - '**/*.component.html'
+  - '**/*.service.ts'
+  - '**/*.module.ts'
+related_skills:
+  - angular-component-pattern
+  - angular-service-di
+  - angular-signals-pattern
+  - test-unit-patterns
+stack_signals:
+  - angular
+  - typescript
+  - rxjs
+keywords:
+  - TestBed
+  - ComponentFixture
+  - jasmine
+  - jest
+  - service-mock
+  - spectator
+  - fakeAsync
+  - tick
+metadata:
+  author: angular.dev
+  upstream: 'angular.dev/guide/testing'
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/cursor/astro-component-pattern/SKILL.md

@@ -0,0 +1,160 @@
+# Astro Component Pattern
+
+> The `.astro` file format — server-only frontmatter, HTML-like templates, and scoped CSS — is the foundation of every Astro project.
+
+## When to Use
+
+- You are creating a new UI component that does not require client-side interactivity
+- You need to fetch data at request/build time and render it as static HTML
+- You want CSS that is automatically scoped to the component without a CSS module setup
+- You are building layouts, pages, or reusable UI fragments in an Astro project
+- You need to understand the anatomy of `.astro` files before working with islands, routing, or content collections
+
+## Instructions
+
+1. Structure every `.astro` file with three sections in order: frontmatter script, template, and optional `<style>`:
+
+```astro
+---
+// 1. Frontmatter (runs server-side only — never sent to the browser)
+import OtherComponent from './OtherComponent.astro';
+import type { Props } from './types';
+
+interface Props {
+  title: string;
+  description?: string;
+  variant?: 'primary' | 'secondary';
+}
+
+const { title, description = 'No description', variant = 'primary' } = Astro.props;
+const formattedDate = new Date().toLocaleDateString('en-US');
+---
+
+<!-- 2. Template (JSX-like but compiles to plain HTML) -->
+<article class={`card card--${variant}`}>
+  <h2>{title}</h2>
+  <p>{description}</p>
+  <OtherComponent date={formattedDate} />
+</article>
+
+<!-- 3. Scoped styles (automatically namespaced — no class collisions) -->
+<style>
+  .card {
+    border: 1px solid var(--color-border);
+    padding: 1rem;
+  }
+  .card--primary { background: var(--color-surface); }
+  .card--secondary { background: var(--color-muted); }
+</style>
+```
+
+2. Declare `Props` as a TypeScript interface inside the frontmatter. Astro reads this interface to provide type-safe props at the call site.
+
+3. Destructure props from `Astro.props`. The `Astro` global is available in every `.astro` file — it also provides `Astro.url`, `Astro.site`, `Astro.request`, `Astro.cookies`, `Astro.redirect()`, and `Astro.locals`.
+
+4. Use `<slot />` to render child content passed between component tags. Named slots handle multiple content areas:
+
+```astro
+<!-- Layout.astro -->
+<header><slot name="header" /></header>
+<main><slot /></main>  <!-- default slot -->
+<footer><slot name="footer" /></footer>
+```
+
+```astro
+<!-- Usage -->
+<Layout>
+  <h1 slot="header">Page Title</h1>
+  <p>Main content goes in the default slot.</p>
+  <p slot="footer">Footer text</p>
+</Layout>
+```
+
+5. Apply `is:global` to override scoped styles when you must style child component internals or third-party HTML:
+
+```astro
+<style is:global>
+  /* Applies globally — use sparingly */
+  .prose h2 { margin-top: 2rem; }
+</style>
+```
+
+6. Use `define:vars` to pass frontmatter variables into scoped CSS as custom properties:
+
+```astro
+---
+const accentColor = '#ff6b35';
+---
+<div class="hero">Hero section</div>
+<style define:vars={{ accentColor }}>
+  .hero { background: var(--accentColor); }
+</style>
+```
+
+7. Use template expressions for conditional rendering and iteration:
+
+```astro
+<!-- Conditional -->
+{isLoggedIn && <UserMenu />}
+{isLoggedIn ? <UserMenu /> : <LoginButton />}
+
+<!-- Iteration -->
+{items.map((item) => (
+  <li key={item.id}>{item.name}</li>
+))}
+
+<!-- Fragments (no wrapper element) -->
+<>
+  <dt>{term}</dt>
+  <dd>{definition}</dd>
+</>
+```
+
+8. Never write `import` statements inside the template section. All imports and logic belong in the frontmatter fence.
+
+## Details
+
+The `.astro` format is superficially similar to JSX but has a fundamental difference: the frontmatter runs exclusively on the server (or at build time). It never reaches the browser. This means you can safely use Node.js APIs, read files, query databases, and import server-only packages in the frontmatter fence.
+
+**Scoped styles explained:**
+
+Astro transforms scoped `<style>` blocks by adding a unique data attribute (e.g., `data-astro-cid-xyz`) to every element the component renders and scoping the CSS to that attribute. This prevents style leakage without requiring CSS Modules or a naming convention. The compiled CSS is extracted and bundled separately — it does not live inline in the HTML.
+
+**Template differences from JSX:**
+
+- Use `class` not `className` (Astro is HTML, not React)
+- `set:html` instead of `dangerouslySetInnerHTML`: `<p set:html={rawHtml} />`
+- `is:raw` on code blocks to prevent Astro from processing curly braces inside
+- Expressions are wrapped in `{}` and must be single expressions — no multi-statement blocks in the template
+
+**Performance characteristics:**
+
+`.astro` components have zero runtime overhead. They compile to static HTML strings at build time (SSG) or at request time (SSR). No virtual DOM, no reconciliation, no hydration cost. A page made entirely of `.astro` components ships exactly 0 bytes of JavaScript.
+
+**When to reach for a framework component instead:**
+
+Use `.astro` for everything that does not need `onClick`, `useState`, or any browser-only API. When interactivity is required, create a React/Vue/Svelte component and import it into the `.astro` file with a `client:*` directive. The `.astro` wrapper remains server-rendered; only the framework component hydrates.
+
+**Layouts:**
+
+Layouts are `.astro` components that use `<slot />` to wrap page content. They live in `src/layouts/` by convention. A layout component wraps page-level structure (`<html>`, `<head>`, `<body>`) and injects page-specific content via slots. Astro does not enforce a special layout mechanism — layouts are just components with slots.
+
+## Source
+
+https://docs.astro.build/en/basics/astro-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/astro-component-pattern/skill.yaml

@@ -0,0 +1,44 @@
+name: astro-component-pattern
+version: '1.0.0'
+description: Structure .astro components with frontmatter, template, and scoped styles following Astro conventions
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths:
+  - 'astro.config.*'
+  - '**/*.astro'
+  - '**/src/pages/**'
+  - '**/src/content/**'
+related_skills:
+  - astro-islands-architecture
+  - astro-content-collections
+  - astro-routing-pattern
+stack_signals:
+  - astro
+  - typescript
+keywords:
+  - astro-component
+  - frontmatter
+  - component-script
+  - scoped-styles
+  - slots
+  - props
+  - Astro.props
+  - define:vars
+  - is:global
+  - is:inline
+metadata:
+  author: docs.astro.build
+  upstream: 'docs.astro.build/en/basics/astro-components'
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/cursor/astro-content-collections/SKILL.md

@@ -0,0 +1,155 @@
+# Astro Content Collections
+
+> Type-safe, schema-validated content management built into Astro — no CMS required for structured Markdown, MDX, and data files.
+
+## When to Use
+
+- You are organizing Markdown, MDX, YAML, or JSON content files in `src/content/`
+- You need frontmatter validation with helpful error messages (not silent failures)
+- You want TypeScript types auto-generated from your content schema
+- You are querying multiple content entries (blog posts, docs pages, team members) and need filtering and sorting
+- You want to render Markdown content with `<Content />` and get full type safety on the rendered entry
+
+## Instructions
+
+1. Create a collection config at `src/content/config.ts`. This is the single source of truth for all collections.
+
+2. Define each collection with `defineCollection()` and a Zod schema. Every frontmatter field should be declared:
+
+```typescript
+// src/content/config.ts
+import { defineCollection, z } from 'astro:content';
+
+const blog = defineCollection({
+  type: 'content', // 'content' for .md/.mdx, 'data' for .json/.yaml
+  schema: z.object({
+    title: z.string(),
+    description: z.string().max(160),
+    pubDate: z.coerce.date(),
+    updatedDate: z.coerce.date().optional(),
+    heroImage: z.string().optional(),
+    tags: z.array(z.string()).default([]),
+    draft: z.boolean().default(false),
+  }),
+});
+
+const authors = defineCollection({
+  type: 'data',
+  schema: z.object({
+    name: z.string(),
+    email: z.string().email(),
+    avatar: z.string().url(),
+  }),
+});
+
+export const collections = { blog, authors };
+```
+
+3. Place content files under `src/content/<collection-name>/`. The directory name must match the collection key exported from `config.ts`.
+
+4. Use `getCollection()` to fetch all entries. Apply filters inline — do not load all entries and filter in the template:
+
+```typescript
+// src/pages/blog/index.astro
+---
+import { getCollection } from 'astro:content';
+
+// Exclude drafts in production
+const posts = await getCollection('blog', ({ data }) => {
+  return import.meta.env.PROD ? !data.draft : true;
+});
+
+// Sort by date descending
+const sorted = posts.sort((a, b) => b.data.pubDate.valueOf() - a.data.pubDate.valueOf());
+---
+```
+
+5. Use `getEntry()` to fetch a single entry by collection name and slug:
+
+```typescript
+const post = await getEntry('blog', 'my-first-post');
+if (!post) return Astro.redirect('/404');
+const { Content } = await post.render();
+```
+
+6. Render Markdown/MDX content with the `<Content />` component returned from `entry.render()`:
+
+```astro
+---
+const { Content, headings, remarkPluginFrontmatter } = await post.render();
+---
+<article>
+  <Content />
+</article>
+```
+
+7. Use `z.coerce.date()` for date fields in frontmatter — raw frontmatter dates are strings, and coercion converts them to `Date` objects automatically.
+
+8. Reference images in frontmatter using the `image()` helper for build-time optimization integration:
+
+```typescript
+import { defineCollection, z, reference } from 'astro:content';
+schema: ({ image }) =>
+  z.object({
+    cover: image(), // local image, processed by astro:assets
+    author: reference('authors'), // type-safe cross-collection reference
+  });
+```
+
+## Details
+
+Content Collections were introduced in Astro 2.0 to solve the problem of unstructured, unvalidated frontmatter. Without collections, a typo in a date field or a missing required property would either silently pass or cause a runtime error deep in your template. With collections, Astro validates every entry at build time using Zod and surfaces clear errors.
+
+**The `type` distinction:**
+
+- `type: 'content'` — for `.md` and `.mdx` files. Entries have `body` (raw Markdown string), `render()` method, and `slug` (auto-derived from filename).
+- `type: 'data'` — for `.json` and `.yaml` files. Entries have only `data` (the parsed object). No `render()` or `slug`.
+
+**Generated types:**
+
+Astro generates `.astro/types.d.ts` from your collection config. This gives you full IntelliSense on `entry.data.title`, `entry.data.pubDate`, etc., without manual type declarations.
+
+**Slugs and IDs:**
+
+- `entry.slug` — the path relative to the collection directory, without the extension. For `src/content/blog/2024/my-post.md`, the slug is `2024/my-post`.
+- `entry.id` — same as slug but with the extension included. Primarily used for `data` collections.
+
+**Cross-collection references:**
+
+Use `reference('collectionName')` in a Zod schema to create typed cross-collection references. Astro validates that the referenced entry exists at build time. Resolve references with `getEntry(entry.data.author)`.
+
+**Content Layer API (Astro 5+):**
+
+Astro 5 introduced the Content Layer API, which extends collections to support external data sources (remote APIs, databases, CMSes). Use `loader` in `defineCollection()`:
+
+```typescript
+const products = defineCollection({
+  loader: async () => {
+    const res = await fetch('https://api.example.com/products');
+    return res.json(); // array of objects with an `id` field
+  },
+  schema: z.object({ id: z.string(), name: z.string(), price: z.number() }),
+});
+```
+
+**Performance:** `getCollection()` reads from the file system at build time (SSG) or at request time (SSR). In SSG, results are used to generate static pages via `getStaticPaths()`. In SSR, consider caching results if collections are large.
+
+## Source
+
+https://docs.astro.build/en/guides/content-collections
+
+## 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/astro-content-collections/skill.yaml

@@ -0,0 +1,42 @@
+name: astro-content-collections
+version: '1.0.0'
+description: Organize and validate content with Astro content collections, schema definitions, and getCollection
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths:
+  - 'astro.config.*'
+  - '**/*.astro'
+  - '**/src/content/**'
+  - '**/src/pages/**'
+related_skills:
+  - astro-component-pattern
+  - astro-routing-pattern
+  - astro-image-optimization
+stack_signals:
+  - astro
+  - typescript
+keywords:
+  - content-collections
+  - getCollection
+  - getEntry
+  - defineCollection
+  - zod-schema
+  - frontmatter
+  - content-layer
+  - type-safe-content
+metadata:
+  author: docs.astro.build
+  upstream: 'docs.astro.build/en/guides/content-collections'
+state:
+  persistent: false
+  files: []
+depends_on: []