Creates tests for Hilla use cases on both sides of the browser boundary: Vitest + React Testing Library tests for the React/TypeScript view (with the generated endpoint clients mocked) and Spring Boot integration tests for the @BrowserCallable service behind it. Use when the user asks to "test a Hilla view", "write Hilla tests", "test a React view for Vaadin", "test a @BrowserCallable service", "write Vitest tests for a Hilla app", or mentions Hilla testing, React Testing Library for Vaadin, endpoint mocking, or testing TSX views.

Implements use cases by creating Hilla views — React/TypeScript views with file-based routing calling @BrowserCallable Java services — and jOOQ queries for the data access layer. Use when the user asks to "implement with Hilla", "create a Hilla view", "build a React view for Vaadin", "create a @BrowserCallable endpoint", or mentions Hilla, client-side Vaadin views, file-based routing, TSX views, or React + jOOQ.

Implements use cases by creating Vaadin Flow views, forms, and grids — server-side Java UI — and jOOQ queries for the data access layer. Use when the user asks to "implement a use case", "build the UI", "create a Vaadin view", "write the data access layer", or mentions Vaadin Flow, server-side Java views, jOOQ queries, Java web app, or database-backed UI. For Hilla (React/TypeScript) views use the implement-hilla skill instead.

Creates Karibu server-side unit tests for Vaadin views covering navigation, component interactions, form validation, grid operations, and notifications. Use when the user asks to "write Karibu tests", "unit test a Vaadin view", "test the UI server-side", "create view tests", or mentions Karibu testing, Vaadin unit tests, or server-side UI testing.

Creates Playwright browser-based tests for Vaadin views using the Drama Finder library for type-safe element wrappers with accessibility-first APIs. Covers two test types: integration tests for a single use case (UC-*) and end-to-end journey tests for a test case (TC-*) spanning multiple use cases. Use when the user asks to "write Playwright tests", "create e2e tests", "write integration tests", "test in the browser", "write IT tests", "automate a test case", "test a user journey", or mentions end-to-end testing, browser tests, UI integration tests, Playwright for Vaadin, or Drama Finder. Also trigger when the user references a use case (UC-*) or a test case (TC-*) and asks for Playwright or E2E tests.

Shared utility scripts for DLD skills. Not intended for direct invocation — used internally by other DLD skills.

Record a single development decision as a markdown file with YAML frontmatter. Collects context, rationale, and code references interactively.

Implement one or more proposed decisions. Makes code changes, adds `@decision` annotations, and updates decision status.

Bootstrap DLD (Decision-Linked Development) in a repository. Creates dld.config.yaml, the decisions/ directory, and INDEX.md. Run once per project.

Look up decisions by ID, tag, code path, or keyword. IMPORTANT — use this proactively whenever you encounter `@decision` annotations in code you are about to read or modify.

Break down a feature into multiple decisions interactively. Creates a set of decision records grouped by a shared tag.

Resolve decision ID collisions between a local branch and the base branch (and open PRs) before rebasing. Renames colliding local decisions with git mv, rewrites cross-references and annotations, then squashes branch commits into a single rebase-clean reindex commit.

Bootstrap DLD decisions from an existing codebase. Analyzes code to infer rationale, generates decision records, and adds `@decision` annotations.

Generate SNAPSHOT.md (detailed decision reference) and OVERVIEW.md (narrative synthesis with diagrams) from the decision log.

Quick overview of the decision log state — counts by status, recent decisions, and run tracking info.

Creates Playwright browser-based end-to-end tests for Angular views using Playwright's native accessibility-first locators (getByRole, getByLabelText, getByText). Covers two test types: tests for a single use case (UC-*) and end-to-end journey tests for a test case (TC-*) spanning multiple use cases. Use when the user asks to "write Playwright tests", "create e2e tests", "write integration tests", "test in the browser", "automate a test case", "test a user journey", or mentions end-to-end testing, browser tests, or UI integration tests for this stack. Also trigger when the user references a use case (UC-*) or a test case (TC-*) and asks for Playwright or E2E tests.

Creates Spring Boot tests for REST controllers and Spring Data JPA repositories. Defaults to MockMvcTester and RestTestClient + Testcontainers for new projects (asking the user to confirm on the very first backend test), but detects and follows whichever convention a project already uses — including legacy MockMvc or RestAssured + Testcontainers — rather than migrating it. Use when the user asks to "write backend tests", "test the REST API", "test the controller", "write a Spring Boot test", "test the JPA repository", or mentions MockMvc, MockMvcTester, RestAssured, RestTestClient, Testcontainers, @SpringBootTest, or server-side Java testing for this stack.

