thinkwork-cli 0.12.11 → 0.12.15

package/dist/workspace-defaults/files/SPACE.md

@@ -0,0 +1,62 @@
+# SPACE.md - Shared Space Context
+
+Use this file for context that belongs to everyone working in this Space.
+`AGENTS.md` is the always-loaded map; this file is loaded through that map when
+the active turn is in this Space.
+
+Do not put secrets here. Enable tools, MCP servers, skills, and execution
+policy on the Agent or Agent Profiles. SPACE.md can mention which profile,
+skill, or tool should be used for a kind of work, but it does not grant that
+capability by itself.
+
+## Start Here
+
+- Read `CONTEXT.md` for the main workflow and operating context when this Space
+  has one.
+- Use attached folders such as `docs/`, `plans/`, `goals/`, and `artifacts/`
+  as source material when relevant.
+- Keep this file short. Link to detailed source files instead of duplicating
+  long-running procedures here.
+
+## Purpose
+
+Describe what this Space is for and when agents should rely on it.
+
+- Work this Space owns:
+- Work this Space does not own:
+- Current priority:
+
+## Working Context
+
+Capture durable facts, decisions, constraints, source links, and assumptions
+that should shape answers in this Space.
+
+- Current goal:
+- Important constraints:
+- Source of truth:
+- Recent decisions:
+
+## Key Files
+
+- `CONTEXT.md` - main workflow/context file.
+
+## Routing Notes
+
+Point agents toward the right Agent Profile, skill, or specialist workspace.
+These are instructions for routing and behavior, not capability grants.
+
+- Use @Analyst for finance, spreadsheet, and general-ledger analysis.
+- Use @Reviewer for review-only passes before shipping or publishing.
+- Use specific skills only when the selected Agent Profile exposes them.
+
+## Operating Agreements
+
+Record team preferences for this Space.
+
+- Ask before:
+- Act without asking when:
+- Report back with:
+
+## Open Questions
+
+-

package/dist/workspace-defaults/files/TOOLS.md

@@ -0,0 +1,65 @@
+---
+modelRouting: []
+---
+
+## Tool Usage Policy
+
+You have access to specialized tools. You MUST use them proactively:
+
+- **Never tell the user to search, check a website, or look something up themselves.** If you have a tool that can retrieve the information, use it.
+- **Always prefer tool-sourced answers** over training data for anything time-sensitive: current events, recent dates, prices, schedules, availability, weather, or any factual claim that may have changed since your training cutoff.
+- **When uncertain whether information is current**, use your tools to verify before responding.
+- **Call tools first, then respond.** Do not apologize for limitations you can overcome with a tool call.
+
+## Web Research Tool Choice
+
+- **Web Search** finds current results and candidate URLs. Use it for discovery and ordinary factual lookups.
+- **Web Extraction** reads one known public URL as clean page content. Use it after Web Search finds a promising URL, or when the user gives you a URL and asks you to read, summarize, analyze, or quote it.
+- **Browser Automation** is the heavyweight fallback for interaction: forms, clicks, auth flows, rendered-state inspection, multi-step browsing, or pages Web Extraction cannot read.
+- Do not create or install workspace skills to emulate these built-ins, and never write provider credentials or API keys into workspace files.
+
+## Workspace Orchestration
+
+- Use `delegate(task, context)` for short text-only specialist help that must finish in this turn.
+- Use `delegate_to_workspace(target, task)` for folder-scoped specialist work that must finish in this turn, when available.
+- Use `wake_workspace(target, request_md, ...)` for async folder-scoped work that can pause, wait on humans, or resume after another agent completes.
+- Do not hand-write files under `work/inbox/`, `review/`, `work/runs/*/events/`, `events/intents/`, or `events/audit/`; use the workspace orchestration tools so the platform can validate, order, and audit the write.
+
+## Model Routing
+
+The YAML frontmatter at the top of this file is the machine-readable tool policy
+contract. Use `modelRouting` to route a specific tool or capability to a
+different approved model for cost or latency reasons.
+
+This `TOOLS.md` contract is ThinkWork-native. It is not an external standard;
+the Pi runtime reads the frontmatter and enforces only the supported
+machine-readable keys.
+
+Example:
+
+```yaml
+modelRouting:
+  - tool: workspace_skill
+    match:
+      slug: financial-analysis
+    model: us.anthropic.claude-haiku-4-5-20251001-v1:0
+    reason: Use the cheaper model for the analyst subtask.
+```
+
+MCP servers route as the server-level `mcp` tool surface. Use `serverName` to
+target a configured MCP server; the runtime will still record the concrete MCP
+operation (`match.toolName`) that ran under the route.
+
+```yaml
+modelRouting:
+  - tool: mcp
+    match:
+      serverName: twenty-crm
+    model: us.anthropic.claude-haiku-4-5-20251001-v1:0
+    reason: Use the cheaper model for Twenty CRM MCP calls.
+```
+
+Routes layer by folder policy: agent root, active Space, active workspace, then
+user workspace. Higher-precedence files replace lower-precedence entries with
+the same `tool` and `match` signature. The runtime still validates that the
+selected model is approved for the user before a routed tool call runs.

