toolbox

Prepare a @toolbox-web library for release AND drive release-please versioning. Covers the pre-release checklist (lint, test, build, bundle size, CHANGELOG, docs) PLUS release-please version operations — graduating a prerelease to GA (rc → stable), switching the prerelease identifier (beta → rc), and the per-package path-scoped Release-As bootstrap commits. Use when cutting a release, promoting a prerelease line to stable, or whenever release-please proposes the wrong version (e.g. an rc/patch bump when you expect the clean GA version like 3.0.0).

Run deterministic codebase-intelligence analysis with fallow. Covers health scoring (complexity/CRAP/refactor targets), dead code, duplication, dependency hygiene, and PR-scoped audit. Use before opening a PR, as part of `/qa`, or to identify refactoring opportunities in a file or plugin. Produces machine-actionable JSON findings that can be fed directly into `qa-apply-findings`.

Add a new feature OR backport a bugfix consistently across the Angular, React, and Vue adapter libraries for @toolbox-web/grid. Use whenever you touch one adapter, to confirm the other two need the same change and to keep full parity.

Create a new framework adapter library for @toolbox-web/grid, with a matching demo app. Covers library scaffolding, adapter implementation, demo setup, workspace wiring, and e2e parity testing.

Author, restructure, or update documentation for the Astro/Starlight docs site. Covers ADDING a new docs page or route (MDX + sidebar registration in astro.config.mjs + llms.txt/llms-full.txt inclusion), which prose/MDX and API-reference docs to check after a code change, how to write them, the `<Audience>` and `llmsFull` curation knobs, and regenerating typedoc API docs. Use whenever you create, move, rename, or edit any file under apps/docs/, or after any feature, fix, or refactor that touches user-visible behaviour. (For building a new interactive demo component, use the astro-demo skill instead.)

Read, reply to, and resolve review-comment threads on a GitHub pull request using the gh CLI. Use whenever you need to triage PR feedback (fetch all unresolved review threads as structured JSON, post inline replies on specific threads, and mark threads resolved) instead of hand-writing a one-off gh/GraphQL script each time. Prefer this over the generic address-pr-comments skill for bulk thread triage and programmatic gh/GraphQL access.

Shared execution core for QA workflows. Apply a normalized findings list, validate changes, and produce a structured result that can be used by both local `/qa` and reactive `/pr-qa` flows.

Create an interactive Astro demo component and its MDX docs page for a grid feature or plugin. Scaffolds .astro demo files following project conventions. Use when adding a live/interactive example; for updating existing prose or API-reference docs, use the docs-update skill instead.

Create a new grid plugin for @toolbox-web/grid following the canonical plugin structure. Use when adding a plugin or extending the grid with optional, toggleable behaviour (hooks, styles, tests, and documentation). Prefer a plugin over a core feature to keep the bundle lean.

Debug or reproduce a component issue in a live browser using the Chrome DevTools MCP server. Use to get a live repro, inspect the DOM, watch console errors, analyze network requests, take screenshots, or evaluate scripts against a running grid. Covers launching dev servers and navigating to pages/stories. (For performance traces and hot-path profiling, use the debug-perf skill.)

Investigate, optimize, and prevent performance regressions in @toolbox-web/grid. Use when something is slow, janky, or memory-leaking, when checking or guarding against a performance regression, when optimizing or improving a hot path, or when capturing/analyzing a performance trace. Covers Chrome DevTools MCP trace capture, the bundled trace analyzer, profiling, hot-path analysis, virtualization tuning, and render-scheduler optimization. (For micro-benchmark regression gating with .bench.ts, see the `bench` skill.)

Analyze test coverage for a specific file or project in the toolbox-web monorepo and write missing tests to improve coverage. Use when coverage is low, when a file or branch is untested/uncovered, or when adding tests for existing code. Follows project test patterns (co-located specs, Vitest, happy-dom).

Run @toolbox-web benchmarks as local regression testing during development — either current-vs-previous-run (`bun run bench`) or current-vs-tag (the bundled bench-vs-tag.ts orchestrator). Covers writing `.bench.ts` files as part of issue development, running the suites, locating artifacts, and interpreting regressions. Use when implementing a perf-sensitive change, before opening a PR that touches hot paths, or when asked to benchmark.

Check that the @toolbox-web/grid build stays within bundle size budget (index.js ≤170 kB raw, ≤50 kB gzipped hard limit, ≤45 kB gzipped soft warning). Run after any code change that could affect bundle size.

Post-task "lessons learned" review. Evaluates what worked, what didn't, and proposes updates to instruction and skill files to continuously improve AI-assisted development workflows.

Run the toolbox-web Playwright e2e suites — docs-demo tests, cross-framework parity tests, performance-regression and stability tests. Covers starting demo servers, the various run commands, and updating visual baselines.

Determine the correct `@since` JSDoc version for new public API in @toolbox-web libraries, and bulk-refresh existing tags. Use whenever you add a public type, interface, method, property, exported constant, or event detail and need its `@since` value — instead of guessing.