@zibby/skills 0.1.33 → 0.1.35

package/docs/packages/mcp-cli.md

@@ -22,17 +22,17 @@ A Model Context Protocol (MCP) server that exposes the Zibby CLI surface — dep
 | `zibby_logout` | Clears the saved session. |
 | `zibby_status` | Who is logged in, how many projects are cached, whether the session is still valid. |
 | `zibby_list_projects` | List the Zibby projects the user has access to. |
-| `zibby_list_templates` | List official workflow templates (browser-test-automation, code-analysis, generate-test-cases, …). |
-| `zibby_scaffold_workflow` | Scaffold `.zibby/workflows/<name>/` from an official template. |
-| `zibby_validate_workflow` | Static-check a local workflow (~30 ms, no API call). |
-| `zibby_list_workflows` | List workflows: local, remote, or both. |
-| `zibby_deploy_workflow` | Deploy a local workflow to a project. |
-| `zibby_trigger_workflow` | Trigger a deployed workflow by UUID. Returns `jobId`. |
-| `zibby_workflow_logs` | Fetch the latest N log lines from a run (one-shot — call again for newer lines). |
-| `zibby_run_workflow_local` | Run a workflow on the user's machine one-shot, for debugging. No cloud. |
-| `zibby_download_workflow` | Pull a deployed workflow back to local. Requires explicit `confirm: true` from the agent. |
-
-**Destructive operations are intentionally not exposed.** Workflow deletion, env-var mutation, schedule changes, and credential management stay in the `zibby` CLI directly. The agent has to involve the user out-of-band for those.
+| `zibby_list_templates` | List official agent templates (browser-test-automation, code-analysis, generate-test-cases, …). |
+| `zibby_scaffold_agent` | Scaffold `.zibby/workflows/<name>/` from an official template. |
+| `zibby_validate_agent` | Static-check a local agent (~30 ms, no API call). |
+| `zibby_list_agents` | List agents: local, remote, or both. |
+| `zibby_deploy_agent` | Deploy a local agent to a project. |
+| `zibby_trigger_agent` | Trigger a deployed agent by UUID. Returns `jobId`. |
+| `zibby_agent_logs` | Fetch the latest N log lines from a run (one-shot — call again for newer lines). |
+| `zibby_run_agent_local` | Run an agent on the user's machine one-shot, for debugging. No cloud. |
+| `zibby_download_agent` | Pull a deployed agent back to local. Requires explicit `confirm: true` from the agent. |
+
+**Destructive operations are intentionally not exposed.** Agent deletion, env-var mutation, schedule changes, and credential management stay in the `zibby` CLI directly. The agent has to involve the user out-of-band for those.
 
 ## Install
 
@@ -128,14 +128,14 @@ If your agent on Windows can't find `npx`, wrap with `cmd /c`:
 ```
 User:  Deploy the browser-test template to my "playhouse" project.
 Agent: → zibby_list_projects
-       → zibby_scaffold_workflow (browser-test-automation → .zibby/workflows/playhouse-tests/)
-       → zibby_validate_workflow
-       → zibby_deploy_workflow
+       → zibby_scaffold_agent (browser-test-automation → .zibby/workflows/playhouse-tests/)
+       → zibby_validate_agent
+       → zibby_deploy_agent
        → "Deployed v1 of playhouse-tests. UUID 988…"
 
 User:  Run it against staging.zibby.dev.
-Agent: → zibby_trigger_workflow (input: { url: "https://staging.zibby.dev" })
-       → zibby_workflow_logs (lines: 200, jobId: "abc-123")
+Agent: → zibby_trigger_agent (input: { url: "https://staging.zibby.dev" })
+       → zibby_agent_logs (lines: 200, jobId: "abc-123")
        → "Run completed. Found 0 errors."
 ```
 
@@ -144,7 +144,7 @@ Agent: → zibby_trigger_workflow (input: { url: "https://staging.zibby.dev" })
 Two-stage by design (mirrors how the `zibby` CLI works):
 
 1. **Session token** (`zibby_login`) — device-code OAuth via browser. Identifies the user.
