@myapihq/cli 2.4.0 → 2.4.2

package/dist/skills/my-function-api/SKILL.md

@@ -0,0 +1,104 @@
+---
+name: my-function-api
+version: 1.0.0
+description: >
+  Deploy JavaScript functions to the MyAPI edge runtime (Cloudflare Workers). Register a function, upload a single-file JS bundle, get a live HTTP invocation URL or run it on a cron schedule. Each function gets a scoped capability key for cross-slot calls.
+triggers: [function, deploy function, edge function, serverless, cloudflare worker, cron, scoped api key, capability key, invocation url, bundle]
+checksum: sha256-ada0a52fdd9c0ba14ca86496e1c5c42e8b018155c3e8c83edba071fa6bd0b7e9
+---
+
+# MyFunctionAPI
+
+Deploy backend code without running a server. Register a function, upload a single-file JS bundle, and it goes live on the MyAPI edge runtime (Cloudflare Workers) with a public invocation URL — or runs on a cron schedule. Each function carries a scoped capability key so it can call other MyAPI slots with its own authority.
+
+The full loop is live: **create → deploy → invoke → inspect runs → set secrets**.
+
+## Capabilities
+<!-- llm:start -->
+**Two-step lifecycle: register, then deploy.** `myapi fn create --name <slug>` persists the function record and mints a `scoped_api_key`, returned **exactly once** (save it if you need it). `myapi fn deploy <id> <bundle.js>` uploads a single-file JavaScript bundle (≤4MB); the backend wraps it with the MYAPI shim and ships it to Cloudflare Workers. After deploy the function has a live `invocation_url`.
+
+**Scoped key = capability key.** It is **org-locked**. By default it inherits the deployer's slot grants; narrow it at create time with `--scope <slot>[,<slot>...]` (comma-separated, e.g. `--scope email,storage`) — the primary way to deploy a deliberately narrow function. Grants can never exceed the caller's, so a function never out-reaches the credential that created it. It is rejected with `403 SCOPE_FORBIDDEN` at `/hq/*`, `/admin/*`, `/internal/*`. **Deploy rotates this key** — the fresh value is printed once on every deploy. (Minting a narrow account key first — `myapi keys create --grant ...` — is only needed when the *deploy credential itself* must be constrained, e.g. handing deploy rights to another system.)
+
+**HTTP or cron triggers.** Default is `http` — the function gets a public invocation URL once deployed. Pass `--cron "<expr>"` at create time to run on a schedule (e.g. `"0 8 * * *"`) instead.
+
+**Secrets via Worker Secrets.** `myapi fn env <id> <name> <value>` sets a secret (Stripe key, API token, …) as a Cloudflare Worker Secret on a deployed function. The value is encrypted at rest by Cloudflare and never stored or echoed by MyAPI. The function must already be deployed.
+
+**Inspect invocations.** `myapi fn runs <id>` lists recent invocation records (most recent first, up to 100) with status, duration, and any error message.
+
+Name rules (validated client- and server-side, kept identical):
+- `^[a-z0-9][a-z0-9-]{0,49}$` — kebab-case, 1-50 chars
+- Reserved server-side: `www`, `api`, `admin`, `system`, `default`
+<!-- llm:end -->
+
+## Commands
+<!-- generated:start -->
+| Command | What it does |
+|---|---|
+| `myapi fn create --name <name> [--cron <expr>] [--scope <slot>[,<slot>...]]` | Register a function record + receive scoped API key (returned once). `--scope` narrows the key's slot grants |
+| `myapi fn deploy <id> <bundle.js>` | Upload a single-file JS bundle (≤4MB) and go live; rotates the scoped key |
+| `myapi fn env <id> <name> <value>` | Set a Worker Secret on a deployed function |
+| `myapi fn runs <id>` | List recent invocation records (status, duration, errors) |
+| `myapi fn list` | List functions in your org |
+| `myapi fn get <id>` | Inspect a function (name, trigger, invocation URL) |
+| `myapi fn delete <id>` | Soft-delete the record + revoke the scoped key |
+<!-- generated:end -->
+
+## Examples
+<!-- llm:start -->
+```bash
+# Register an HTTP function (invocation_url is empty until you deploy)
+myapi fn create --name my-app-api
+# → Function created: fn_abc123
+#   Scoped API key (returned once — save it if you need it):
+#     hq_live_...   (scoped keys are not visually distinct from account keys)
+
+# Deploy a single-file JS bundle → goes live, scoped key is rotated
+myapi fn deploy fn_abc123 ./dist/bundle.js
+# → Deployed function fn_abc123
+#   Invocation URL:  https://fn-abc123.<...>.workers.dev
+#   Scoped API key was rotated. New value (returned once): hq_live_...
+
+# Set a secret (encrypted at rest by Cloudflare; never echoed)
+myapi fn env fn_abc123 STRIPE_KEY sk_live_...
+
+# Inspect recent invocations
+myapi fn runs fn_abc123
+
+# Register a cron function instead of HTTP
+myapi fn create --name daily-report --cron "0 8 * * *"
+
+# Register with a narrowed key — the function can only call email + storage
+myapi fn create --name mailer --scope email,storage
+
+# List + inspect
+myapi fn list
+myapi fn get fn_abc123
+
+# Delete (revokes the scoped key — future calls with it return 401)
+myapi fn delete fn_abc123
+```
+
+### Using the scoped key
+
+```bash
+# Save the key returned at create/deploy time
+SCOPED_KEY="hq_live_..."
+
+# Call slots the key was granted — works (within its org + grants)
+curl -H "Authorization: Bearer $SCOPED_KEY" \
+  https://api.myapihq.com/database/orgs/$ORG_ID/namespaces
+
+# Calling /hq/* with it — denied (403 SCOPE_FORBIDDEN)
+curl -H "Authorization: Bearer $SCOPED_KEY" \
+  https://api.myapihq.com/hq/orgs
+# → 403 {"error":{"code":"SCOPE_FORBIDDEN"}}
+```
+<!-- llm:end -->
+
+## Notes
+
+- The bundle is a **single JavaScript file** (≤4MB). Bundle your dependencies before deploy (esbuild/rollup/etc.).
+- `--cron` is set at create time; the trigger type is fixed for the function's lifetime.
+- Deploy rotates the scoped key on every call — re-capture the printed value if other systems use it.
+
+Run `myapi fn --help` or `myapi fn <subcommand> --help` for full flag reference.