Creates Vitest component tests for Angular views using Angular's own testing idioms — TestBed, ComponentFixture, and HttpTestingController — not React Testing Library patterns. Use when the user asks to "write frontend tests", "test the Angular component", "write a Vitest test", "unit test an Angular page", or mentions TestBed, HttpTestingController, or component testing for this stack.

Creates Playwright browser-based end-to-end tests for a Next.js frontend running against a live NestJS API: a test.describe per use case (UC-XXX) with a test per scenario, or a journey per test case (TC-XXX) with one test.step per Flow row, tagged @UC-XXX / @TC-XXX, with accessibility-first locators and the application's seed data, wired into the project's playwright.config webServer setup. Use when the user asks to "write Playwright tests", "create e2e tests", "write end-to-end tests for UC-001", "automate TC-001", "test in the browser", or mentions end-to-end testing, browser tests, or a test case (TC-*) to automate.

Creates Vitest component tests for Next.js App Router pages and React components with React Testing Library in jsdom: renders the client component, drives it with user-event, mocks the project's API client module, asserts the rendered content, the messages, and the requests sent to the NestJS API, one describe block per use case (UC-XXX). Use when the user asks to "write frontend tests", "write Vitest tests for the page", "write React unit tests", "test the component", "write an RTL test", or mentions React Testing Library, jsdom, or component testing for a Next.js project. Browser tests against the running stack are /playwright-test.

Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.

Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.

Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.

Sync delta specs from a change to main specs. Use when the user wants to update main specs with changes from a delta spec, without archiving the change.

Reviews the entire PLAN.md of a new project through fixed, file-only provider rounds. Triggered by plan-mode when every plan entry is draft; Round 1 alternates Codex and Claude, then returns control to a human checkpoint.

Builds and maintains openspec/PLAN.md, the human-approved plan that sequences OpenSpec changes toward a stated goal — the tier above tasks.md. Explore read-only, draft entries, then stop and ask for approval; a change cannot start until its entry is approved. Trigger — make a plan, what should we build first, plan the work, roadmap, add this to the plan, approve the plan, why is the plan gate failing, NO-ENTRY, HASH-MISMATCH.

Rewrites a confirmed REFINED_PROMPT.md from prompt-loop into an ENGINEERED_PROMPT.md ready to execute: cleaned of reasoning-scripting and shouting, structured into the task contract (objective, context, scope, tools, action boundaries, verification, output, stop condition), every change traced to a numbered prompting rule, the lock register carried byte-identical, and an effort level recommended. Runs in a fresh-context subagent and never asks the user anything. Trigger — automatically after prompt-loop's output contract is confirmed and before openspec-propose, for non-trivial development work; explicitly on: engineer this prompt, ottimizza il prompt, prompt engineering, ingegnerizza il prompt, make this prompt executable. Do not use it on a prompt that has not been through prompt-loop: without a confirmed REFINED_PROMPT.md there is nothing to engineer.

Refines an incoming prompt through a bounded score → interview → lock → rewrite loop until it is mechanically good enough (rubric score ≥ 9/10) to feed the SDD workflow. Trigger — automatically before openspec-propose when the request is non-trivial development work; explicitly on: refine this prompt, prompt loop, score my prompt, is this prompt ready.

Structured interview process that turns a vague stakeholder request into clear, actionable requirements before any spec or code is written. Trigger — new feature request, unclear requirements, vague task, clarify scope, before proposing a change.

Single entry point to the spec-as-source workflow: given a request, decides which of the plugin's skills to activate — excluding trivial work first, deriving the current phase from the state of the repo second, and matching descriptions last — then runs the chosen skill inline or in a subagent. Use when you do not know which skill applies, or want the workflow driven for you. Trigger — which skill should I use, what do I do next, route this, start working on X, implement X, propose a change, continue the implementation, I want to build X, help me with this project, non so da dove partire.

Installs the spec-as-source OpenSpec schema, enforcement scripts, CI workflow, and pre-commit hooks into a project. Trigger — setup spec enforcement, add spec checks, configure spec-as-source, install spec scripts, add spec CI, install openspec schema.

Syncs .github/workflows/spec-verification.yml with the test runner and test files declared in specs. Trigger — update CI workflow, sync spec CI, regenerate workflow, CI out of sync with specs, add spec test to CI.

Runs an autonomous Ralph-style loop over the tasks of an active OpenSpec change: one task per fresh-context agent invocation, mechanically gated by scripts/verify.sh, with runaway guardrails. Trigger — run the loop, ralph loop, autonomous apply, loop the tasks, implement the change unattended.

Deletes all files declared as targets in openspec/specs/**/spec.md and rebuilds them from the specs to verify spec-as-source integrity. Trigger — clean rebuild, verify source of truth, spec drift check, regenerate from specifications, rebuild from spec.