-2. **Per-project API tokens** — fetched at login time and cached locally. The MCP server picks the right token automatically when you call a project-scoped tool like `zibby_deploy_workflow`.
+2. **Per-project API tokens** — fetched at login time and cached locally. The MCP server picks the right token automatically when you call a project-scoped tool like `zibby_deploy_agent`.
 
 All credentials live in `~/.zibby/config.json` (mode `0600`). The same file `zibby login` writes — so if you've already done `zibby login` from a terminal, the MCP server picks up that session.
 
@@ -156,7 +156,7 @@ The user's password never touches the MCP server: login is OAuth in the browser,
 - **Minimum env passthrough** — only `HOME`, `USER`, `PATH`, and the project-scoped `ZIBBY_API_KEY` reach the child CLI process.
 - **API tokens never returned to the agent** — they live in `~/.zibby/config.json` only, read server-side per call.
 - **Destructive ops excluded** — see the table above.
-- **`zibby_download_workflow` requires `confirm: true`** — the schema rejects calls without it. Agents must explicitly opt in after confirming the destination path with the user.
+- **`zibby_download_agent` requires `confirm: true`** — the schema rejects calls without it. Agents must explicitly opt in after confirming the destination path with the user.
 
 ## Troubleshooting
 

package/docs/packages/skills.md

@@ -17,7 +17,7 @@ npm install @zibby/skills
 
 ## What Are Skills?
 
-A **skill** is a declarative description of an MCP (Model Context Protocol) server and the tools it exposes. Skills are the bridge between your workflow nodes and external capabilities like browser automation, Jira, GitHub, Slack, and test memory.
+A **skill** is a declarative description of an MCP (Model Context Protocol) server and the tools it exposes. Skills are the bridge between your agent nodes and external capabilities like browser automation, Jira, GitHub, Slack, and test memory.
 
 Skills are **agent-agnostic** — the same skill definition works across Cursor, Claude, and Codex. The framework resolves the skill into the right MCP configuration for whichever agent is active.
 
@@ -46,7 +46,7 @@ export const executeLiveNode = {
 };
 ```
 
-When the workflow runs:
+When the agent runs:
 1. The framework reads the node's `skills` array
 2. For each skill, calls `skill.resolve()` to get the MCP server config
 3. Injects the resolved MCP server into the agent's environment

package/docs/packages/ui-memory.md

@@ -51,7 +51,7 @@ zibby memory init
 
 Creates `.zibby/memory/.dolt/` with the schema for runs, selectors, page model, navigation, and insights.
 
-### 3. Enable memory in your workflow
+### 3. Enable memory in your agent
 
 Add `SKILLS.MEMORY` to any node that should have memory access:
 

package/docs/recipes/bug-autofix.md

@@ -78,7 +78,7 @@ Plus the children's own config: Jira connected (triage/poll/writeback), GitHub c
 ## Deploy
 
 ```bash
-zibby agent templates                         # browse the marketplace (zibby workflow templates still works)
+zibby agent templates                         # browse the marketplace
 zibby agent new bug-autofix -t bug-autofix    # scaffold the orchestrator
 # ...also scaffold + deploy ticket-triage, code-fix, tracker-writeback in the same project
 zibby agent deploy bug-autofix

package/docs/recipes/index.md

@@ -5,9 +5,9 @@ title: Agent Marketplace
 
 # Agent Marketplace
 
-Zibby ships a set of **ready-made agents** — production-ready automations you can deploy today. Each one is a real Zibby agent (a workflow graph under the hood), eating its own dog food. Browse them, deploy with one command, and tune them to your project.
+Zibby ships a set of **ready-made agents** — production-ready automations you can deploy today. Each one is a real Zibby agent, eating its own dog food. Browse them, deploy with one command, and tune them to your project.
 