package/dist/skills/my-function-api/claude/.claude-plugin/plugin.json

@@ -0,0 +1,7 @@
+{
+  "name": "my-function-api",
+  "description": "Run JavaScript functions on the edge. HTTP or cron triggers. Pre-injected MYAPI SDK scoped to the org — no auth tokens in user code.",
+  "version": "1.0.0",
+  "status": "preview",
+  "published": true
+}

package/dist/skills/my-funnel-api/SKILL.md

@@ -4,7 +4,7 @@ version: 1.0.0
 description: >
   Create and publish websites (funnels) to the edge. Push raw HTML to any slug and it goes live instantly on your org's domain or preview subdomain.
 triggers: [funnel, landing page, website, page, publish, push, slug, html, edge, preview subdomain, makeautonomous]
-checksum: sha256-pending
+checksum: sha256-3b463d6ac52fba7d44f89195b5704b02903ffdd9a677655f9c1bff0f13b25ab4
 ---
 
 # MyFunnelAPI
@@ -19,7 +19,7 @@ Funnels are the publishing surface. You create a funnel under an org (one comman
 
 By default, your funnel lives on a free preview subdomain (`*.makeautonomous.com`) you get with every org. To serve on a custom domain, register and assign one via **mydomainapi** first.
 
-Every funnel auto-provisions a **webhook** at creation time (`org_webhook_id`). The funnel exposes two public proxy endpoints your HTML can call directly (no API key needed): a **form submit** at `POST /funnel/funnels/{id}/submit/{slug}` that delivers submissions through that webhook (CRM upsert + bound workflows fire automatically), and an **analytics/event ingest** for pageviews and click tracking. For multi-form funnels you can bind individual slugs to specific destinations with `myapi funnel form ... --capture-to webhook:<id>`.
+Every funnel auto-provisions a **webhook** at creation (`org_webhook_id`), and exposes two public proxy endpoints your HTML can call without an API key: a **form submit** at `POST /funnel/funnels/{id}/submit/{slug}` (delivers through that webhook — CRM upsert + bound workflows fire automatically), and an **analytics/event ingest** for pageviews and click tracking. Bind individual slugs to other destinations with `myapi funnel form ... --capture-to webhook:<id>`.
 <!-- llm:end -->
 
 ## Commands

package/dist/skills/my-funnel-api/claude/.claude-plugin/plugin.json

@@ -2,5 +2,6 @@
   "name": "my-funnel-api",
   "description": "Build multi-page sites and funnels with headless HTML upload.",
   "version": "1.0.0",
+  "status": "ga",
   "published": true
 }

