@hailer/mcp 1.2.1 → 1.3.10

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

@@ -1,280 +0,0 @@
----
-name: publish-hailer-app
-description: Guide for publishing Hailer apps to production
-version: 1.3.0
-triggers:
-  - publish app
-  - deploy app
-  - production app
----
-
-# Publish Hailer App Skill
-
-Guide for publishing Hailer apps to production using MCP tools.
-
-<warning>
-## ⚠️ Publishing Requires Explicit User Request
-
-**Default is local development** — scaffold creates a dev app at `http://localhost:3000` automatically.
-
-**Only use this skill when the user explicitly asks to publish or deploy to production.**
-
-Before publishing: validate manifest.json (see below), then `publish_hailer_app` (auto-updates URL to production).
-</warning>
-
-<critical>
-## MANDATORY: Validate Before Publishing
-
-The `publish_hailer_app` tool will SILENTLY FAIL if manifest.json is misconfigured.
-
-**YOU MUST validate these before calling publish_hailer_app:**
-
-1. Read `public/manifest.json` in the project
-2. Check `appId` exists and is 24 characters
-3. Check `version` exists and is NOT empty (e.g., "1.0.0")
-4. Check `versionDescription` exists and is NOT empty
-
-If ANY are missing/empty, FIX THEM FIRST before publishing.
-</critical>
-
-<validation-code>
-## Validation Steps (DO THIS FIRST)
-
-```
-1. Read({file_path: "{projectDir}/public/manifest.json"})
-
-2. Verify JSON contains:
-   - "appId": "24-char-id"        ← If missing: use create_app first
-   - "version": "1.0.0"           ← If empty: set to "1.0.0"
-   - "versionDescription": "..."  ← If empty: set to "Initial release"
-
-3. If any field missing/empty → Edit manifest.json to fix
-
-4. ONLY THEN call publish_hailer_app
-```
-</validation-code>
-
-<workflow>
-## Full Publishing Workflow
-
-### Step 1: Validate & Fix manifest.json
-
-Read the manifest:
-```javascript
-Read({file_path: "{projectDir}/public/manifest.json"})
-```
-
-Required structure:
-```json
-{
-  "appId": "695816e2ba1d8bef3af7e018",
-  "version": "1.0.0",
-  "versionDescription": "Initial production release"
-}
-```
-
-**If appId missing:** Add the ID from Step 2
-**If version empty:** Set to "1.0.0"
-**If versionDescription empty:** Set to "Initial release"
-
-### Step 2: Publish
-
-```javascript
-publish_hailer_app({
-  projectDirectory: "/path/to/app"
-})
-```
-
-This does everything in one call:
-- **Auto-derives app name** from project directory (e.g., `upcoming-matches` → "Upcoming Matches")
-- **Auto-sets description** from `versionDescription` in manifest.json
-- **Auto-generates and uploads a colored icon** with initials (e.g., green "UM" circle)
-- **Auto-shares** with the entire workspace
-- Copies manifest.json into dist/
-- Creates .tgz with `package/` prefix (matches npm pack format)
-- Uploads to S3 via POST /app/publish
-- **Auto-updates app URL** to `https://apps.hailer.com/{workspaceId}/{appId}/`
-
-No manual `update_app` calls needed after publish — name, description, icon, and sharing are all automatic.
-
-### Step 3: Verify
-
-```javascript
-list_apps()
-```
-Confirm URL is `https://apps.hailer.com/...` (not localhost).
-</workflow>
-
-<silent-failure>
-## Why Silent Failures Happen
-
-The SDK publish script requires `version` and `versionDescription` in manifest.json.
-If missing/empty, the tool returns "Success" but files are NOT uploaded.
-
-**Symptoms of silent failure:**
-- Tool says "App Published Successfully!"
-- But app URL is still `http://localhost:3000`
-- Or production URL returns 403/404
-
-**Always validate manifest BEFORE publishing.**
-</silent-failure>
-
-<dev-vs-prod>
-## Dev vs Production Apps
-
-| Type | URL | Created By | Purpose |
-|------|-----|------------|---------|
-| Dev | `http://localhost:3000` | `scaffold_hailer_app` (reuses existing) | Local development, always stays at localhost |
-| Prod | `https://apps.hailer.com/{workspaceId}/{appId}/` | `publish_hailer_app` (auto-created) | Published production app |
-
-**Flow:**
-1. `scaffold_hailer_app` checks for existing dev app at localhost:3000 — reuses it instead of creating duplicates
-2. Dev app stays at localhost forever — it's your development slot
-3. When user says "publish": `publish_hailer_app` detects the dev app URL, auto-creates a NEW production app with:
-   - Name derived from project directory (e.g., `upcoming-matches` → "Upcoming Matches")
-   - Description from `versionDescription` in manifest.json
-   - Colored icon with initials (auto-generated, uploaded as public)
-   - Shared with entire workspace
-   - URL pointing to production CDN
-
-**No manual `update_app` or `create_app` needed.** The publish tool handles name, description, icon, sharing, and URL automatically.
-</dev-vs-prod>
-
-<updating>
-## Updating Published Apps
-
-1. Bump version in manifest.json:
-```json
-{
-  "version": "1.0.1",
-  "versionDescription": "Fixed data loading bug"
-}
-```
-
-2. Publish:
-```javascript
-publish_hailer_app({
-  projectDirectory: "/path/to/app"
-})
-```
-
-New version replaces old at same URL.
-
-**Marketplace apps:** If `manifest.json` contains a `targetId`, the publish automatically updates the marketplace listing version too. No separate `publish_app` call needed for version updates.
-</updating>
-
-<marketplace>
-## Marketplace Publishing
-
-**Two different things:**
-1. **App publish** (`publish_hailer_app`) — uploads files to CDN, updates app URL. If manifest has `targetId`, also updates the marketplace version.
-2. **Marketplace metadata** (`publish_app`) — updates title, description, icon, images on the marketplace listing. Does NOT upload app files.
-
-**First-time marketplace publish:**
-1. Publish app with `publish_hailer_app` — server returns a `targetId`, auto-saved to manifest
-2. Create marketplace listing with `publish_app` using `versionId` (= targetId from manifest)
-3. Note the `productId` returned — that's the marketplace listing ID (different from targetId)
-
-**Updating marketplace version:**
-Just run `publish_hailer_app` — if manifest has `targetId`, the marketplace version updates automatically.
-
-**Updating marketplace metadata (description, icon, images):**
-Use `publish_app` with `productId` (the marketplace listing ID, NOT the targetId).
-
-**Key IDs:**
-| ID | What | Where |
-|----|------|-------|
-| `appId` | The app itself | manifest.json `appId` |
-| `targetId` | Version entry for marketplace | manifest.json `targetId` |
-| `productId` | Marketplace listing | Returned by first `publish_app` call, find via `list_templates` |
-</marketplace>
-
-<sharing>
-## Sharing Apps
-
-Workspace sharing is automatic on first publish. For manual sharing:
-
-```javascript
-// Entire workspace
-add_app_member({ appId: "...", member: "network_{workspaceId}" })
-
-// Team
-add_app_member({ appId: "...", member: "team_{teamId}" })
-
-// User
-add_app_member({ appId: "...", member: "user_{userId}" })
-```
-</sharing>
-
-<gotchas>
-## Gotchas
-
-**App icons MUST be uploaded with `isPublic: true`.**
-Files uploaded without this flag are private — the Hailer frontend can't load them and shows a broken/transparent image. The publish tool handles this automatically, but if you manually upload an icon via `upload_files`, always include `isPublic: true`:
-```javascript
-upload_files({ files: [{ path: "/tmp/icon.png", isPublic: true }] })
-```
-
-**SVG images don't work as app icons.**
-Hailer's backend image pipeline uses sharp for resizing and doesn't serve SVGs correctly. Always use PNG or JPEG.
-
-**Don't use SVG gradients in icon generation.**
-Sharp's `flatten()` with SVG `linearGradient` produces transparency. Use `sharp.create()` with solid RGB background + composite for text.
-</gotchas>
-
-<vite-config>
-## CRITICAL: Vite Base Path
-
-Vite apps MUST have `base: './'` in vite.config.ts for production deployment.
-
-```typescript
-// vite.config.ts
-export default defineConfig({
-  base: './',  // REQUIRED for production
-  // ... other config
-});
-```
-
-**Without this:**
-- Asset paths resolve to root domain instead of app folder
-- Production app returns 403/404 errors
-- Works in localhost but fails in production
-
-**Also verify:** The .tgz package must have files at `package/dist/` path structure.
-</vite-config>
-
-<cache-busting>
-## CRITICAL: Browser Cache for Published Apps
-
-Published Hailer apps serve stale versions from browser cache. Vite's hashed JS/CSS filenames handle asset cache-busting, but `index.html` itself needs no-cache headers.
-
-**Add these meta tags to `index.html` `<head>` before publishing:**
-
-```html
-<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate" />
-<meta http-equiv="Pragma" content="no-cache" />
-<meta http-equiv="Expires" content="0" />
-```
-
-**Without these:**
-- Users see old app version after publish
-- Hard refresh (Ctrl+Shift+R) works but users won't know to do it
-- Particularly bad for bug fix deploys where users expect changes immediately
-
-**Why meta tags not server headers?**
-Hailer apps are served from `apps.hailer.com` static hosting - we can't control server headers. Meta tags are the only client-side cache control available.
-</cache-busting>
-
-<checklist>
-## Pre-Publish Checklist
-
-- [ ] manifest.json `appId` is 24 chars (dev app ID is fine — publish auto-creates prod app)
-- [ ] manifest.json `version` is set (e.g., "1.0.0")
-- [ ] manifest.json `versionDescription` is set (not empty — also used as app description)
-- [ ] vite.config.ts has `base: './'`
-- [ ] index.html has no-cache meta tags (see cache-busting section)
-- [ ] node_modules exists (dependencies installed)
-- [ ] After publish: verify URL auto-updated to production format (check with `list_apps`)
-
-**Automatic on first publish** (no action needed): app name, description, colored icon, workspace sharing.
-</checklist>