Runs all spec consistency checks (link integrity, target ownership, manifest build), the test suite, and a semantic drift spot-check, then reports results. Trigger — verify specs, spec check, run spec suite, check spec consistency, validate spec links, spec integrity, spec drift.

Creates and maintains capability spec.md files under openspec/specs/: requirements, scenarios, targets frontmatter, and Verified by test links. Trigger — write a spec, update a spec, document requirements, create capability spec, spec drift in frontmatter or links.

Reviews completed implementation requirement-by-requirement against its capability spec, with file:line evidence, before declaring work done. Trigger — review my work, is this done, verify completeness, check against spec before merging, final review.

Use when the user shares a Mermaid ER diagram, schema sketch, or relationship diagram and asks for review, feedback, validation, or critique — including phrases like "what do you think of this", "look at this diagram", "I have this in mind", "can we model it like this", or pastes any block starting with "erDiagram" or "classDiagram". Validates the diagram against the constitution, returns a five-section structured response (constitutional violations, counter-proposal with improved Mermaid, migration plan if existing schema applies, test surface, open questions), and never silently accepts a design that violates tenant isolation, eventing, or graph-RAG boundaries.

Use when designing or reviewing the eventing layer of the commerce platform — including transactional outbox tables, outbox relays, domain event catalogs, idempotency keys, audit logs, memento snapshots, event sourcing decisions, and Neo4j projection workers. Triggered by requests to design events, design integration with external systems, design notification flows, design data sync to Neo4j or analytics warehouses, decide between event sourcing and CRUD, or review existing outbox / audit / event-sourcing schemas.

Use when the agent needs to inspect the actual current state of a PostgreSQL database before answering a schema question — including before adding columns, before reviewing diagrams, before proposing migrations, or whenever the snapshot in .specify/memory/current-schema-state.md is stale. Connects via the configured Supabase MCP/read-only schema source, queries catalog metadata through list_tables or SELECT-only catalog SQL, and refreshes the snapshot file. Triggered by any "let me check what's already there", "what columns does X have", "what indexes exist on Y", "what does the schema look like", or by the snapshot being older than 24 hours.

Use when the user wants to add an attribute, modify an entity, or model a new concept on top of an existing PostgreSQL schema — including phrases like "add a column to", "track this on the product", "we need to store", "model this concept", "extend the order with", "where should this live", or "should this be a new table". Inspects current state via the postgres-schema-introspection skill, runs a five-placement analysis (new column / JSONB key / EAV row / new related table / wrong entity), maps blast radius across foreign keys, outbox events, Neo4j projections, RLS, and indexes, and produces an expand/contract migration plan with rollback and tests.

Use when repository changes are complete and you need to run and report the required validation gates for the applicable change class (`docs-only`, `terraform-module`, `example-terraform`, `ci-workflow`, or `mixed`).

Review completed implementation against approved specs to ensure all requirements are satisfied. Use after finishing implementation work, before marking a task as done, or when a stakeholder asks to verify deliverables against requirements. Produces a review summary with pass/fail per requirement. Common triggers: "review my work", "check against spec", "did I miss anything", "is implementation complete".

Resolve required NanoClaw host contracts, load operation constraints and identify exception checks before host work. Use for "deploy NanoClaw", "publish a plugin", "update image packages", "extract an overlay", "restore browser login", "enroll the private browser viewer", "relink WhatsApp", "recover a task", "check memory budgets", "read meeting chat evidence" or "capture Sessionize My Events" when a nanoclaw-host rule requires its full procedure. This skill reads the applicable policy; it does not deploy, operate services or grant approval.

Kill a running agent container on the NAS by Telegram group JID. The orchestrator respawns a fresh container on the next message. Does NOT delete registration or group folder. Use when a container is stuck, stale, or needs a fresh start.

Promote agent-created skills and rules from NAS staging to plugin GitHub repos — opens a PR from staging, then hands the review, merge, and publish-confirmation lifecycle to the release skill. Use when there are new items on staging, after check-staging shows pending items, or when asked to deploy skills, push to production, or publish rules to a plugin repo. The promote scripts keep the historical `TILE_NAME` env var.

Verify that all tessl plugins are in sync between git source, tessl registry, and the NAS orchestrator. Reports drift, unpublished content, untracked files, and version mismatches. Use when plugin state seems wrong, container behavior looks stale, you suspect out-of-sync plugins, or need to check plugin health before a release. Run after promoting skills or after any manual plugin edits. The script keeps its historical name, `./scripts/reconcile-tiles.sh`.

Ship a committed code change to private NanoClaw (jbaruch/nanoclaw) through a reviewed PR, merge, and branch cleanup. Use when asked to ship a NanoClaw fix, open its PR, or merge its changes. Plugin repositories use the release skill directly.