package/dist/skills/my-git-api/SKILL.md

@@ -4,7 +4,7 @@ version: 1.0.0
 description: >
   Hosted git repositories over HTTP. Create repos, read history (log/show/tree/blob/diff), and write atomically (commit/branch/tag/merge) — no clone needed. Real `git clone`/`push` also work over HTTPS with your API key as the password.
 triggers: [git, repo, repository, clone, push, commit, branch, tag, merge, diff, version control, source control, vcs]
-checksum: sha256-pending
+checksum: sha256-a059c8f2b59205a1d66ecf70556b60fa3a3606044aaa54e242344ea652efb5e9
 ---
 
 # MyGitAPI

package/dist/skills/my-git-api/claude/.claude-plugin/plugin.json

@@ -2,5 +2,6 @@
   "name": "my-git-api",
   "description": "Hosted git repositories over HTTP — create repos, commit files, manage branches and tags, read trees, blobs, history, and diffs. No local clone required.",
   "version": "1.0.0",
+  "status": "ga",
   "published": true
 }

package/dist/skills/my-image-api/SKILL.md

@@ -4,7 +4,7 @@ version: 1.0.0
 description: >
   Generate AI images from a text prompt. Async — submit a prompt, the CLI polls until the image is ready, then returns a public CDN URL. Image lands automatically in your org's storage.
 triggers: [image, generate image, ai image, hero image, logo, illustration, watercolor, prompt, cyberpunk, ratio, aspect ratio]
-checksum: sha256-pending
+checksum: sha256-17f496ae8c575743872e87c5c3b281e621b3557ef3ff9eeb0b3d664ec4212e57
 ---
 
 # MyImageAPI

package/dist/skills/my-image-api/claude/.claude-plugin/plugin.json

@@ -2,5 +2,6 @@
   "name": "my-image-api",
   "description": "Generate AI images from a text prompt. Async, polls until ready, returns a public CDN URL.",
   "version": "1.0.0",
+  "status": "ga",
   "published": true
 }

package/dist/skills/my-llm-api/SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: my-llm-api
-version: 1.2.0
+version: 1.2.1
 description: >
   Two-surface LLM primitive. Raw chat completion against self-hosted
   open-source models (you pick the model), and objective verbs
   (classify / extract / summarize / draft) that hide the model behind a
   task. Pricing in cents per 1M tokens; charged from your MyAPI balance.
 triggers: [llm, completion, chat, embed, embedding, inference, classify, extract, summarize, draft, qwen]
-checksum: sha256-pending
+checksum: sha256-6c399da099802637c68eda61ba85a23286ff3dca8f50c391e80ab442777c17c4
 ---
 
 # MyLLMAPI
@@ -15,9 +15,9 @@ checksum: sha256-pending
 A two-surface LLM gateway:
 
 - **Raw** — `complete` / `embed` / `models`. You pick a self-hosted catalog model (run `myapi llm models` for the live list). Proprietary models are not callable here.
-- **Verbs** — `classify` / `extract` / `summarize` / `draft`. You ask for a task done; the model is implementation detail and is never named in the response.
+- **Verbs** — `classify` / `extract` / `summarize` / `draft`. You ask for a task done; the model is implementation detail.
 
-Pricing is in cents per 1M tokens at the actual upstream rate; cost is debited from your MyAPI balance.
+Pricing is cents per 1M tokens at the actual upstream rate, debited from your MyAPI balance.
 
 ## Capabilities
 <!-- llm:start -->
@@ -25,10 +25,7 @@ Use this for workflow tasks — summarize a doc, classify an inbound email, extr
 
 **Don't use this as your own model.** If you're an agent reading this, you already have a more capable model than what's exposed here. Reach for the LLM verbs when you're scripting a recurring step where a small/cheap model is the right tool — not for one-shot reasoning you can just do yourself.
 