-> **"Agent" is the product noun** for a deployed automation. The CLI / SDK / API still speak "workflow" — the CLI command is `zibby agent` (`zibby workflow` still works as an alias), the package is `@zibby/agent-workflow`.
+> An **Agent** is a deployed automation built on coding-agent CLIs. Build and ship one with the `zibby agent` CLI.
 
 ```
                        ┌──────────────────┐
@@ -53,7 +53,7 @@ Three reasons we ship ready-made agents alongside the platform:
 If you have an agent you'd want shipped as a built-in:
 
 ```bash
-zibby agent new my-agent          # scaffold (zibby workflow new still works)
+zibby agent new my-agent          # scaffold
 # ... build it out ...
 zibby agent run my-agent          # test locally
 zibby agent deploy my-agent       # ship to your cloud account

package/docs/recipes/pipeline-supervisor.md

@@ -11,7 +11,7 @@ v1 is strictly **READ → PROPOSE → NOTIFY**. It never edits another agent's g
 
 ```
 scan_pipelines        (deterministic + Zibby REST API, PAT-authed)
-   → propose_improvements (LLM — one proposal per flagged pipeline)
+   → propose_improvements (LLM — one proposal per flagged agent)
    → notify               (LLM + SKILLS.CHAT_NOTIFY — one review card)
 ```
 
@@ -21,7 +21,7 @@ If `scan_pipelines` flags nothing, the graph short-circuits straight to `notify`
 
 A direct authed `GET /executions?projectId=<id>&limit=200` against the Zibby REST API (the same route the dashboard and remote MCP server use), carrying a **user personal access token** in `Authorization: Bearer`.
 
-It must be a USER PAT (`zby_pat_…`), **not** the Fargate-injected `PROJECT_API_TOKEN`: every cross-pipeline read route requires a `userId` from the authorizer, and a project token carries none — so it 401s.
+It must be a USER PAT (`zby_pat_…`), **not** the Fargate-injected `PROJECT_API_TOKEN`: every cross-agent read route requires a `userId` from the authorizer, and a project token carries none — so it 401s.
 
 ## Config (ENV tab)
 
@@ -40,9 +40,9 @@ Optional:
 | Field | Default | Meaning |
 |---|---|---|
 | `lookbackHours` | 24 | Hours of execution history to scan |
-| `minFailRate` | 0.4 | Flag a pipeline failing ≥ this fraction of recent runs |
+| `minFailRate` | 0.4 | Flag an agent failing ≥ this fraction of recent runs |
 | `targetWorkflowTypes` | — | Optional name filter (case-insensitive substring) |
-| `maxPipelines` | 25 | Cap on distinct pipelines analyzed per run |
+| `maxPipelines` | 25 | Cap on distinct agents analyzed per run |
 
 ## Trigger
 

package/docs/recipes/sentry-triage.md

@@ -5,7 +5,7 @@ title: Sentry triage recipe
 
 # `sentry-triage` — agent-driven Sentry triage
 
-An hourly Sentry triage workflow that fetches unresolved issues, classifies them by severity, and **routes them to the right human**. Three nodes, end-to-end agent-driven, deployed from the marketplace in one click.
+An hourly Sentry triage agent that fetches unresolved issues, classifies them by severity, and **routes them to the right human**. Three nodes, end-to-end agent-driven, deployed from the marketplace in one click.
 
 ```
 fetch_issues  →  classify  →  dispatch_alerts
@@ -27,12 +27,12 @@ The agent uses [`slack_lookup_user_by_email`](../skills/slack), [`slack_list_use
 ## Deploy from the marketplace
 
 ```bash
-zibby workflow templates deploy sentry-triage --project <project-id>
+zibby agent templates deploy sentry-triage --project <project-id>
 ```
 
 Or via the dashboard: `/marketplace/workflows` → Sentry Triage → Deploy.
 
-After deploy, configure ENV (Apps → workflow → ENV tab):
+After deploy, configure ENV (Apps → agent → ENV tab):
 
 | Env var | Required? | Default | What it does |
 |---|---|---|---|