package/dist/workspace-defaults/files/USER.md

@@ -0,0 +1,40 @@
+# USER.md - About Your Human
+
+- **Name:** {{HUMAN_NAME}}
+- **What to call them:** {{HUMAN_CALL_BY}}
+- **Pronouns:** {{HUMAN_PRONOUNS}}
+- **Timezone:** {{HUMAN_TIMEZONE}}
+- **Phone:** {{HUMAN_PHONE}}
+- **Notes:** {{HUMAN_NOTES}}
+
+## Family
+
+{{HUMAN_FAMILY}}
+
+## Context
+
+{{HUMAN_CONTEXT}}
+
+## How I work
+
+### Rhythms
+
+{{OPERATING_MODEL_RHYTHMS}}
+
+### Decisions
+
+{{OPERATING_MODEL_DECISIONS}}
+
+### Dependencies
+
+{{OPERATING_MODEL_DEPENDENCIES}}
+
+### ThinkWork Brain
+
+{{OPERATING_MODEL_KNOWLEDGE}}
+
+## Surfaces
+
+### Slack
+
+When I talk with you from Slack, treat Slack as a delivery surface for the selected shared Computer, not a separate identity. Use only the Slack thread, message, file references, and linked-user context the platform provides for the turn. Keep responses clear enough for a shared channel, and remember that the platform will add shared Computer and requester attribution when it posts back.

package/dist/workspace-defaults/files/mcp.json

@@ -0,0 +1,3 @@
+{
+  "directTools": []
+}

package/dist/workspace-defaults/files/memory/contacts.md

@@ -0,0 +1,13 @@
+# Contacts
+
+People you interact with on behalf of your human partner — colleagues,
+clients, vendors, family. Capture enough to be useful in future interactions
+(who they are, how they prefer to be addressed, context about the
+relationship) without writing a dossier.
+
+One contact per entry. Omit sensitive details (home addresses, private
+phone numbers) unless the human explicitly asks you to record them.
+
+## Contacts
+
+_(empty — add entries as you encounter them)_

package/dist/workspace-defaults/files/memory/lessons.md

@@ -0,0 +1,13 @@
+# Lessons
+
+Durable lessons from past interactions — what worked, what didn't, what you
+wish you'd known sooner. One lesson per bullet. Lead with the rule, then a
+short reason.
+
+Only add a lesson when you've learned something non-obvious that will change
+future behavior. Don't log every interaction — the automatic memory system
+already does that.
+
+## Lessons
+
+_(empty — add entries as you learn them)_

package/dist/workspace-defaults/files/memory/preferences.md