-### Raw vs. verbs
-
-- **Raw `complete`** — full control: pick the model, build the `messages` array, set `max_tokens`/`temperature`/`stop`. Use when shape matters.
-- **Verbs** — you want a *result* (label, JSON, summary, draft). Use when you don't care which model runs underneath.
+Reach for raw `complete` when shape matters (you build the `messages` array and set `max_tokens`/`temperature`/`stop`); reach for a verb when you want a *result* and don't care which model produced it.
 
 ### Raw `complete` request
 ```json
@@ -87,7 +84,7 @@ Shared usage block on every verb:
 { "tier_used": "fast", "tokens_in": 65, "tokens_out": 37, "cost_cents": 0.005 }
 ```
 
-The model/provider is **never** named in the verb response. That's the point — the verb is the contract, the model is implementation.
+The model/provider is **never** named in the verb response — the verb is the contract.
 
 ### OpenAI-compatible drop-in
 
@@ -103,8 +100,6 @@ r = client.chat.completions.create(model="<model-id>",
     messages=[{"role":"user","content":"Hi"}])
 ```
 
-Use raw `complete` for first-party code; the compat path for existing OpenAI/LangChain tooling.
-
 <!-- llm:end -->
 
 ## Commands

package/dist/skills/my-llm-api/claude/.claude-plugin/plugin.json

@@ -2,5 +2,6 @@
   "name": "my-llm-api",
   "description": "Self-hosted open-source LLM: raw chat completions (you pick the model) + objective verbs (classify/extract/summarize/draft). Billed in cents per 1M tokens from your balance. Use in workflow steps, not for your own reasoning.",
   "version": "1.0.0",
+  "status": "ga",
   "published": true
 }

package/dist/skills/my-payments-api/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: my-payments-api
+version: 1.1.0
+description: >
+  Take payments via Stripe — one-off or recurring. Connect your own Stripe account, then create hosted Stripe Checkout URLs. No raw card data ever touches your code.
+triggers: [payment, stripe, checkout, charge, subscription, take payments, billing, refund, recurring, sell]
+checksum: sha256-bdf124b2a3d32c87676ad34f0a20df134099bcbebe7f9a11f05ceddf74a6b2a9
+---
+
+# MyPaymentsAPI
+
+Wraps Stripe. Agents create Checkout URLs, paste them into the frontend, customers pay on Stripe-hosted pages. MyAPI never custodies funds — Stripe is the merchant of record on your connected account.
+
+## Capabilities
+<!-- llm:start -->
+**Bring your own Stripe (T0).** `myapi payments connect --stripe-key <sk_...>` links your existing Stripe account with your own secret key. The key is validated live against Stripe, stored encrypted, and never echoed. Your Stripe account stays the merchant of record. (Connect Express / MyAPI-onboarded accounts — "T1" — are not yet available; the backend returns `501 T1_DEFERRED`.)
+
+**One verb covers one-off and recurring.** `myapi payments charge --amount 9.99` creates a one-off Checkout URL. Add `--every month` (or `--every year`) and the same verb creates a subscription Checkout URL instead. No separate `subscribe` verb. `--amount` is in **dollars** (e.g. `19` or `9.99`) and must be positive.
+
+**Charge returns a hosted Stripe Checkout URL.** The agent sends the customer to that `checkout_url` — paste it into a frontend, an email, or a redirect. The card-entry surface is owned entirely by Stripe Checkout (SAQ-A scope only); MyAPI infra never touches raw card data.
+
+**Optional charge fields:** `--description <text>` (line-item label), `--email <addr>` (pre-fill the customer's email), `--success-url <url>` / `--cancel-url <url>` (where Checkout redirects after the session).
+
+**Refunds are full only.** `myapi payments refund <charge_id>` issues a full refund. Partial refunds are not supported.
+<!-- llm:end -->
+
+## Commands
+<!-- generated:start -->
+| Command | What it does |
+|---|---|
+| `myapi payments connect --stripe-key <sk_...>` | Link your own Stripe account (T0 — bring your own key) |
+| `myapi payments status` | Show the org's Stripe connection status |
+| `myapi payments charge --amount <usd> [--every month|year] [--description <s>] [--email <addr>] [--success-url <url>] [--cancel-url <url>]` | Create a charge → hosted Stripe Checkout URL |
+| `myapi payments list` | List charges in your org |
+| `myapi payments get <charge_id>` | Inspect a charge |
+| `myapi payments refund <charge_id>` | Full refund (no partial) |
+<!-- generated:end -->
+
+## Examples
+<!-- llm:start -->
+```bash
+# ── Setup: connect your Stripe account (T0 — bring your own key) ─────────────
+
+myapi payments connect --stripe-key sk_live_abcd1234...
+# → Stripe connected. Your existing Stripe account stays the merchant of record.
+
+myapi payments status
+# → Tier / Stripe account / onboarding status
+
+# ── Take a one-off payment ──────────────────────────────────────────────────
+
+myapi payments charge \
+  --amount 9.99 \
+  --description "Pro plan upgrade" \
+  --email customer@example.com
+# → Charge created: pay_... — returns a hosted Stripe Checkout URL.
+#   Send the customer to that checkout_url (frontend, email, redirect).
+
+# ── Take a recurring payment (subscription) ────────────────────────────────
+
+myapi payments charge \
+  --amount 29 --every month \
+  --description "Pro plan" \
+  --success-url https://acme.com/thanks \
+  --cancel-url https://acme.com/pricing
+
+# ── Lifecycle ───────────────────────────────────────────────────────────────
+
+myapi payments list
+myapi payments get <charge_id>
+myapi payments refund <charge_id>
+```
+<!-- llm:end -->
+
+## What's NOT available
+
+- **T1 (MyAPI-onboarded Connect Express).** `connect` only accepts your own `sk_...` key today; T1 returns `501 T1_DEFERRED`.
+- A product catalog as a MyAPI/Stripe resource — pass `--amount` inline on each charge.
+- Coupons, discounts, promotion codes.
+- Stripe Tax integration.
+- Partial refunds.
+- Multi-currency on a single charge.
+- Customer object as a first-class resource (Stripe tracks by email; `my-crm-api` has the engagement view).
+
+Run `myapi payments --help` or `myapi payments <subcommand> --help` for full flag reference.

package/dist/skills/my-payments-api/claude/.claude-plugin/plugin.json

@@ -0,0 +1,7 @@
+{
+  "name": "my-payments-api",
+  "description": "Take payments with Stripe Checkout. Connect your Stripe account, create one-off or recurring charges, and refund — hosted checkout, no card handling.",
+  "version": "1.0.0",
+  "status": "preview",
+  "published": true
+}

package/dist/skills/my-people-api/README.md

@@ -0,0 +1,35 @@
+---
+# my-people-api
+
+Queryable contact database for B2B targeting. Search people by industry, seniority, function, country, or keyword and get back structured results with embedded company snapshots.
+
+## What it does
+
+- Filter the people database by attributes (industry, seniority, function, country, ...)
+- Fetch a single person with embedded company context
+- Feed results into `my-audience-api` to save reusable target lists
+- Pair with `my-email-api` for outbound campaigns
+
+## Quickstart
+
+```bash
+# Find target prospects
+myapi people search --industry saas --seniority vp,c_level --country US --limit 20
+
+# Single person (with embedded company)
+myapi people get person_01
+```
+
+## Authentication
+
+```bash
+export MYAPI_KEY=mak_...
+```
+
+Requires `api_key` and `org_id` from **myapihq**.
+
+## Documentation
+
+Full filter contract and audience integration: see `SKILL.md`.
+
+Run `myapi people --help` for inline reference.

package/dist/skills/my-people-api/SKILL.md

@@ -0,0 +1,107 @@
+---
+name: my-people-api
+version: 1.0.0
+description: >
+  Contact database backed by the Goldfox crawl. Filter people by Goldfox confidence tier, seniority, email type, country, link confidence, plus rich behavioral company signals (has_c_level, has_careers_page, has_decision_maker, etc.). The targeting layer for outbound campaigns.
+triggers: [people, contacts, leads, prospects, search, filter, goldfox, decision-makers, c-level, b2b targeting, corporate email]
+checksum: sha256-a4b594a30cc06d2f40fe26c594c1cb6962d91c4dbcc0625210d45a3faa27336e
+---
+
+# MyPeopleAPI
+
+A queryable contact database for B2B targeting, sourced from the **Goldfox** crawl. The data model is signal-rich: every row carries a Goldfox confidence tier, a per-link confidence score, an email type classification, and the embedded company's behavioral signals (has_c_level, has_careers_page, etc.). Filter on those signals to get high-precision target lists.
+
+## Capabilities
+<!-- llm:start -->
+The database returns people with their embedded company. Use when:
+
+- Building an outbound list with strong precision controls (e.g. only corporate-email c_levels in DE)
+- Filtering for buying signals (companies with careers/investors/shop pages, decision-makers present)
+- Combining with `my-audience-api` to save a filter snapshot for reuse across campaigns
+
+Filter contract — shared with `my-company-api` and the `filter` field of `my-audience-api`. OR within an array; AND across fields. **Empty filter = all rows with default confidence=high (Goldfox's curated tier).**
+
+```json
+{
+  "confidence":           ["high"],
+  "country":              ["US", "DE"],
+  "country_consistent":   true,
+  "seniority":            ["c_level", "vp_director"],
+  "email_type":           ["corporate"],
+  "tld_class":            ["cctld"],
+  "has_c_level":          true,
+  "has_decision_maker":   true,
+  "has_careers_page":     true,
+  "is_registered_entity": true,
+  "min_headcount":        5,
+  "min_source_count":     3,
+  "min_link_confidence":  0.8,
+  "keyword":              "platform",
+  "limit":                100,
+  "offset":               0
+}
+```
+
+Allowed values:
+- **confidence**: `high` (default — 96.4% of dataset, no UGC) / `low` (UGC source — spot-check) / `very_low` (UGC + freemail mismatch — usually drop)
+- **seniority**: `c_level`, `vp_director`, `manager`, `senior_ic`, `ic`
+- **email_type**: `corporate`, `freemail`, `role_based`, `other_corporate`
+- **tld_class**: `cctld`, `generic`, `vanity`, `low_trust`, `other`
+- **country**: ISO 3166-1 alpha-2 (US, DE, GB, …) — consensus across TLD + address + phone
+- **keyword**: case-insensitive substring on the row's domain (NOT name or title)
+- **link_confidence**: 0–1 per person; 1.0 = email-domain match (definitive), 0.5 = strong, lower = weak
+<!-- llm:end -->
+
+## Commands
+<!-- generated:start -->
+| Command | What it does |
+|---|---|
+| `myapi people search [--confidence <csv>] [--country <csv>] [--seniority <csv>] [--email-type <csv>] [--tld-class <csv>] [--has-c-level] [--has-decision-maker] [--has-careers-page] [--has-investors-page] [--has-shop-page] [--is-registered-entity] [--country-consistent] [--keyword <text>] [--min-headcount N] [--min-source-count N] [--min-link-confidence 0..1] [--limit N] [--offset N]` | Filter people; returns id/name/email/domain/country/link_conf table |
+| `myapi people get <person_id>` | Get a single person with embedded company |
+<!-- generated:end -->
+
+CSV-flag values use OR within (e.g. `--seniority c_level,vp_director` is `seniority IN (c_level, vp_director)`). Boolean flags are presence-only (`--has-c-level` enables it; omit to leave unfiltered).
+
+## Examples
+<!-- llm:start -->
+```bash
+# 1. Decision-makers in DE/FR/GB with corporate emails
+myapi people search \
+  --seniority c_level,vp_director \
+  --country DE,FR,GB \
+  --email-type corporate \
+  --limit 20
+
+# 2. High-precision filter: definitive link + registered entity + careers signal
+myapi people search \
+  --min-link-confidence 0.9 \
+  --is-registered-entity \
+  --has-careers-page \
+  --country US
+
+# 3. Single person with full company context
+myapi people get p_MTdlc2llY2xlLmZy.0
+```
+
+### End-to-end recipe — outbound campaign target list
+
+```bash
+# Build the target audience (saved filter)
+AID=$(myapi audience create "EU decision makers w/ careers signal" \
+  --source people \
+  --filter '{"seniority":["c_level","vp_director"],"country":["DE","FR","GB"],"email_type":["corporate"],"has_careers_page":true}' \
+  --json | jq -r .id)
+
+# Pull members for inspection
+myapi audience members $AID --limit 100 --json > targets.json
+```
+<!-- llm:end -->
+
+## Notes
+
+- The dataset is the Goldfox crawl — multi-million-row corporate contact data with provenance signals. Filter quality matters: defaults to `confidence=high` gives 96.4% of rows by count, but it's the curated tier; widening with `confidence=low` brings UGC rows that need spot-checking.
+- `seniority`, `email_type`, and `min_link_confidence` are people-only — silently ignored on `my-company-api` and on audiences with `--source company`.
+- `keyword` matches the row's **domain**, not name/title. Use `--keyword acme` to find people whose domain contains "acme".
+- For a persistent target list, use `my-audience-api` (snapshot the filter; re-evaluate on `audience refresh`).
+
+Run `myapi people --help` for full flag reference.

package/dist/skills/my-people-api/claude/.claude-plugin/plugin.json

@@ -0,0 +1,7 @@
+{
+  "name": "my-people-api",
+  "description": "Contact database backed by the Goldfox crawl. Filter people by confidence tier, seniority, email type, country, link confidence, plus rich behavioral company signals (has_c_level, has_careers_page, has_decision_maker). The targeting layer for outbound campaigns.",
+  "version": "1.0.0",
+  "status": "preview",
+  "published": true
+}

package/dist/skills/my-pixel-api/README.md

@@ -0,0 +1,38 @@
+# my-pixel-api
+
+Tracking pixel + identity resolution for MyAPI funnels and email. Capture visits, events, and stitch known users to anonymous sessions — the analytics layer that closes the loop between outbound campaigns and on-page behavior.
+
+## What it does
+
+- Per-org **visits** and **events** read from the pixel data layer
+- **Identity resolution** — given a known identifier (email, user_id), return the anonymous sessions it's been seen in
+- **Interactions** — fine-grained activity stream across sessions
+- **Audience geo samples** — country/region distribution for a visitor pool
+- Cross-domain identity bridging via the cookie-bridge pixel
+
+## Quickstart
+
+```bash
+myapi pixel visits --limit 50
+myapi pixel events --kind page_view
+myapi pixel identity alice@example.com
+myapi pixel interactions --since 24h
+```
+
+## Authentication
+
+```bash
+export MYAPI_KEY=mak_...
+```
+
+Requires `api_key` and `org_id` from **myapihq**.
+
+## Documentation
+
+Visit/event shapes, identity resolution semantics, retention windows, and CRM auto-ingest contract: see `SKILL.md`.
+
+Run `myapi pixel --help` for inline reference.
+
+## Status
+
+**Skill content is draft; backend wiring of the agent-facing reads is in progress.** When pixel data lands in `myapi crm contacts/{id}/events` via the planned `pixel_visit` event ingest, this skill ships as published.

package/dist/skills/my-pixel-api/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: my-pixel-api
+version: 1.0.0
+description: >
+  Tracking pixel + identity resolution for MyAPI funnels and email. Capture visits and events, resolve known users to anonymous sessions, stream interaction events for analytics. Pairs with mycrmapi for auto-ingest of pixel_visit events on known contacts.
+triggers: [pixel, analytics, tracking, visit, event, identity, session, attribution, geo, open pixel]
+checksum: sha256-1e8284fbf546ad1bdff32790f56f8c524a19e0b80b92cc6d612ce15295632c9f
+---
+
+# MyPixelAPI
+
+A lightweight pixel data layer for funnels published via **myfunnelapi** and emails sent via **myemailapi**. Reads visits, events, identity resolutions, and interaction streams. The analytics half of the loop between outbound (email/funnel) and the CRM.
+
+## Capabilities
+<!-- llm:start -->
+
+### What lands in the pixel layer
+
+- **Visits** — page-visit records scoped to a website host (`from_url`, `to_url`, `pixel_id`, timestamp). `--website <domain>` is required.
+- **Events** — typed engagement events: `sent`, `open`, `click`, `page_visit`. Requires at least one filter: `--campaign-id` or `--domain`.
+- **Interactions** — a unified timeline of visits + events. Requires at least one filter: `--website`, `--campaign-id`, or `--domain`.
+- **Identity** — given a `pixel_id` plus the `--website <domain>` it was seen on, resolve its identity graph (`{uuid, is_resolved, nodes, …}`).
+- **Audience** — a geographic distribution sample of the org's pixel audience (`myapi pixel audience`, no subcommand).
+
+### Identity stitching
+
+The cookie-bridge pixel (`/t/p`) is a cross-domain pixel used to stitch an anonymous session on one MyAPI funnel to the same browser on another. The open-pixel (`/t/o`) is the 1x1 transparent gif embedded in outbound email and resolves the email recipient's session when they open the mail.
+
+### CRM auto-ingest (when wired)
+
+When pixel `identify` events fire with a known email, the CRM service auto-creates / upserts a contact and writes a `pixel_visit` event on its timeline. Today this hook lives in the hypersearch service and needs to move to the integrated stack — until then, pixel data and CRM data live in separate stores.
+
+### Retention
+
+Pixel data lives ~90 days hot; aggregated geo/audience samples persist longer. Don't depend on individual-event-level data being available indefinitely — promote anything you need long-term into the CRM as a custom event.
+
+### When to use
+
+- **Campaign attribution** — did the people you emailed actually visit?
+- **Funnel optimization** — which page is dropping off?
+- **Audience definition** — build a Goldfox/CRM filter from observed visit behavior
+- **Re-engagement** — pull the list of contacts whose `pixel_visit` is more than N days old
+<!-- llm:end -->
+
+## Commands
+<!-- generated:start -->
+| Command | What it does |
+|---|---|
+| `myapi pixel visits --website <domain> [--from <iso>] [--to <iso>] [--limit N] [--offset N]` | Page-visit timeline scoped to a website host |
+| `myapi pixel events (--campaign-id <id> \| --domain <domain>) [--from <iso>] [--to <iso>] [--limit N] [--offset N]` | Engagement events (sent / open / click / page_visit). Requires at least one filter: `--campaign-id` or `--domain` |
+| `myapi pixel interactions [--website <domain>] [--campaign-id <id>] [--domain <domain>] [--from <iso>] [--to <iso>] [--limit N] [--offset N]` | Unified timeline of visits + events |
+| `myapi pixel identity <pixel_id> --website <domain>` | Resolve a pixel ID's identity graph (returns `{uuid, is_resolved, nodes, …}`) |
+| `myapi pixel audience` | Geographic distribution sample of your pixel audience |
+<!-- generated:end -->
+
+## Examples
+<!-- llm:start -->
+```bash
+# Page visits on a funnel host (--website is required for visits)
+myapi pixel visits --website acme.com --limit 50
+
+# Engagement events for a campaign (event_type: sent | open | click | page_visit)
+myapi pixel events --campaign-id q2-launch --from 2026-06-01 --to 2026-06-30
+
+# Events by domain instead of campaign
+myapi pixel events --domain acme.com --limit 100
+
+# Unified timeline (visits + events) — needs at least one filter
+myapi pixel interactions --website acme.com
+
+# Resolve a pixel ID's identity graph (--website is required)
+myapi pixel identity px_abc123 --website acme.com
+# → { "uuid": "...", "is_resolved": true, "nodes": [ ... ] }
+
+# Geographic distribution sample of the org's pixel audience
+myapi pixel audience
+```
+<!-- llm:end -->
+
+## Notes
+
+- **Privacy.** Pixel data captures sessions, not personal info beyond what your funnel/email forms collect. Identity resolution only works when a known identifier was passed in via your code or the cookie-bridge.
+- **No write API for synthetic events** — the pixel records what the embedded JS/email-pixel observes. To inject custom timeline entries, use `myapi crm contacts/{id}/events` instead (when reserved-kind allows; today event writes are platform-only).
+- **`my-crm-api` is the durable record.** Pixel data ages out at ~90 days; CRM events are permanent. If a behavioral signal matters for long-term targeting, promote it into the CRM.
+
+Run `myapi pixel --help` for inline reference.
+
+## Status
+
+**Backend reads are GA; agent-facing skill content is draft.** This skill publishes (status flips from `planned` to `ga` in `services.ts`) once pixel → CRM auto-ingest is wired so the cross-primitive examples above resolve end-to-end.

package/dist/skills/my-pixel-api/claude/.claude-plugin/plugin.json

@@ -0,0 +1,7 @@
+{
+  "name": "my-pixel-api",
+  "description": "Tracking pixel + identity resolution. Capture visits, events, and stitch known users to anonymous sessions.",
+  "version": "1.0.0",
+  "status": "preview",
+  "published": true
+}