package/dist/CLAUDE.md

@@ -1,370 +0,0 @@
-# Hailer SDK
-
-MCP tools for Hailer workspaces: workflows, activities, insights, and apps.
-
-<quick-start>
-## Quick Start (New Project Setup)
-
-```bash
-npm init @hailer/sdk              # Scaffold project with workspace/ config
-npm run pull                      # Pull latest workflow schemas from Hailer
-npm run generate                  # Generate TypeScript types
-```
-
-Then ask Claude Code to build features. It delegates to specialized agents automatically.
-Run `/help` for an overview, or `/help:agents`, `/help:skills`, `/help:commands` for details.
-</quick-start>
-
----
-
-<identity>
-You are the orchestrator. You delegate tasks to specialized agents, run commands from their responses, and summarize results for users.
-
-Always delegate - agents have optimized tools and context for their domains.
-</identity>
-
-<orchestrator-rules>
-DO DIRECTLY: Answer from context, summarize agent results, run push/sync commands
-DELEGATE TO AGENTS: Everything else. No exceptions.
-
-**FEATURE REQUESTS:** Before implementing, ask "Want me to create a PRD first?" Only skip if user declines or already used `/prd`/`/autoplan`.
-
-**NEVER USE BUILT-IN AGENTS:** Do not spawn Plan, Explore, general-purpose, or Bash subagents. These are Claude Code built-ins that lack specialized skills and tools. Instead:
-- Give the executing agent a prompt that includes research + planning + execution
-- Agents have the Skill tool — they can load patterns themselves
-- E.g., instead of "Plan agent researches templates → Ingrid implements", just tell Ingrid: "Load SDK-document-templates skill, plan the template structure, then build it"
-
-**ANTI-PATTERNS (never do these):**
-- "Let me use Plan agent to research first..." → Include research in the agent's prompt
-- "I'll use Explore to find the code..." → Use Glob/Grep directly, or include in agent prompt
-- "I'll just quickly read this file..." → Delegate to the appropriate agent
-- "Let me check this one field..." → Delegate to Kenji
-- "I can create this simple activity..." → Delegate to Dmitri
-- "This is a small change..." → Delegate to the appropriate agent
-- "User gave detailed plan, so I'll skip PRD..." → Still ask about PRD
-
-**CRITICAL ROUTING RULE — Kenji vs Giuseppe:**
-- **Kenji** = Hailer workspace data ONLY (workspace/ files, MCP API queries, field IDs, schemas)
-- **Giuseppe** = App source code (apps/, src/, .tsx/.ts files, API call bugs, UI fixes, debugging)
-- NEVER send app source code tasks to Kenji. He reads workspace/ config, not app code.
-- For app bugs/fixes: Giuseppe (complex) or Simple Writer (simple string/ID fixes)
-
-**MULTI-AGENT WORK:** Prefer squads over manual agent chaining. If a task needs 2+ agents in sequence (e.g., Helga → Alejandro → Viktor), check if a squad already does it (`/help:commands`). For large-scale repetitive work across many items, use `/swarm` instead of looping agents yourself.
-
-Agents return JSON. You interpret it for the user.
-</orchestrator-rules>
-
-<delegation-blocks>
-## When Hook Blocks You
-
-Hooks enforce delegation by blocking certain direct tool calls. When blocked:
-
-**1. Default: Delegate (recommended)**
-The block message shows the suggested agent. Use it:
-```
-Task(subagent_type="agent-kenji-data-reader", prompt='{"task":"..."}')
-```
-
-**2. Override: Ask user permission first**
-If context suggests user wants direct action, ask:
-```
-AskUserQuestion:
-  question: "Hook wants me to delegate reading workspace/fields.ts to Kenji. Read directly instead?"
-  options:
-    - "Delegate to Kenji (recommended)"
-    - "Read directly this once"
-```
-
-**3. If user approves direct action:**
-1. Run the bypass command shown in block message (writes one-time bypass file)
-2. Retry the original tool call
-3. Bypass auto-deletes after one use
-
-**CRITICAL: NEVER bypass without explicitly asking user.**
-
-**Blocked tools:**
-- `Read` on `workspace/` → Kenji
-- `Glob`/`Grep` code searches → include in appropriate agent's prompt
-- `mcp__hailer__*` tools → appropriate agent (Kenji, Dmitri, Viktor, etc.)
-</delegation-blocks>
-
-<agent-routing>
-## Quick Routing
-
-| Category | Agent |
-|----------|-------|
-| Read workspace/ data, schemas, IDs | **Kenji** |
-| Read/fix/debug app or integration source code | **Giuseppe** or **Simple Writer** |
-| Write activities | **Dmitri** |
-| Workflows, fields, phases | **Helga** |
-| Calculated fields + name functions | **Alejandro** |
-| SQL insights | **Viktor** |
-| Build apps, fix app bugs, debug API calls | **Giuseppe** |
-| App UI/UX design specs | **UI Designer** |
-| Demo/mockup apps (no Hailer connection) | **Marco** |
-| Document templates (PDF/CSV) | **Ingrid** |
-| Activity movers (phase cascades) | **Igor** |
-| Monolith automations (webhooks, scheduled jobs) | **Ivan** |
-| Zapier integrations | **Zara** |
-| Tests (vitest, playwright, build checks) | **Tanya** |
-| Code review (bugs, security, best practices) | **Svetlana** |
-| LSP inspection (dead code, unused imports) | **Lars** |
-| Basic edits (ID swaps, string replacements) | **Simple Writer** |
-| Code simplification and cleanup | **Code Simplifier** |
-| API endpoint documentation | **Marcus** |
-| MCP tool development | **Gunther** |
-| Discussions (read, post, membership) | **Yevgeni** |
-| App permissions (grant/revoke access) | **Permissions Handler** |
-| Skill creation and agent updates | **Ada** |
-| New agent creation | **Builder** |
-| Marketplace publishing | **Marketplace Publisher** |
-| Marketplace PR review | **Marketplace Reviewer** |
-| Web research | **Web Search** |
-| Config audit (CLAUDE.md, hooks, agents) | **Bjorn** |
-
-Ambiguous routing? Load `delegation-routing` skill or run `/help:agents`.
-</agent-routing>
-
-<skill-system>
-## Skill System
-
-Skills are reusable knowledge files (`.claude/skills/<name>/SKILL.md`) that give agents domain-specific patterns, API references, and code templates. They keep agent definitions lean while providing deep expertise on demand.
-
-**Two types of skill loading:**
-
-**1. Auto-injected (no action needed):** Agents declare core skills in their frontmatter `skills:` field. The `SubagentStart` hook (`skill-injector.cjs`) reads the list, loads each `SKILL.md` from `.claude/skills/<name>/`, and injects it as `additionalContext` when the agent spawns.
-
-**2. On-demand (include in prompt):** For specialized tasks, tell the agent to load an extra skill via Skill tool. Only 6 agents have the Skill tool: Giuseppe, Helga, Viktor, Alejandro, Ingrid, Ada.
-
-| Agent | Task pattern | Add to prompt |
-|-------|-------------|---------------|
-| **Giuseppe** | Images, pictures, photos | `Load the hailer-apps-pictures skill.` |
-| **Giuseppe** | Publishing, deploy to prod | `Load the publish-hailer-app skill.` |
-| **Giuseppe** | REST API, direct HTTP calls | `Load the hailer-rest-api skill.` |
-| **Viktor** | JOIN, cross-workflow, linked data | `Load the insight-join-patterns skill.` |
-| **Viktor** | Field config, phases, workspace | `Load the SDK-ws-config-skill skill.` |
-| **Alejandro** | Field config, phases, workspace | `Load the SDK-ws-config-skill skill.` |
-| **Ingrid** | Field config, phases, workspace | `Load the SDK-ws-config-skill skill.` |
-
-**Adding core skills to an agent:**
-```yaml
-# In .claude/agents/agent-name.md frontmatter
-skills:
-  - SDK-ws-config-skill
-  - SDK-generate-skill
-```
-</skill-system>
-
-<task-usage>
-## Task Usage
-
-**Rule: 2+ agents or 3+ steps = create tasks.** Mark in_progress before starting, completed when done.
-
-Examples that need tasks:
-- "Apply these 4 learnings" → 4 tasks
-- "Run review squad" → 1 task per agent + 1 for fixes
-- "Build feature from PRD" → task per implementation step
-
-Skip tasks for: single-agent dispatch, quick lookups, simple edits
-</task-usage>
-
-<background-agents>
-## Background Execution
-
-All agents support `run_in_background: true`. Use it proactively for tasks that take a while (full test suites, multi-file reviews, deep research, app scaffolding). Tell the user "Running X in background" and keep working. Check results via `Read` on the `output_file` path or `TaskOutput(task_id, block=false)`. Multiple agents can run in background simultaneously.
-</background-agents>
-
-<error-detection-skills>
-## Error Detection Skills
-
-Load these skills when you detect common agent failure patterns:
-
-| Trigger | Load Skill |
-|---------|------------|
-| MCP validation fails ("Required" errors, empty receivedArgs) | `tool-parameter-usage` |
-| Agent returns success but tool actually failed | `tool-response-verification` |
-| Empty array/string errors in optional parameters | `optional-parameters` |
-| Agent outputs prose after JSON closing brace | `json-only-output` |
-
-These help you detect and correct issues before reporting to user.
-</error-detection-skills>
-
-<push-commands>
-When agents return `"status": "ready_to_push"`:
-```json
-{ "status": "ready_to_push", "commands": ["npm run fields-push"], "summary": "..." }
-```
-
-YOU run these commands via Bash tool. This triggers safety hooks.
-Do NOT ask user to run them manually.
-</push-commands>
-
-<needs-confirmation>
-When agents return `"status": "needs_confirmation"`:
-1. AskUserQuestion to confirm
-2. If yes: run the `safe_command` from result
-3. If no: report cancellation
-</needs-confirmation>
-
----
-
-<local-first>
-**Why local-first?** Workspace files are instant, free, and contain all structural data (IDs, field types, phases). API calls are slow, rate-limited, and only needed for live activity data. Always check workspace/ BEFORE API calls.
-
-```
-workspace/
-├── workflows.ts, enums.ts, teams.ts, groups.ts
-└── [Workflow]_[id]/
-    ├── fields.ts
-    └── phases.ts
-```
-
-LOCAL: Workflow/field/phase IDs, field types, labels, options
-API: Activity data, counts, discussion messages
-
-REFRESH: `npm run pull`
-</local-first>
-
-<hooks>
-## Hooks
-
-26 CJS hooks in `.claude/hooks/` wired via `settings.json`. Each receives JSON on stdin, returns `{"decision": "allow"}` or `{"decision": "block", "message": "..."}` on stdout.
-
-Key events: `SessionStart` (auto-loads context), `PreToolUse` (guards + delegation enforcement), `PostToolUse` (linting, logging, failure detection), `SubagentStart` (skill injection).
-
-**If hooks break after `npm install`:** Check `.claude/settings.json` paths, test with `node .claude/hooks/<script>.cjs --help`, or run `/clear-defaults`.
-
-PROTECTED (hooks confirm): npm run push, *-push, *-sync | SAFE: npm run pull, npm run generate
-</hooks>
-
-<app-development>
-## App Development Rules
-
-**Default: Local development.** Scaffold creates a dev app at `http://localhost:3000` automatically. Run `npm run dev` and test inside Hailer iframe.
-
-**Publishing: Only when user explicitly asks.** Tell Giuseppe to load the `publish-hailer-app` skill. It handles manifest validation, `publish_hailer_app` upload, and `update_app` to switch URL to production.
-
-**Builder mode for Giuseppe:** The `app-edit-guard` hook blocks file edits in `apps/` unless builder mode is active. Before spawning Giuseppe directly, run:
-```bash
-node .claude/hooks/app-edit-guard.cjs --agent-on
-```
-After Giuseppe completes:
-```bash
-node .claude/hooks/app-edit-guard.cjs --agent-off
-```
-The `/app-squad` command handles this automatically.
-</app-development>
-
----
-
-<session-protocol>
-## Session Protocol
-
-### Starting a Session
-SessionStart hook auto-loads SESSION-HANDOFF.md + DEVELOPMENT.md into context.
-1. Review auto-loaded context, update handoff (remove completed items)
-2. If handoff has "Pending Tasks" → recreate with `TaskCreate`
-3. If no DEVELOPMENT.md → offer to create one
-4. Briefly confirm current state before diving in
-
-### During a Session
-- **Feature request:** Ask "Want me to create a PRD?" even if user provides detailed plan. Only skip if user explicitly declines or already used `/prd`/`/autoplan`.
-- **Tasks:** 2+ agents or 3+ steps = create tasks. Mark in_progress before starting, completed when done. If it won't be done this session, put it in DEVELOPMENT.md backlog.
-- **Learnings:** Use `/learn <cat> <desc>` to capture gotchas and patterns.
-
-### Ending a Session
-- **Completion:** Update DEVELOPMENT.md + PRD status. Offer code-simplifier after features.
-- **Context full:** Update handoff, tell user to run `/handoff`.
-- **When to update DEVELOPMENT.md:** After features/milestones, architecture decisions, or discovering technical constraints.
-
-### Planning Workflow
-1. **Big picture → DEVELOPMENT.md** — Purpose, stack, roadmap linking to PRDs
-2. **Feature details → PRDs** (`docs/prd-*.md`) — One per feature, links back to roadmap
-3. **Implementation → Pick a PRD and build** — Use `/yolo` for autonomous execution
-
-**Quick start:** `/autoplan "description"` creates DEVELOPMENT.md + PRDs automatically.
-</session-protocol>
-
-<file-templates>
-## Documentation Hierarchy
-
-| File | Purpose |
-|------|---------|
-| **DEVELOPMENT.md** | Project status, backlog, tech stack, roadmap |
-| **docs/prd-*.md** | Feature requirements and implementation steps |
-| **SESSION-HANDOFF.md** | Current work, next steps, key context |
-
-**DEVELOPMENT.md** has sections: What This Project Does, Roadmap (linking PRDs), Current Status, Known Issues, Technical Decisions.
-**SESSION-HANDOFF.md** has sections: Current Work, Next Steps, Context.
-</file-templates>
-
-<customization>
-**Creating agents:** Load `agent-structure` skill for template.
-**Modify:** Edit `.claude/agents/*.md`
-**Disable:** Move to `docs/agents/`
-</customization>
-
-<config-source>
-## Config Source
-
-Agents, skills, hooks, and commands are in `.claude/` (project-local).
-Update from config repo: `cd ~/hailer-claude-config && git pull`, then copy to project.
-Learnings: `~/hailer-claude-config/inbox/`
-</config-source>
-
-<commands>
-## Commands
-
-**Syntax:** `/command <param>` (angle brackets = required). `/help:topic` (colon = subtopic).
-
-**Essential:** `/save`, `/handoff`, `/prd`, `/autoplan`, `/yolo`, `/ws-pull`, `/learn`
-
-**Squads** (multi-agent workflows):
-
-| Squad | Agents | Use for |
-|-------|--------|---------|
-| `/app-squad` | Kenji → Designer → Giuseppe → Tanya | Build apps end-to-end |
-| `/review-squad` | Svetlana + Lars + Tanya | Code review with auto-fix |
-| `/config-squad` | Helga → Alejandro → Viktor | Workflow + fields + insights |
-| `/hotfix-squad` | Tanya → Simple Writer → Svetlana | Quick bug fixes |
-| `/debug-squad` | Kenji + Viktor + Svetlana + Tanya | Parallel investigation |
-| `/swarm <desc>` | Auto-selected | Large-scale parallel work |
-
-More squads + full command list: `/help:commands`
-</commands>
-
-<directory>
-## Project Structure
-
-```
-workspace/           # Hailer config - check FIRST for IDs
-apps/                # Frontend apps
-integrations/        # Backend services
-.claude/             # Agents, hooks, skills, commands (project-local)
-DEVELOPMENT.md       # Project status
-```
-</directory>
-
-<sdk-gotchas>
-## Hailer SDK Quick Reference
-
-Common pitfalls that cause debugging loops - check these FIRST:
-
-| Gotcha | Correct | Wrong |
-|--------|---------|-------|
-| Activity field updates | `{type: "string", value: "x"}` wrapper | Raw value `"x"` |
-| `linkedfrom` in isolated-vm | Does NOT work - use ActivityLink field instead | Trying cross-link resolution |
-| Code in isolated-vm | Plain JavaScript only | TypeScript syntax (`as`, type annotations) |
-| Phase transitions | Exact string: `"Uudet"` → `"Tehty"` | Guessed names |
-| Field IDs | Read from workspace/ files | Guessing from labels |
-| Dropdown values | `{data: [{value, label}]}` | `{options: [...]}` |
-| ActivityLink format | Plain string array of workflow IDs | Nested objects |
-
-**Rule:** When touching Hailer fields, ALWAYS read workspace/ first via Kenji. Never guess IDs or formats.
-</sdk-gotchas>
-
-<bulk-operations>
-## Bulk Tasks
-
-For repetitive edits, use `/swarm` or headless mode (`claude -p "..." --allowedTools "Edit,Read,Grep,Glob"`). Act first — grep to find instances, then edit immediately.
-</bulk-operations>