Pull updates from qwibitai/nanoclaw directly into private NanoClaw through a reviewed PR, then deploy to NAS. Use when upstream has new features, when the user asks to update NanoClaw, or when /update-nanoclaw is invoked.

Move every app reference from an old Hubitat device onto a new one — via Settings → Swap Device where possible, a virtual-device bridge or parking slot where the swap list blocks it, and a guided manual re-select where neither works. Use when the user wants to swap, migrate, replace, or move a device's references to a different device, re-home a device to a different hub over Hub Mesh, or asks why a device does not appear in the Swap Device list.

Safely remove a Hubitat device — enumerate where it's used, warn about the blast radius before deleting, verify references cleared after, and re-wire them onto a replacement device. Use when the user wants to remove, delete, retire, or replace a device, or asks what a device is used by before deleting it.

Fire an ordered list of Hubitat devices with a timed hold on each, so you can walk the property and bind each observation to a device id — which lamp is `Kitchen 3`, which shade is `Office Left`, which valve is irrigation zone 7. Use when the user wants to map which physical thing a device controls, identify which zone/lamp/shade/valve is which, run a set of devices one at a time in sequence, or fire devices on a timer for field verification.

Update Z-Wave device firmware on a Hubitat hub via the native zwaveJS updater — discover installed versions, find vendor-latest firmware, stage it, and batch-flash safely with a radio-hang watchdog. Use when the user wants to update/flash device firmware, check which devices are behind on firmware, or fix a device whose issue a firmware update addresses.

Manage the hubs.json config that records how to reach each Hubitat hub by IP for code operations. Actions — init a config, add a hub, set the default hub, remove a hub, list hubs. Use when the user wants to configure, register, add, or list Hubitat hubs for deploy/pull/debug.

Run the Hubitat sandbox linter on app or driver Groovy and judge each finding — real defect vs. false positive — before the code goes near a hub. Use when the user wants to lint, check, or validate Hubitat code, or automatically before deploying.

Use the hub's first-party AI (MCP) Connector Integration to read hub state and drive devices over its local MCP endpoint — connect with the bearer token, discover the live tool surface, prefer read-only tools, gate sensitive actions, and verify the mutation. Use when the user wants to control or query a Hubitat hub through its MCP server / AI connector, or asks whether an operation should go through MCP or the hub_* scripts.

Diagnose Hubitat Z-Wave and Zigbee network problems — ghost/failed nodes, packet errors, weak routes, dead or unjoined Zigbee devices, devices that stopped responding to commands, a broken hub-mesh link, an unhealthy mesh. Use when the user wants to check mesh health, find ghost nodes, debug a flaky/slow/dead Z-Wave or Zigbee device, or figure out why the radio network misbehaves.

Generate a correct Hubitat app or driver skeleton from declared capabilities, with the required lifecycle callbacks, subscription/schedule idioms, and logging conventions wired in. Use when starting a new Hubitat app or driver, or when the user asks to create/scaffold/bootstrap Hubitat Groovy code.

Onboard one or more Hubitat sensors with verification at each step — pair, confirm the built-in driver auto-selected, name by function and position, raise event retention, read the real adjustable preferences, share to the mesh and confirm the mirror, add to inactivity monitoring, acceptance-test, and reconcile the inventory. Use when the user wants to onboard, install, add, or set up sensors (soil probes, contact/motion/temperature/energy sensors) on a hub, or roll out a sensor fleet.

Set up and run offline unit tests for a Hubitat app or driver — load the script under biocomp/hubitat_ci, mock the platform executor, and assert on sendEvent/log/parse output off-hub. Use when the user wants to test, unit-test, mock, or add CI for Hubitat Groovy code.

Bootstrap a new TamboUI Toolkit DSL application — generates a `ToolkitApp` subclass with a working `render()` and a `main` entry point, plus the right Maven/Gradle/JBang dependencies. Use when the user says "create a TamboUI app", "scaffold a TUI", "new tamboui app", "hello world TamboUI", or asks to start a TUI project from scratch.

Add a Toolkit `Element` wrapping an existing TamboUI widget so it gains CSS support, styled sub-components, focus integration, and a Toolkit factory method. Use when the user says "wrap a widget", "add an element for X widget", "make widget Y CSS-aware", "expose widget Z in the DSL", or asks to integrate a custom widget into the Toolkit.

Creates, updates, migrates, and audits evidence-backed personal writing identity packages by tracing voice and composition guidance to source passages while excluding employer branding. Use when someone asks to capture their writing style, make a persona from their posts, build an author voice profile or tone guide, refresh an existing writing identity, migrate legacy persona files, or audit whether a profile matches its author.