From xh
Authoritative reference for the @xh/hoist React framework. Use when (a) about to write or modify TypeScript/React code under a Hoist app's `client-app/` directory that consumes Hoist APIs - components (`hoistCmp`), models (`HoistModel`), services (`HoistService`), the `XH` singleton, decorators (`@bindable`, `@managed`, `@observable`, `@action`), or framework patterns (element factories, persistence, MobX integration) - OR (b) the user asks for orientation, the docs index, or where to start learning Hoist concepts (models, components, services, decorators, grids, dashboards, framework patterns) in the @xh/hoist framework, even if they're not yet authoring code. Do not guess at prop names, method signatures, decorators, or conventions - consult the reference tools first. Skip for code outside `client-app/` or for TypeScript work that doesn't import from `@xh/hoist`.
npx claudepluginhub xh/hoist-ai --plugin xhThis skill is limited to using the following tools:
You're about to write or modify code that consumes the `@xh/hoist` framework. Consult the reference tools before authoring - Hoist's API surface is large, prop names and decorators are easy to misremember, and a wrong guess produces code that compiles but fails at runtime.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Searches prompts.chat for AI prompt templates by keyword or category, retrieves by ID with variable handling, and improves prompts via AI. Use for discovering or enhancing prompts.
Checks Next.js compilation errors using a running Turbopack dev server after code edits. Fixes actionable issues before reporting complete. Replaces `next build`.
You're about to write or modify code that consumes the @xh/hoist framework. Consult the reference tools before authoring - Hoist's API surface is large, prop names and decorators are easy to misremember, and a wrong guess produces code that compiles but fails at runtime.
Each workflow step has two interfaces. Use the column that matches what's in your tool context.
| Step | MCP tool | CLI command |
|---|---|---|
| Search docs | mcp__hoist-react__hoist-search-docs | npx hoist-docs search "<query>" |
| List docs by category | mcp__hoist-react__hoist-list-docs | npx hoist-docs list -c <category> |
| Read a specific doc | mcp__hoist-react__hoist-search-docs (with id query) | npx hoist-docs read <docId> |
| Search symbols / members | mcp__hoist-react__hoist-search-symbols | npx hoist-ts search "<query>" |
| Get symbol details | mcp__hoist-react__hoist-get-symbol | npx hoist-ts symbol <name> |
| List class members | mcp__hoist-react__hoist-get-members | npx hoist-ts members <name> |
If mcp__hoist-react__* tools are listed in your tool context, prefer them. Otherwise use the CLI column. The MCP tool names look the same regardless of whether the server is running locally or as a deployed remote endpoint - transport is invisible to you.
Standard sequence for any Hoist authoring task:
mcp__hoist-react__hoist-list-docs, mcp__hoist-react__hoist-search-docs with a broad query, or npx hoist-docs index) when you're new to the area. Find the right README."panel modal" finds ModalSupportModel via its JSDoc.get-symbol for full details, or get-members to list a class's properties and methods with types and decorators.filePath when symbol names collide (e.g. View exists in both cmp/viewmanager and data/cube).Look up a component's available props.
mcp__hoist-react__hoist-get-members with name: "GridConfig" (or whatever *Config interface fronts the component).npx hoist-ts members GridConfigFind which decorator a model property uses.
mcp__hoist-react__hoist-get-members with name: "<MyModelClass>".npx hoist-ts members <MyModelClass>Look up a service method by behavior, not name.
mcp__hoist-react__hoist-search-symbols with query: "fetch loadConfigs" (multi-word AND match against names + JSDoc).npx hoist-ts search "fetch loadConfigs"Find the convention for something cross-cutting (persistence, theming, lifecycle).
mcp__hoist-react__hoist-search-docs with query: "persistence MobX integration".npx hoist-docs search "persistence MobX integration"Read the docs index.
mcp__hoist-react__hoist-list-docs (or hoist-search-docs with a broad query).npx hoist-docs index (shorthand for read docs/README.md).Print coding conventions.
mcp__hoist-react__hoist-search-docs with query: "coding conventions" then read the matching id.npx hoist-docs conventions"modal" may miss the answer. Use multi-word queries that include behavior keywords ("panel modal") - JSDoc matching surfaces symbols whose names don't include the term.*Config interface with its consuming class. GridModel (the class) and GridConfig (its config interface) both exist. GridModel's properties are runtime state; GridConfig's are configuration knobs. Use members on whichever you actually need - they answer different questions.search-symbols returns multiple matches with the same name (e.g. View in cmp/viewmanager AND data/cube), the tool will hint that you should pass a file path. Do so.Read on framework source. If the reference tools answer the question, prefer them - they expose JSDoc and decorator info more cleanly than reading source. Read the source only as a last resort.If neither MCP tools (mcp__hoist-react__*) nor the CLI (npx hoist-docs, npx hoist-ts) are present in your context, stop and tell the user. Do not improvise Hoist APIs from training data - prop names, decorators, and conventions evolve, and stale guesses produce real bugs.
If the project has @xh/hoist installed locally, you may use the Read tool to read package READMEs (e.g. client-app/node_modules/@xh/hoist/core/README.md) as a last resort. Surface the limitation to the user; the recommended fix is to ensure the plugin's MCP server or CLI is wired up via /xh:onboard-app.