@@ -79,15 +79,15 @@ If you deployed your backend with `RELEASE_SHA` Sentry release-tracking on, susp
 Each node's prompt lives in its own module — fork the template, edit, redeploy:
 
 ```bash
-zibby workflow download <uuid>
+zibby agent download <uuid>
 # edit nodes/dispatch-node.js
-zibby workflow deploy ./sentry-triage   # same UUID, new version
+zibby agent deploy ./sentry-triage   # same UUID, new version
 ```
 
 Or fork the whole template repo if you want long-term divergence — it's just a `@zibby/workflow-templates/sentry-triage/` directory in the published package.
 
 ## Cadence
 
-Default: hourly cron, fires `sinceMinutes=60`. Change in the trigger config (Apps → workflow → Triggers) — keep the SQL safe `since` between 5 and 1440 minutes (`inputSchema` enforces this).
+Default: hourly cron, fires `sinceMinutes=60`. Change in the trigger config (Apps → agent → Triggers) — keep the SQL safe `since` between 5 and 1440 minutes (`inputSchema` enforces this).
 
-→ Next: [`zibby test`](./test) (the browser-testing recipe) or [Build your own workflow](../get-started/your-first-workflow).
+→ Next: [`zibby test`](./test) (the browser-testing recipe) or [Build your own agent](../get-started/your-first-workflow).

package/docs/recipes/test.md

@@ -7,7 +7,7 @@ title: Browser test recipe (zibby test)
 
 The browser-test recipe takes a plain-English spec, drives a real browser via a coding agent (Cursor / Claude / Codex / Gemini), runs the assertions, and produces a Playwright script + verification video.
 
-It's a worked example of what the Zibby platform does — every step is a regular workflow node with Zod-validated handoff. You can read the source, fork it, or build your own variation.
+It's a worked example of what the Zibby platform does — every step is a regular agent node with Zod-validated handoff. You can read the source, fork it, or build your own variation.
 
 ## Quick start
 
