Claude Code Plugin

HLive ships a Claude Code plugin from the same repository as the framework itself. It bundles five skills that activate automatically whenever you're working on HLive code, plus two slash commands for scaffolding a component or an entire new project.

The goal is to keep Claude grounded in HLive's real, current API instead of guessing: every skill is written against the runnable code in _example/ and hlivetest/pages/ as the source of truth, so scaffolded code should compile and match how HLive actually works today.

Install

The plugin is published from a marketplace inside the HLive repo itself. From a Claude Code session, run:

If you're working from a local checkout of the HLive repo instead (for example, while contributing to the plugin itself), point the marketplace at the path on disk rather than the GitHub repo:

What's included

Five skills, each scoped to a different layer of building an HLive app:

• hlive-core — the core API: the l.T/l.C/l.CM builders, l.On event handling, l.Box reactive state, page/server setup, and the SSR-vs-WebSocket lifecycle and tree-diff gotchas covered on the Concepts page.
• hlive-hhtml — building markup with the typed, autocompleting hhtml builders (Div, Button, Class, Href, …) instead of raw tag-name strings.
• hlive-project — structuring a real multi-page app: main.go routing, a page/ package of page factories, reusable components, and static asset serving, once you've outgrown a single-file example.
• hlivekit — the companion toolkit: ComponentList for dynamic lists, giving an input focus, running logic after a diff applies with OnDiffApply, real-time updates with PubSub, visibility/scroll/redirect helpers, and preempt-disable-on-click.
• hlive-testing — writing browser tests with hlivetest and Playwright: booting a test server, driving a real browser, and asserting with hlivetest.Diff.

Skills are Claude Code's way of loading extra, targeted knowledge only when it's relevant — they activate automatically based on what you're doing (editing a file with the hhtml dot-import, asking about event handlers, mentioning Playwright, and so on). You never invoke a skill directly; you just work, and the right guidance is there.

Slash commands

/hlive-component

Scaffolds a single component or page, with events already wired up. Every argument is optional:

• name — the component or function name, e.g. counter or searchBox.
• tag — the base HTML tag, e.g. button or input. Defaults to div.
• one or more DOM event names to bind, e.g. click or keyup.
• --mountable — generate an l.CM component with a SetMount hook for fetching data when the component first appears.

If you leave arguments out or they're ambiguous, Claude asks before generating anything. Two ways to use it:

The first scaffolds a plain button component with a click handler and an l.Box counter. The second scaffolds a mountable input component that reacts to keystrokes and has a SetMount hook ready for an initial data fetch. Either way, Claude also shows you how to add the result to a page and offers to write a matching hlivetest browser test.

/hlive-new-project

Scaffolds a complete, runnable HLive project on disk — not just a snippet to copy in:

• module-path — the Go module path, e.g. github.com/you/myapp. Claude asks for this if it's missing.
• dir — the target directory. Defaults to a new directory named after the last segment of the module path.

For example:

This writes a go.mod, main.go with stdlib routing, a page/ package with a home page and a shared header component, a small assets/ reset/layout stylesheet, and a justfile. It then runs go mod init, go get github.com/SamHennessy/hlive@latest, a real go build, and gofmt -l . — fixing anything that fails before reporting success — so you're handed a project that's already known to compile, not just code that looks right.

If dir already exists and isn't empty, Claude stops and confirms with you first rather than writing over anything.

How to use it day to day

Most of the time you won't reach for a command at all. Since the five skills activate on their own, you can just describe what you want in plain language and the relevant skill's guidance is pulled in automatically. For example, just asking:

• "Add a button to this page that increments a counter" pulls in hlive-core and hlive-hhtml so the result uses l.Box and the hhtml builders correctly.
• "Where should this new settings page live?" pulls in hlive-project for the recommended file layout.
• "Show a live-updating list of connected users" pulls in hlivekit for ComponentList and PubSub.
• "Write a test that checks the counter increments" pulls in hlive-testing for the Playwright/hlivetest pattern.

Reach for the two slash commands specifically when you want a predictable, complete scaffold rather than an open-ended conversation:

• /hlive-component when you know the shape of a single component or page you want up front — its name, tag, and events — and just want it generated and wired in.
• /hlive-new-project when you're starting something new from nothing and want a verified, buildable skeleton rather than assembling one file at a time.

Because every skill is written against HLive's real, runnable source rather than a hand-maintained description of the API, the guidance you get stays accurate as the framework evolves — if something looks off, it's worth checking the current source under _example/ or hlivetest/pages/ in the HLive repo, which is exactly what the skills themselves are written against.