@hailer/mcp 2.0.0-beta.4 → 2.0.0-beta.7

package/.claude/skills/create-and-publish-app/SKILL.md

@@ -111,6 +111,10 @@ npm run publish-production -- --create --app-name "<App Name>" --workspace <work
 npm run publish-production -- --host http://hailer-api:1337 --create --app-name "<App Name>" --workspace <workspaceId> --force
 ```
 
+**FIRST-PUBLISH GOTCHA — the `--create` bundle embeds a stale manifest. Do these two things:**
+1. **Before publishing, fix `public/manifest.json`**: the scaffold leaves a placeholder `author` (e.g. "Magic Apps Ltd.") and `description`. Set the real values now — the agent controls these.
+2. **After the `--create` publish, republish once** (plain `npm run publish-production -- --force`). Reason: the script packs the tarball *before* `--create` learns the new `appId`, so the first uploaded bundle has the placeholder `appId` baked in. The second publish embeds the correct one (the manifest now holds the real `appId`). This is a known app-sdk ordering bug — the double-publish is the workaround, not optional.
+
 **What the CLI itself does** (`@hailer/app-sdk` publish.cjs): `--create` makes the app entry (`v3.app.create`) and writes the `appId` to the manifest; the bundle is packed (`package/` prefix) and POSTed to `/app/publish`; the server hosts it at `https://apps.hailer.com/{workspaceId}/{appId}/`.
 
 **What the CLI does NOT do:** icon, name/description updates, workspace sharing. Finish those after publishing: share with `manage_app({ action: 'add_member', appId, member: 'network_<wsId>' })`, and set an icon with `manage_app({ action: 'update', appId, image: <fileId> })` if wanted (icon files MUST be uploaded `isPublic: true`, PNG/JPEG only).

package/.claude/skills/hailer-app-builder/SKILL.md

@@ -12,6 +12,24 @@ triggers:
 
 Patterns and templates for building Hailer apps with @hailer/app-sdk.
 
+<build-philosophy>
+## How to Build Fast: Correct Data First, Theme Does the Looks
+
+The goal of the first version is **showing the correct data the user asked for** — not a custom-designed UI. Get the data right; the user iterates on looks afterward. Two rules make apps both fast and good:
+
+1. **Spend your effort on the data layer, because that's what's easy to get wrong.** Read the real field/phase/workflow IDs from `workspace/enums.ts` + `fields.ts` (never guess, never use labels as keys), fetch with the SDK, and read field values by ID. A dashboard that shows the *wrong* numbers beautifully is a failure; correct numbers in plain components is a success.
+
+2. **Do NOT hand-design UI or build a component library — the scaffold already installed the Hailer theme.** `main.tsx` wires `<ChakraProvider theme={hailerTheme}>`, so **every stock Chakra component is already on Hailer brand** (Nunito Sans, the full Hailer palette, light/dark via system) and there are **214 ready icons** in `src/hailer/theme/icons/`. Compose the UI from plain Chakra primitives — they look right for free:
+   - Layout: `Box`, `Flex`, `Grid`, `SimpleGrid`, `Stack`, `Container`
+   - Data: `Stat`/`StatLabel`/`StatNumber`/`StatHelpText` (stat cards), `Table`/`Thead`/`Tbody`/`Tr`/`Td`, `Card`/`CardHeader`/`CardBody`
+   - Text/state: `Heading`, `Text`, `Badge`, `Tag`, `Spinner`, `Skeleton`, `Alert`
+   - Import icons like `import { HailerSearch } from './hailer/theme/icons/HailerSearch'`
+
+   Don't write custom CSS, custom color values, or bespoke styled components on the first pass. Reach for a Chakra component; it's already themed. The user refines the look later — your job is correct data in a clean themed shell.
+
+3. **Always handle the three states** — loading (`Spinner`/`Skeleton`), empty (a `Text`, never a crash), and outside-Hailer (the app must render standalone — never block on `inside`). Real data is async; assume it's missing first.
+</build-philosophy>
+
 <critical-rules>
 ## CRITICAL: Scaffolding and Data Sources
 

package/CLAUDE.md

@@ -142,4 +142,6 @@ Load in sub-agents via the Skill tool. Never in main context.
 
 **Essential:** `/save`, `/handoff`, `/prd`, `/autoplan`, `/ws-pull`
 
-**Squads** (drive the native Workflow tool): `/app-squad "<desc>"`, `/review-squad [target]`, `/debug-squad "<bug>"`
+**Squads** (drive the native Workflow tool): `/review-squad [target]`, `/debug-squad "<bug>"`
+
+Build apps with a single agent + the `hailer-app-builder` / `create-and-publish-app` skills — faster than fanning out a squad (no shared-contract prep, no cross-agent integration fixups).

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@hailer/mcp",
-  "version": "2.0.0-beta.4",
+  "version": "2.0.0-beta.7",
   "config": {
     "docker": {
       "registry": "registry.gitlab.com/hailer-repos/hailer-mcp"

package/.claude/commands/app-squad.md

@@ -1,37 +0,0 @@
----
-description: Build a Hailer app with hyper-parallel component teams
-argument-hint: "app description"
-allowed-tools: Workflow, Bash, Read, Skill, Agent
----
-# App Squad
-
-Hyper-parallel app build: the orchestrator does ALL prep, then a Workflow fans out one agent per component with everything pre-loaded. Component agents do ZERO discovery — they just write code.
-
-**Goal:** $ARGUMENTS
-
-## Step 1: Prep (you, before the Workflow)
-
-- **Schema**: read `workspace/enums.ts` + relevant `workspace/<Name>_<id>/fields.ts`/`phases.ts` via a fast sub-agent (never in main context). Only if there's no `workspace/` dir, fall back to MCP `describe_workflows` (+ `include: ["schema","phases"]`).
-- **Scaffold**: `npx @hailer/create-app` — NEVER copy an existing app. (Apps are script-only — no MCP scaffold tool exists.)
-- **Read the scaffold SDK**: `src/hailer/use-app.ts` (store API), `src/main.tsx` (providers), `ls src/hailer/theme/icons/`. Read one working app from `apps/` for live SDK patterns.
-- **Skills**: load `hailer-app-builder` + `hailer-design-system` once; their content goes into the contract.
-
-## Step 2: Shared contract
-
-One document every agent receives verbatim: all workflow/field/phase IDs; the actual use-app.ts store shape and fetch patterns; helper functions; the component manifest (name, file path, props, renders what); exact import paths incl. icons; the working-app SDK patterns (**apps must render outside Hailer — never block on `inside`**); both skills' content.
-
-## Step 3: Workflow fan-out
-
-Author a Workflow script (this command is your opt-in to call the Workflow tool): `parallel()` over the component manifest — Shell (App.tsx: nav, state, fetching), Overview (dashboard), List (table: filters, sorting), Detail (modal), plus one per extra workflow. Each agent gets the full contract + its mission and returns ONLY complete TypeScript/React code as its final text.
-
-## Step 4: Assemble + verify (you)
-
-Write each component to its file, delete scaffold demo components, fix import/prop mismatches, then `npx tsc --noEmit` and `npx vite build`. Under ~5 errors: fix directly; structural failures: re-spawn that one agent with the error and contract.
-
-Report: path, component count, build/TS status, next steps (`cd apps/<name> && npm run dev`, test in the Hailer iframe).
-
-## Rules
-
-- NEVER copy existing apps — scaffold fresh
-- Agents never load skills or read files — you pre-load and paste
-- Include ACTUAL SDK code in the contract, not summaries