@@ -0,0 +1,12 @@
+# Preferences
+
+Your human partner's stated preferences — communication style, working hours,
+tone, formats they like, formats they don't. Update as you observe or as
+they tell you directly.
+
+One preference per bullet. Prefer concrete over abstract ("wants bullet
+summaries under 5 lines" beats "prefers concise responses").
+
+## Preferences
+
+_(empty — add entries as you learn them)_

package/dist/workspace-defaults/files/skills/.gitkeep

@@ -0,0 +1 @@
+

package/dist/workspace-defaults/files/skills/artifact-builder/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: artifact-builder
+description: Builds reusable ThinkWork Computer apps and interactive artifacts from research prompts. Use when the user asks to build, create, generate, or make a dashboard, app, report, briefing, workspace, or other interactive surface.
+---
+
+# Artifact Builder
+
+Use this skill when the user wants Computer to produce an interactive, reusable artifact. The expected output is a fast unsaved app preview first, not just a prose answer. Save only after the user explicitly asks to keep the preview.
+
+## Contract
+
+1. Research with the available tools and thread context.
+2. If live sources are missing or partial, keep going with the best available workspace, memory, context, web, or fixture data. Keep the visible app focused on the user's requested output; do not render provenance, source coverage, or recipe/refresh explainers unless the user explicitly asks for them.
+3. Keep app generation and saving in this parent turn. Do not use `delegate` or `delegate_to_workspace` to write, generate, or save the app.
+4. **Look up shadcn components on demand, not up front.** Draft the TSX in your head first — the small, focused set of components a typical dashboard or report needs (usually 5-8: `Card`, `Table`/`DataTable`, `Badge`, `Button`, `Tabs`, one chart, sometimes `Tooltip` or `Dialog`). Then call `get_component_source` (or `get_block`) only for the specific components you are about to render. Do not fan out `list_components`, `search_registry`, `get_component_source`, and `get_block` in parallel across many components before writing any TSX — that pattern wastes tool calls, slows the turn dramatically, and risks deadlocking the shadcn MCP server. Treat the shadcn MCP like a precision lookup, not a bulk registry crawl. If MCP is unavailable, use the compact local registry generated from `packages/ui/registry/generated-app-components.json` or the runtime `shadcn_registry` helper. If neither source is available, stop with a structured guidance error instead of emitting TSX.
+5. Generate TSX using approved shadcn-compatible primitives from `@thinkwork/ui` plus approved domain primitives from `@thinkwork/computer-stdlib`. You must use approved shadcn primitives for their roles. Hand-rolled replacements for cards, tabs, badges, buttons, tables, selects, form controls, dialogs, sheets, separators, tooltips, scroll areas, charts, or maps are rejected.
+6. Never embed Theme CSS, `<style>` tags, or app-owned theme objects in artifact metadata or TSX. App style is tenant-controlled host configuration. Build with semantic shadcn token classes and chart variables so the host-injected style controls the rendered iframe.
+7. Export a deterministic `refresh()` function whenever the result should be refreshable. Refresh must rerun saved source queries or deterministic transforms; it must not reinterpret the whole user request.
+8. Call `preview_app` before responding. Pass at least `name`, `files`, and `metadata`. Metadata must include `threadId`, `prompt`, `agentVersion`, `modelId`, `uiRegistryVersion`, `uiRegistryDigest`, and `shadcnMcpToolCalls` when available. Use `["local_registry_fallback"]` for `shadcnMcpToolCalls` when MCP was unavailable but the local registry was consulted.
+9. Call `save_app` only after the user explicitly asks to save or keep the preview. Save metadata must preserve the preview's registry, data-provenance, prompt, source, agent, and model metadata. It must not include theme CSS.
+10. After `preview_app` returns `ok`, answer concisely with what is ready to inspect. After `save_app` returns `ok`, answer concisely with what was saved and the `/artifacts/{appId}` route.
+11. Never use emoji as icons, status markers, bullets, tabs, headings, empty states, or data labels in generated apps. Use `lucide-react` named icon imports only when an icon materially improves scannability; otherwise use plain text, `Badge`, or approved registry components.
+
+## Host Chrome And Runtime
+
+The Computer host renders generated Apps inside host-provided Artifact chrome: title, `App` label, open-full action, refresh action placement, route header, iframe wrapper, and future provenance/version controls. Your TSX should render only the app body or canvas content.
+
+Do not create an outer artifact card, duplicate route header, `App` badge, "Open full" button, refresh recipe, source coverage, evidence, or provenance panel unless the user explicitly asks for that in the app body.
+
+Generated Apps run in the sandboxed iframe runtime for both preview and save. Do not assume access to parent app globals, credentials, cookies, local storage, window navigation, network, dynamic imports, or browser APIs outside the supported stdlib surface.
+
+## App Shape
+
+Use `App.tsx` as the main file. Export one default React component. Prefer concise component-local data transforms over large abstractions. Do not use network calls, browser globals, dynamic imports, `eval`, or raw HTML injection.
+
+## Component System
+
+Generated dashboards must look like ThinkWork product UI, not raw HTML. The shadcn registry is the source of truth for approved generated-app components, examples, roles, and substitutions. Import structure and controls from `@thinkwork/ui`: `Card`, `CardHeader`, `CardTitle`, `CardDescription`, `CardContent`, `Badge`, `Button`, `Tabs`, `TabsList`, `TabsTrigger`, `TabsContent`, `Table`, `TableHeader`, `TableBody`, `TableRow`, `TableHead`, `TableCell`, `Select`, `Checkbox`, `Switch`, `Tooltip`, `Dialog`, `Sheet`, `ScrollArea`, `Separator`, `ChartContainer`, `Combobox`, and `DropdownMenu` where applicable.
+
+Use `@thinkwork/computer-stdlib` for semantic dashboard primitives such as `AppHeader`, `KpiStrip`, `BarChart`, `StackedBarChart`, `DataTable`, `MapView`, and formatters. It is fine to combine stdlib charts with `@thinkwork/ui` layout chrome.
+
+Use shadcn semantic tokens, not one-off colors: `bg-background`, `text-foreground`, `bg-card`, `text-card-foreground`, `border-border`, `text-muted-foreground`, `bg-muted`, `text-primary`, `text-destructive`, and chart colors from `var(--chart-1)` through `var(--chart-5)`. User-uploaded shadcn Create Theme CSS is injected by the host from tenant app style settings; do not paste a `<style>` tag or theme metadata into `App.tsx`.
+
+Do not use emoji icons. Use `lucide-react` named icon imports only when an icon materially improves scannability; otherwise use plain text, `Badge`, or approved registry components.
+
+Do not create adjacent plain text tabs, raw `<button>` controls, raw `<table>` layouts for tabular data, raw form controls, inline-pill badges, chart wrappers outside `ChartContainer`, or bespoke card CSS. Tabs must use `Tabs`/`TabsList`/`TabsTrigger`; data grids must use `DataTable` or `Table`; status labels must use `Badge`; general metric panels may use `Card` or `KpiStrip`; charts must use the approved chart surface; maps must use `MapView`.
+
+For CRM, sales, pipeline, opportunity, account-risk, stage-exposure, stale-activity, or LastMile dashboards, top-level KPIs must use `KpiStrip` from `@thinkwork/computer-stdlib`. Do not hand-compose KPI metrics as individual full-width `Card` components, do not stack KPI cards vertically, and do not rely on generated `grid-cols-*` or responsive `md:grid-cols-*` Tailwind layout classes for the core dashboard structure. Use compiled stdlib primitives for the dashboard shape and reserve `Card` for chart, table, or detail sections.
+
+Good apps include:
+
+- Focused body content that starts at the useful work, not wrapper chrome.
+- `KpiStrip` for CRM dashboard key totals.
+- Charts or tables that make comparison easy.
+- Empty, partial, and failed-source states proportional to the requested task.
+
+Dashboard apps must be dashboard-shaped, not prose-only markdown reports. Do not save a dashboard artifact that is primarily a prose report, markdown summary, or stack of text-only cards. A useful dashboard should show at least one meaningful visual comparison through a chart, table, map, timeline, or other structured UI surface.
+
+## Maps
+
+When the user asks for a map (locations, regions, routes, geographic comparisons), use `MapView` from `@thinkwork/computer-stdlib`. **Do NOT embed an OpenStreetMap.org iframe, do NOT roll your own `react-leaflet` `<MapContainer>`, and do NOT enable `scrollWheelZoom` — `MapView` handles the tile provider, theming, default-icon bundler fix, and scroll-trap defaults correctly.** It uses Mapbox tiles when `VITE_MAPBOX_PUBLIC_TOKEN` is set (light/dark style swap from `useTheme`) and falls back to OpenStreetMap tiles when unset.
+
+Pass `fit` (one of `{type: "country", code: "<ISO-3166-1-alpha-2>"}`, `{type: "bbox", bounds: [[lat,lng],[lat,lng]]}`, or `{type: "auto"}`) plus optional `markers`, `polylines`, and `geojson` arrays. See `@thinkwork/computer-stdlib/MapView` for the full prop shape.
+
+## Preview And Save
+
+The first useful result should be an unsaved preview. `preview_app` validates and renders the same TSX payload shape that `save_app` persists later, using the same generated-app policy. Do not save every preview as a durable artifact row.
+
+Use only real available data, partial real data, or honest empty states. Do not invent CRM accounts, customers, metrics, events, opportunities, locations, or evidence to make a preview look complete. Missing or partial inputs should produce a runnable app with proportional empty states and concise limitations.
+
+When the user asks to save, promote the preview by calling `save_app` with the same files and provenance metadata. Include the preview's `uiRegistryVersion`, `uiRegistryDigest`, and `shadcnMcpToolCalls` or `["local_registry_fallback"]` so the saved artifact records which shadcn registry source shaped the TSX.
+
+## Composing With Domain Skills
+
+Domain skills like `crm-dashboard`, `research-dashboard`, and `map-artifact` add their own layout, component, and data-shape guidance on top of this skill. When one of them is in play, follow its guidance for layout, top-level KPIs, chart choices, and data shape — and use this skill only for the artifact mechanics (component lookups, `preview_app`, `save_app`, validation, registry policy). Do not duplicate or override the domain skill's structure with a generic dashboard layout.
+
+## Missing Data
+
+Missing data is not a reason to stop before creating the preview. Create a runnable app that handles gaps gracefully, then ask for source setup, approval, or save confirmation as a follow-up when needed.

package/dist/workspace-defaults/files/skills/artifact-builder/references/crm-dashboard.md

@@ -0,0 +1,166 @@
+# CRM Dashboard Recipe
+
+Use this reference when the user asks for a CRM, sales pipeline, opportunity, account-risk, stage-exposure, stale-activity, or LastMile dashboard app.
+
+This file is retained as the Artifact Builder compatibility reference. The published `crm-dashboard` runbook owns orchestration and phase sequencing; this reference supplies the dashboard data shape, artifact layout, refresh contract, and `save_app` metadata for legacy prompts or active runbook produce phases.
+
+The goal is a saved, reusable app. Do not stop at analysis prose. Normalize the available data first, generate the app source second, then call `save_app` directly.
+
+The quality bar is an operational CRM dashboard, not a formatted report. The app should resemble a dense LastMile-style sales dashboard: compact header and source/status badges, KPI strip, visual pipeline/risk comparisons, sortable or scannable entity rows, and restrained color accents for value, risk, stale activity, and success.
+
+Do not use emoji as icons, status markers, bullets, tab labels, headings, empty states, or data values. When an icon is useful, import it from `lucide-react`; otherwise use plain text or styled badges.
+
+## Source Discovery
+
+Use the best sources available in this order:
+
+1. Thread context and any attached or already retrieved CRM rows.
+2. Available CRM, connector, MCP, context, workspace, memory, or Hindsight tools.
+3. Email, calendar, and web context when the prompt asks for stale activity, next meetings, or external account risk.
+4. A small demo or fixture-shaped dataset only when live sources are missing. Make limitations visible only when they materially affect the displayed result.
+
+Missing live data is not a blocker. The app should still run and should stay focused on the requested dashboard rather than rendering provenance panels.
+
+## Canonical Data Shape
+
+Normalize source results into `CrmDashboardData` before writing TSX. Keep this shape stable even when some arrays are empty.
+
+    type SourceStatus = "success" | "partial" | "failed";
+    type RiskLevel = "high" | "medium" | "low";
+
+    interface CrmDashboardData {
+      snapshot: {
+        title: string;
+        summary: string;
+        generatedAt: string;
+        accountFilter?: string;
+      };
+      kpis: Array<{
+        id: string;
+        label: string;
+        value: string;
+        detail?: string;
+        tone?: "default" | "risk" | "success";
+      }>;
+      stageExposure: Array<{
+        label: string;
+        value: number;
+        count: number;
+      }>;
+      staleActivity: Array<{
+        label: string;
+        value: number;
+        count: number;
+      }>;
+      topRisks: Array<{
+        id: string;
+        opportunity: string;
+        account: string;
+        stage: string;
+        amount: number;
+        lastActivity?: string;
+        risk: RiskLevel;
+        reason: string;
+        nextStep?: string;
+      }>;
+      opportunities: Array<{
+        id?: string;
+        opportunity: string;
+        account: string;
+        stage: string;
+        amount: number;
+        owner?: string;
+        closeDate?: string;
+        lastActivity?: string;
+        risk?: RiskLevel;
+      }>;
+      refreshNote?: string;
+    }
+
+## App Layout
+
+Build one responsive app that fits the available horizontal space with `w-full min-w-0 max-w-[1280px]`. Do not create horizontal page scrolling. Prefer stacked or wrapped layouts on narrow widths.
+
+The host already provides Artifact chrome, including the route title, `App` label, full-screen action, refresh action placement, and sandboxed iframe wrapper. Render the dashboard body only; do not add a duplicate app shell, route header, evidence panel, source coverage panel, or refresh recipe unless the user explicitly requests it.
+
+Required sections:
+
+- Body intro or context row only when it helps interpret the dashboard.
+- KPIs: total pipeline, high-risk exposure, stale opportunity count, and next-meeting or source-health count when available.
+- Stage exposure: a bar chart or stacked bar chart from `stageExposure`.
+- Stale activity: a chart or compact table from `staleActivity`.
+- Top risks: a ranked table or compact list from `topRisks`, sorted by risk and exposure.
+- Opportunities: a sortable/scannable table from `opportunities`.
+
+Use shadcn-compatible primitives from `@thinkwork/ui` for layout and controls: `Card`, `CardHeader`, `CardTitle`, `CardDescription`, `CardContent`, `Badge`, `Button`, `Tabs`, `TabsList`, `TabsTrigger`, `TabsContent`, `Table`, `TableHeader`, `TableBody`, `TableRow`, `TableHead`, `TableCell`, `ScrollArea`, and `Separator` where applicable.
+
+Use `@thinkwork/computer-stdlib` primitives where they fit: `AppHeader`, `KpiStrip`, `BarChart`, `StackedBarChart`, `DataTable`, and formatters such as `formatCurrency`.
+
+Theme requirements:
+
+- Do not preserve Theme CSS in artifact metadata. Shadcn Create Theme CSS is tenant app style controlled by the host renderer.
+- Use semantic shadcn token classes and chart variables: `bg-background`, `text-foreground`, `bg-card`, `text-card-foreground`, `border-border`, `text-muted-foreground`, `bg-muted`, and `var(--chart-1)` through `var(--chart-5)`.
+- Do not paste a `<style>` tag into `App.tsx`, hard-code black chart marks on dark surfaces, or invent a separate palette that fights the uploaded theme.
+
+Do not hand-roll cards, tabs, badges, buttons, or tables. Tabs must use `Tabs`/`TabsList`/`TabsTrigger`; tabular data must use `DataTable` or `Table`; status labels must use `Badge`; top-level KPIs must use `KpiStrip` from `@thinkwork/computer-stdlib`. Use `Card` for chart, table, or detail sections, not as a substitute for the KPI strip.
+
+Do not create a vertical stack of full-width KPI cards. Do not rely on generated `grid-cols-*` or responsive `md:grid-cols-*` Tailwind classes for the core dashboard layout; those classes may not exist in the iframe CSS bundle. Use the compiled stdlib primitives (`KpiStrip`, `BarChart`, `StackedBarChart`, `DataTable`) for dashboard structure.
+
+Do not use emoji icons. Use `lucide-react` icons when an icon is needed.
+
+Use the stdlib prop names directly:
+
+- `KpiStrip` receives `cards={data.kpis}`.
+- `DataTable` receives `columns={...}` and `rows={data.opportunities}`.
+- `BarChart` receives `data={data.stageExposure}` or `data={data.staleActivity}`.
+
+Before saving, reject the draft and revise it if any of these are true:
+
+- The app reads like a markdown report or prose summary.
+- Core metrics are shown as paragraphs instead of visual comparisons.
+- It lacks a KPI strip, chart, or table.
+- Top-level KPIs are hand-composed as individual metric `Card` components.
+- The core dashboard layout depends on `grid-cols-*` or responsive `md:grid-cols-*` class names.
+- It uses emoji characters for icons or labels.
+- It duplicates host chrome such as an outer artifact frame, `App` badge, open-full control, or refresh controls supplied by the host.
+
+## Empty And Partial States
+
+If no CRM opportunities are available, still save a runnable app. Show empty KPI values, an empty table, and a concise empty state.
+
+If CRM rows exist but email, calendar, or web signals are missing, keep the CRM sections populated. Do not add source coverage or evidence panels.
+
+Never hide uncertainty, but keep it proportional: use a short note near the affected metric only when it changes how the user should read the dashboard.
+
+## Refresh Contract
+
+Export `refresh()` when the dashboard can be refreshed. It must return deterministic data shaped like this:
+
+    export async function refresh() {
+      return {
+        data: refreshedCrmDashboardData,
+        sourceStatuses: { crm: "success" },
+      };
+    }
+
+Refresh should rerun saved source queries or deterministic transforms. It must not reinterpret the whole prompt or create a different app.
+
+The artifact host renders refresh actions in its top-bar actions menu. Do not render a refresh control, refresh timeline, recipe explainer, or `RefreshBar` inside the app unless the user explicitly asks for a custom in-artifact refresh experience.
+
+## Save Contract
+
+Call `save_app` directly after generating the files. Do not delegate saving to another agent or tool.
+
+Use:
+
+- `name`: a concise user-facing dashboard name.
+- `files`: at least `App.tsx` with default export and `refresh()`.
+- `metadata.kind`: `computer_applet`.
+- `metadata.threadId`: current thread id when available.
+- `metadata.prompt`: the user prompt.
+- `metadata.recipe`: `crm-dashboard`.
+- `metadata.recipeVersion`: `1`.
+- `metadata.dataShape`: `CrmDashboardData`.
+- Do not include theme CSS or app-owned theme objects in metadata.
+
+Only tell the user the artifact exists after `save_app` returns `ok`, `persisted`, and an `appId`. Link to `/artifacts/{appId}`.

package/dist/workspace-defaults/files/skills/automation-loop-designer/SKILL.md

@@ -0,0 +1,120 @@
+---
+name: automation-loop-designer
+description: Design a ThinkWork Automation from a prompt by interviewing for goal, Space, trigger, verification, judge settings, stop guards, and privacy boundaries, then emit a reviewable AutomationDraft.
+license: MIT
+metadata:
+  adaptedFrom: https://github.com/ksimback/looper
+  adaptedFromLicense: MIT
+  adaptedFromAuthor: Kevin Simback
+---
+
+# Automation Loop Designer
+
+Use this skill when a user wants to create, improve, or review a ThinkWork
+Automation. The output is a reviewable `AutomationDraft` for ThinkWork's durable
+Automation runtime. Do not emit a Looper Python runner, Claude slash command,
+or file-scaffolded external loop unless the user explicitly asks for a separate
+portable design artifact.
+
+This skill adapts design-coaching ideas from Kevin Simback's Looper
+(`https://github.com/ksimback/looper`, MIT license): coached goals, typed
+verification, review gates, stop guards, state/logging visibility, and explicit
+privacy boundaries. ThinkWork remains the orchestrator.
+
+## Interview Flow
+
+Ask only the questions needed to make the draft reviewable. Prefer one compact
+question at a time when the user's intent is unclear.
+
+1. Goal: what outcome should exist after each run?
+2. Space: where should the execution thread live?
+3. Trigger: manual, schedule, API, webhook, app event, or future workflow.
+4. Verification: what evidence proves the run is good enough?
+5. Judge: self-check, human approval, model judge, reviewer agent, eval
+   threshold, or external callback.
+6. Control: max iterations, runtime/token/budget caps, no-progress stops, and
+   failure behavior.
+7. Privacy: which external systems or humans may see the prompt, evidence, or
+   review context.
+
+## Design Rules
+
+- Treat the user's prompt as the Automation's main artifact. Do not bury it
+  behind internal AgentLoop jargon.
+- If a crisp done state exists, write concrete `goal.completionCriteria` and
+  matching `judge.criteria`.
+- If the goal is useful but not yet crisply checkable, set
+  `source.goalInference` to `runtime_inferred` and include a plain-language
+  note about what should be clarified later.
+- Prefer programmatic checks when the Automation naturally has measurable
+  outputs. Use judge or human checks for qualitative work.
+- Keep reviewer and judge roles distinct. A reviewer gives notes; a judge
+  returns a verdict.
+- Require at least two stop guards for recurring work: an iteration/runtime cap
+  and a no-progress or budget stop.
+- Name the execution boundary. For ThinkWork v1 this is usually one selected
+  Space plus a first-class thread created by the Automation run.
+- Do not ask the user to select a worker agent in v1. Use the main ThinkWork
+  Agent unless an operator is in Advanced mode.
+
+## AutomationDraft Shape
+
+Return a JSON object with this shape when the user is ready to review:
+
+```json
+{
+  "name": "Readable Automation name",
+  "prompt": "The instruction the Automation will run",
+  "space": {
+    "id": "selected-space-id-or-null",
+    "name": "selected Space name or requested Space"
+  },
+  "trigger": {
+    "family": "manual",
+    "scheduleExpression": null,
+    "timezone": "UTC"
+  },
+  "goal": {
+    "objective": "Normalized objective",
+    "completionCriteria": ["Concrete criterion, if known"]
+  },
+  "judge": {
+    "mode": "self_check",
+    "criteria": ["Criterion the judge can inspect"]
+  },
+  "policy": {
+    "maxIterations": 1,
+    "maxRuntimeMinutes": 30,
+    "maxTokens": 100000,
+    "failBehavior": "return_blocker"
+  },
+  "source": {
+    "creationMode": "chat",
+    "goalInference": "explicit",
+    "designerSkill": "automation-loop-designer"
+  }
+}
+```
+
+If the draft uses runtime-inferred criteria, keep the Automation valid by
+including a fallback completion criterion in the review summary:
+
+```text
+The agent produces a useful response or next step for the automation prompt.
+```
+
+## Review Summary
+
+Before the Automation is saved, summarize:
+
+- Prompt
+- Space
+- Trigger
+- Done condition or runtime-inferred fallback
+- Judge mode
+- Stop guards
+- Privacy or external context notes
+
+Ask for explicit confirmation before save. After confirmation, the host system
+will persist the draft through ThinkWork's Automation save path and link this
+builder thread as setup history.