Run any Skill in Manus with one click

add-component-harness

Stars55

Forks36

UpdatedJune 12, 2026 at 17:14

Workflow for adding a test harness to an existing @skyux/* component in this Nx monorepo. Use when asked to "add a harness", "write a test harness", "create a SkyXHarness", or backfill harness coverage for a component that already ships without one. Covers locating the component and its public API, mirroring a sibling harness, writing the harness + filters + spec, wiring the testing/src/public-api.ts barrel and documentation.json, and the test/lint/format gate. For brand-new components, use the add-skyux-component skill instead (its step 6 creates the harness).

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

blackbaud

blackbaud/skyux

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software Quality Assurance Analysts and TestersComputer and Mathematical Occupations·SOC 15-1253

SKILL.md

readonly

name	add-component-harness
description	Workflow for adding a test harness to an existing @skyux/* component in this Nx monorepo. Use when asked to "add a harness", "write a test harness", "create a SkyXHarness", or backfill harness coverage for a component that already ships without one. Covers locating the component and its public API, mirroring a sibling harness, writing the harness + filters + spec, wiring the testing/src/public-api.ts barrel and documentation.json, and the test/lint/format gate. For brand-new components, use the add-skyux-component skill instead (its step 6 creates the harness).
argument-hint	<library> <ComponentName> (e.g. forms SkyCheckbox)

Add a Test Harness to an Existing Component

Use this skill to backfill or add a CDK component test harness for a component that already lives in a published @skyux/* library. The detailed conventions live in component-harnesses.instructions.md (it auto-applies to **/libs/components/**/testing/src/modules/**) — read it before writing code rather than guessing.

Read AGENTS.md first if you are not already familiar with the monorepo's conventions (Nx tasks, public API discipline, the sky/Sky export prefix, the Karma vs. Jest split, and Conventional Commits).

When to Use

A consumer needs a harness for an existing component that doesn't have one.
Extending an existing harness to cover newly added component inputs/outputs.

Do NOT use this skill to:

Create a brand-new component — use the add-skyux-component skill, which creates the harness as part of its flow.
Author harnesses outside libs/components/* (the harness base classes and documentation.json wiring are specific to those libraries).

Procedure

Work top to bottom. Follow the canonical patterns in component-harnesses.instructions.md for all code-level detail; open a sibling harness only to look up facts (which sub-harness a child component exposes, the template's CSS classes), not to copy its structure or naming.

Locate the component and read its public API. Find the component under libs/components/<library>/src/lib/modules/<module>/. Note its tag/selector (the hostSelector), every public input()/@Input(), output(), model(), the relevant template CSS classes, and any child SKY UX components (candidates for sub-harness composition). The harness should expose this surface and nothing internal.
Choose a base class (SkyComponentHarness or SkyQueryableComponentHarness) per the instruction file's "Choosing a base class".
Create the harness, filters, and spec under libs/components/<library>/testing/src/modules/<module>/ (<component>-harness.ts, <component>-harness-filters.ts, and <component>-harness.spec.ts) following component-harnesses.instructions.md for the class structure, locators, filters, and spec conventions. The harness must expose the public API surface identified in step 1, and the spec must cover every public method and thrown-error path (most projects enforce 100% coverage).
Wire the public API. Export the harness and its filters from libs/components/<library>/testing/src/public-api.ts, using the sky/Sky prefix.
Update documentation. Add both doc IDs to the library's documentation.json under the matching group's testing.docsIds (e.g. ["SkyExampleHarness", "SkyExampleHarnessFilters"]).

Verify. Run the testing project's specs headless, then lint and format:

npx nx test <library>-testing --browsers=ChromeHeadless
npm run lint:affected
nx format --files=<changed-file-paths>

Commit. Use a Conventional Commit with the components/<library> scope per commit-message.instructions.md.

Definition of Done

Harness, filters, and harness spec exist under the library's testing/ tree and follow the patterns in the instruction file.
The harness exposes the component's public API (inputs/outputs/models, key interactions, child harnesses) with JSDoc on the class and every public member; hostSelector is @internal.
Harness and filters are exported (with the sky/Sky prefix) from testing/src/public-api.ts and listed in documentation.json's testing.docsIds.
npx nx test <library>-testing passes at the project's coverage threshold, lint is clean, and changed files are formatted.

More from this repository

same repository

add-component-unit-tests

blackbaud/skyux

Workflow for writing or backfilling Karma + Jasmine unit tests for a component or directive that ships from a @skyux/* library in this Nx monorepo. Use when asked to "write unit tests", "add a spec", "test this component/directive", or raise coverage for library source under libs/components/<lib>/src/lib/**. Covers reading the public API, mirroring a sibling spec, the fixture/TestBed setup, accessibility tests, SKY custom matchers, coverage, and the test/lint/format gate. For code-example demo specs use the code-examples instruction; for test harnesses use the add-component-harness skill.

2026-06-1255

add-component-visual-tests

blackbaud/skyux

Workflow for adding Storybook visual-test stories for a @skyux/* component in this Nx monorepo, used for Percy visual regression snapshots. Use when asked to "add visual tests", "add a story", "create a storybook story", or set up Percy/visual coverage for a component. Covers the @skyux-sdk/e2e-schematics:story generator, the component-e2e generator when no storybook app exists yet, the wrapper component + .stories.ts conventions, and the build/lint/format gate. For unit tests use the add-component-unit-tests skill; for harnesses use the add-component-harness skill.

2026-06-1255

add-skyux-code-example

blackbaud/skyux

Workflow for authoring a code example (demo) component for a @skyux/* component in this Nx monorepo, published from @skyux/code-examples and shown in the docs. Use when asked to "add a code example", "create a demo", "add a documentation example", or showcase a component for consumers. Covers the end-to-end workflow: the src/index.ts barrel, auto-generated routes (code-examples:prebuild), documentation.json wiring, and the test/lint/format gate. Component-authoring and spec conventions live in component-code-examples.instructions.md.

2026-06-1255

add-skyux-component

blackbaud/skyux

End-to-end workflow for adding a new component (or directive/service) to an existing @skyux/* library in this Nx monorepo. Use when asked to "add a component", "create a new SKY UX component", scaffold a component with its module, harness, code example, tests, and docs, or wire a new component into a library's public API. Covers file layout, the src/index.ts barrel and sky/Sky prefix rules, SCSS compat overrides, test harness, code-example unit tests, documentation.json, and the test/lint/format/commit gate.

2026-06-1255

add-skyux-library

blackbaud/skyux

Workflow for creating a brand-new published @skyux/* component library (a new component suite) in this Nx monorepo. Use when asked to "create a new library", "add a new component suite", "scaffold a new @skyux package", or stand up a new publishable package under libs/components/. Covers the @nx/angular:library generator, the SKY-specific project.json/ng-package.json/package.json wiring mirrored from a sibling library, the src/index.ts barrel and testing/ entry point, documentation.json, the e2e/storybook app, i18n resources, and the test/lint/format/commit gate. For adding a component to a library that already exists, use the add-skyux-component skill instead.

2026-06-1255

name	add-component-harness
description	Workflow for adding a test harness to an existing @skyux/* component in this Nx monorepo. Use when asked to "add a harness", "write a test harness", "create a SkyXHarness", or backfill harness coverage for a component that already ships without one. Covers locating the component and its public API, mirroring a sibling harness, writing the harness + filters + spec, wiring the testing/src/public-api.ts barrel and documentation.json, and the test/lint/format gate. For brand-new components, use the add-skyux-component skill instead (its step 6 creates the harness).
argument-hint	<library> <ComponentName> (e.g. forms SkyCheckbox)

Add a Test Harness to an Existing Component

When to Use

A consumer needs a harness for an existing component that doesn't have one.
Extending an existing harness to cover newly added component inputs/outputs.

Do NOT use this skill to:

Create a brand-new component — use the add-skyux-component skill, which creates the harness as part of its flow.
Author harnesses outside libs/components/* (the harness base classes and documentation.json wiring are specific to those libraries).

Procedure

Locate the component and read its public API. Find the component under libs/components/<library>/src/lib/modules/<module>/. Note its tag/selector (the hostSelector), every public input()/@Input(), output(), model(), the relevant template CSS classes, and any child SKY UX components (candidates for sub-harness composition). The harness should expose this surface and nothing internal.
Choose a base class (SkyComponentHarness or SkyQueryableComponentHarness) per the instruction file's "Choosing a base class".
Create the harness, filters, and spec under libs/components/<library>/testing/src/modules/<module>/ (<component>-harness.ts, <component>-harness-filters.ts, and <component>-harness.spec.ts) following component-harnesses.instructions.md for the class structure, locators, filters, and spec conventions. The harness must expose the public API surface identified in step 1, and the spec must cover every public method and thrown-error path (most projects enforce 100% coverage).
Wire the public API. Export the harness and its filters from libs/components/<library>/testing/src/public-api.ts, using the sky/Sky prefix.
Update documentation. Add both doc IDs to the library's documentation.json under the matching group's testing.docsIds (e.g. ["SkyExampleHarness", "SkyExampleHarnessFilters"]).

Verify. Run the testing project's specs headless, then lint and format:

npx nx test <library>-testing --browsers=ChromeHeadless
npm run lint:affected
nx format --files=<changed-file-paths>

Commit. Use a Conventional Commit with the components/<library> scope per commit-message.instructions.md.

Definition of Done

Harness, filters, and harness spec exist under the library's testing/ tree and follow the patterns in the instruction file.
The harness exposes the component's public API (inputs/outputs/models, key interactions, child harnesses) with JSDoc on the class and every public member; hostSelector is @internal.
Harness and filters are exported (with the sky/Sky prefix) from testing/src/public-api.ts and listed in documentation.json's testing.docsIds.
npx nx test <library>-testing passes at the project's coverage threshold, lint is clean, and changed files are formatted.