@@ -38,7 +38,7 @@ zibby test test-specs/checkout.txt --agent claude
 
 Open the session in [Zibby Studio](https://zibby.app/studio) to scrub through the run, swap the prompt, re-execute any node.
 
-## The graph (this is just a Zibby workflow)
+## The graph (this is just a Zibby agent)
 
 Under the hood, `zibby test` is a 3-node graph:
 
@@ -115,10 +115,10 @@ Auto-pull on test start, auto-push on test pass. Failing runs don't pollute team
 
 ## Forking the recipe
 
-If the built-in recipe doesn't fit your case, scaffold a custom workflow and copy the structure:
+If the built-in recipe doesn't fit your case, scaffold a custom agent and copy the structure:
 
 ```bash
-zibby workflow new my-test-pipeline
+zibby agent new my-test-agent
 ```
 
 Then in `graph.mjs`, define your own nodes:
@@ -170,7 +170,7 @@ That's the platform. The recipe is just a starter.
     npx @zibby/cli test test-specs/checkout.txt --headless
 ```
 
-For workflows triggered remotely (rather than per-CI-run), use [`workflow trigger`](../cloud/triggering) on a deployed graph.
+For agents triggered remotely (rather than per-CI-run), use [`agent trigger`](../cloud/triggering) on a deployed graph.
 
 ## Why this is different from Playwright codegen / a basic LLM script
 
@@ -187,4 +187,4 @@ For workflows triggered remotely (rather than per-CI-run), use [`workflow trigge
 
 - [Recipes overview](./)
 - [Concepts: graph](../concepts/graph) — the primitives this recipe uses
-- [Cloud triggering](../cloud/triggering) — fire workflows from CI/CD
+- [Cloud triggering](../cloud/triggering) — fire agents from CI/CD

package/docs/skills/browser.md

@@ -5,7 +5,7 @@ title: Browser
 
 # Browser skill
 
-Playwright-driven browser automation. Click, type, navigate, snapshot, record video. Used by `zibby test` and by any workflow node that needs to drive a web UI.
+Playwright-driven browser automation. Click, type, navigate, snapshot, record video. Used by `zibby test` and by any agent node that needs to drive a web UI.
 
 - **ID:** `browser`
 - **MCP server:** `playwright` (tools exposed as `mcp__playwright__*`)
@@ -45,7 +45,7 @@ npm install @zibby/mcp-browser
 
 Override the bin path with `MCP_BROWSER_PATH` if you need to point at a local checkout.
 
-## Use in a workflow
+## Use in an agent
 
 ```js
 import { WorkflowAgent, WorkflowGraph } from '@zibby/core';

package/docs/skills/chat-memory.md

@@ -72,7 +72,7 @@ Turn `infer` on when you want mem0 to consolidate noisy inputs into clean facts;
 
 On Zibby Cloud, mem0 state **persists across Fargate tasks**. mem0's SQLite vector + history stores are rooted under the workspace's tenant-scoped `.zibby/memory/` tree, which is tarball-synced between executions — so a memory written in one run is recallable in the next, even though each run is a fresh, ephemeral container. mem0 user IDs are workspace-scoped (`workspace:<name>`, overridable via `ZIBBY_MEMORY_USER_ID`), keeping each project's memory isolated.
 
-## Use in a workflow
+## Use in an agent
 
 ```js
 import { WorkflowAgent, WorkflowGraph } from '@zibby/core';

package/docs/skills/core-tools.md

@@ -27,7 +27,7 @@ Most Claude/Cursor/Codex nodes get these tools by default from their agent strat
 
 None. The skill has no env keys, no auth, no external dependencies.
 
-## Use in a workflow
+## Use in an agent
 
 ```js
 import { WorkflowAgent, WorkflowGraph } from '@zibby/core';

package/docs/skills/function-skill.md

@@ -34,7 +34,7 @@ export const myTool = skill('my_tool', {
 
 Calling `skill()` both creates and **registers** the skill in the global registry, so just importing the module is enough to make it available.
 
-## Use in a workflow
+## Use in an agent
 
 Once registered, reference by id:
 

package/docs/skills/github.md

@@ -37,11 +37,11 @@ Two options:
 
 **GitHub App (recommended).** In **Settings → Integrations**, click **Connect GitHub**, install the Zibby GitHub App on the orgs/repos you want, and authorize. Tokens auto-refresh; you don't manage them. See the [GitHub Integration page](../integrations/github.md) for the full app permissions list.
 
-**Personal access token.** Set `GITHUB_TOKEN` in your workflow's env (locally) or via **Cloud → Env vars** (cloud runs). Scope `repo` for private read+write, `public_repo` for public-only.
+**Personal access token.** Set `GITHUB_TOKEN` in your agent's env (locally) or via **Cloud → Env vars** (cloud runs). Scope `repo` for private read+write, `public_repo` for public-only.
 
 The skill reads `envKeys: ['GITHUB_TOKEN']` and the official `@modelcontextprotocol/server-github` consumes it directly.
 
-## Use in a workflow
+## Use in an agent
 
 ```js
 import { WorkflowAgent, WorkflowGraph } from '@zibby/core';

package/docs/skills/index.md

@@ -20,7 +20,7 @@ Per-skill reference for everything shipped in `@zibby/skills`. For the mental mo
 | [Jira](./jira.md) | `jira` | Issues, sprints, comments, transitions | Atlassian OAuth |
 | Linear | `linear` | `linear_list_issues`, `linear_get_issue`, `linear_add_comment`, `linear_update_state`, `linear_list_teams/states/labels` | `LINEAR_API_KEY` |
 | Plane | `plane` | Projects, work items, cycles, modules, epics, comments (official MCP) | `PLANE_API_KEY` (+ `PLANE_WORKSPACE_SLUG`, `PLANE_BASE_URL`) |
-| Notion | n/a | Not an attachable MCP skill — a [connectable integration](../integrations/notion.md). Workflows publish a `report` object to Notion blocks (`reportToNotionBlocks`), e.g. the `notify-notion` template | OAuth (dashboard) / `NOTION_API_KEY` (SDK) |
+| Notion | n/a | Not an attachable MCP skill — a [connectable integration](../integrations/notion.md). Agents publish a `report` object to Notion blocks (`reportToNotionBlocks`), e.g. the `notify-notion` template | OAuth (dashboard) / `NOTION_API_KEY` (SDK) |
 | [Memory](./memory.md) | `memory` | Test history, selectors, page model (Dolt) | `zibby init --mem` |
 | [Chat memory](./chat-memory.md) | `chat-memory` | `memory_store`, `memory_recall`, `memory_brief`, `task_log`, `task_history` | None (Dolt or mem0) |
 | [Core tools](./core-tools.md) | `core-tools` | `read_file`, `write_file`, `list_directory`, `run_command`, `open_url`, `wait` | None |

package/docs/skills/jira.md

@@ -40,7 +40,7 @@ See the [Jira Integration page](../integrations/jira.md) for the user-facing set
 
 Under the hood the bin reads `ATLASSIAN_ACCESS_TOKEN` + `ATLASSIAN_CLOUD_ID` (and optional `ATLASSIAN_INSTANCE_URL`), which the backend supplies through `resolveIntegrationToken('jira')`.
 
-## Use in a workflow
+## Use in an agent
 
 ```js
 import { WorkflowAgent, WorkflowGraph } from '@zibby/core';

package/docs/skills/lark.md

@@ -30,7 +30,7 @@ Lark bots authenticate with App ID + App Secret. The bot needs `im:message` and
 
 For self-hosted Lark deployments, set `host` on the integration config; the default is the standard Feishu host.
 
-## Use in a workflow
+## Use in an agent
 
 ```js
 import { WorkflowAgent, WorkflowGraph } from '@zibby/core';

package/docs/skills/memory.md

@@ -30,7 +30,7 @@ Requires [Dolt](https://docs.dolthub.com/introduction/installation) and an initi
 ```bash
 # macOS
 brew install dolt
-# then, in your workflow workspace:
+# then, in your agent workspace:
 zibby init --mem
 ```
 
@@ -40,7 +40,7 @@ Override the bin location for development with `MCP_MEMORY_PATH`.
 
 See [Tests → Memory](../tests/memory.md) for the full memory lifecycle.
 
-## Use in a workflow
+## Use in an agent
 
 ```js
 import { WorkflowAgent, WorkflowGraph } from '@zibby/core';

package/docs/skills/sentry.md

@@ -29,7 +29,7 @@ Sentry uses OAuth 2.0 with PKCE (public client — no client secret).
 
 The backend (`/integrations/sentry/connect` and `/integrations/sentry/callback`) handles the PKCE exchange. Tokens auto-refresh on use; if refresh fails, click **Reconnect** in the same settings panel.
 
-## Use in a workflow
+## Use in an agent
 
 ```js
 import { WorkflowAgent, WorkflowGraph } from '@zibby/core';

package/docs/skills/slack.md

@@ -31,7 +31,7 @@ Slack uses a bot token + workspace team id.
 1. Create (or reuse) a Slack app at [api.slack.com/apps](https://api.slack.com/apps).
 2. Add Bot Token Scopes: `chat:write`, `channels:read`, `channels:history`, `groups:read`, `users:read`, `reactions:write` (minimum).
 3. Install the app to your workspace; copy the **Bot User OAuth Token** (`xoxb-…`) and **Team ID**.
-4. Set them on the workflow's env (locally) or via **Cloud → Env vars**:
+4. Set them on the agent's env (locally) or via **Cloud → Env vars**:
 
 ```bash
 SLACK_BOT_TOKEN=xoxb-...
@@ -40,7 +40,7 @@ SLACK_TEAM_ID=T01234567
 
 The skill declares `envKeys: ['SLACK_BOT_TOKEN', 'SLACK_TEAM_ID']` and the official `@modelcontextprotocol/server-slack` consumes them.
 
-## Use in a workflow
+## Use in an agent
 
 ```js
 import { WorkflowAgent, WorkflowGraph } from '@zibby/core';

package/package.json

@@ -1,29 +1,78 @@
 {
   "name": "@zibby/skills",
-  "version": "0.1.33",
+  "version": "0.1.35",
   "description": "Built-in skill definitions for Zibby test automation framework",
   "type": "module",
   "main": "dist/index.js",
+  "types": "dist/index.d.ts",
   "exports": {
-    ".": "./dist/index.js",
+    ".": {
+      "types": "./dist/index.d.ts",
+      "default": "./dist/index.js"
+    },
     "./bin/mcp-sentry.mjs": "./bin/mcp-sentry.mjs",
     "./bin/mcp-lark.mjs": "./bin/mcp-lark.mjs",
     "./bin/mcp-slack.mjs": "./bin/mcp-slack.mjs",
-    "./browser": "./dist/browser.js",
-    "./jira": "./dist/jira.js",
-    "./github": "./dist/github.js",
-    "./plane": "./dist/plane.js",
-    "./slack": "./dist/slack.js",
-    "./lark": "./dist/lark.js",
-    "./memory": "./dist/memory.js",
-    "./function": "./dist/function-skill.js",
-    "./integrations": "./dist/integrations.js",
-    "./report": "./dist/report.js",
-    "./llm-billing": "./dist/llm-billing.js",
-    "./sentry": "./dist/sentry.js"
+    "./browser": {
+      "types": "./dist/browser.d.ts",
+      "default": "./dist/browser.js"
+    },
+    "./jira": {
+      "types": "./dist/jira.d.ts",
+      "default": "./dist/jira.js"
+    },
+    "./github": {
+      "types": "./dist/github.d.ts",
+      "default": "./dist/github.js"
+    },
+    "./gitlab": {
+      "types": "./dist/gitlab.d.ts",
+      "default": "./dist/gitlab.js"
+    },
+    "./linear": {
+      "types": "./dist/linear.d.ts",
+      "default": "./dist/linear.js"
+    },
+    "./plane": {
+      "types": "./dist/plane.d.ts",
+      "default": "./dist/plane.js"
+    },
+    "./slack": {
+      "types": "./dist/slack.d.ts",
+      "default": "./dist/slack.js"
+    },
+    "./lark": {
+      "types": "./dist/lark.d.ts",
+      "default": "./dist/lark.js"
+    },
+    "./memory": {
+      "types": "./dist/memory.d.ts",
+      "default": "./dist/memory.js"
+    },
+    "./function": {
+      "types": "./dist/function-skill.d.ts",
+      "default": "./dist/function-skill.js"
+    },
+    "./integrations": {
+      "types": "./dist/integrations.d.ts",
+      "default": "./dist/integrations.js"
+    },
+    "./report": {
+      "types": "./dist/report.d.ts",
+      "default": "./dist/report.js"
+    },
+    "./llm-billing": {
+      "types": "./dist/llm-billing.d.ts",
+      "default": "./dist/llm-billing.js"
+    },
+    "./sentry": {
+      "types": "./dist/sentry.d.ts",
+      "default": "./dist/sentry.js"
+    }
   },
   "scripts": {
-    "build": "node ../scripts/build.mjs",
+    "build": "node ../scripts/build.mjs && npm run build:types",
+    "build:types": "tsc -p tsconfig.types.json",
     "prepack": "node scripts/copy-docs.mjs",
     "lint": "eslint .",
     "lint:fix": "eslint --fix ."
@@ -56,8 +105,8 @@
     "node": ">=18.0.0"
   },
   "dependencies": {
-    "@zibby/agent-workflow": "^0.3.0",
     "@modelcontextprotocol/sdk": "^1.29.0",
+    "@zibby/agent-workflow": "^0.3.0",
     "better-sqlite3": "^12.6.2",
     "mem0ai": "npm:@zibby/mem0ai@^3.0.5",
     "zod": "^3.23.0 || ^4.0.0"
@@ -73,6 +122,7 @@
     "@eslint/js": "^10.0.1",
     "esbuild": "^0.28.0",
     "eslint": "^10.0.2",
-    "globals": "^17.4.0"
+    "globals": "^17.4.0",
+    "typescript": "^5.9.3"
   }
 }