package/dist/agents/bot-manager.d.ts

@@ -1,48 +0,0 @@
-/**
- * Multi-Bot Client Manager
- * Manages multiple bot clients, each with their own Hailer connection
- */
-import { HailerClient } from "../mcp/hailer-clients";
-import { SignalHandler } from "../mcp/signal-handler";
-import { BotClientConfig } from "./shared/types";
-import { WorkspaceCache } from "../mcp/workspace-cache";
-export interface BotClient {
-    userId: string;
-    firstName: string;
-    lastName: string;
-    config: BotClientConfig;
-    client: HailerClient;
-    signalHandler: SignalHandler;
-    workspaceCache?: WorkspaceCache;
-}
-export declare class MultiBotManager {
-    private botConfigs;
-    private botClients;
-    constructor(botConfigs: BotClientConfig[]);
-    initializeAllHailerClientsFromConfig(): Promise<void>;
-    getBotClient(userId: string): BotClient | undefined;
-    getAllBotClients(): BotClient[];
-    getBotIds(): string[];
-    private userNameCache;
-    private static USER_CACHE_TTL;
-    /**
-     * Look up a user's full name by their user ID
-     * Uses workspace cache first, then falls back to socket API call
-     */
-    getUserName(userId: string): string | undefined;
-    /**
-     * Initialize a single bot client from credentials
-     * Used for dynamic bot creation from AI Hub
-     */
-    initializeBotClient(email: string, password: string, apiKey: string): Promise<string>;
-    /**
-     * Remove and disconnect a bot client
-     */
-    removeBotClient(userId: string): Promise<void>;
-    /**
-     * Get bot client by bot ID (hal, giuseppe, hailerExpert, vastuullisuus)
-     */
-    getBotClientByBotId(botId: string): BotClient | undefined;
-    shutdown(): Promise<void>;
-}
-//# sourceMappingURL=bot-manager.d.ts.map