@myapihq/cli 2.4.1 → 2.4.2

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
+}

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

@@ -0,0 +1,34 @@
+---
+# my-queue-api
+
+A durable job queue. Enqueue work and have it delivered to your HTTP consumer with retry/backoff, a concurrency cap, and a dependency DAG — no broker to run.
+
+## What it does
+
+- Named queues, each bound to an HTTP `consumer_url`
+- Jobs retried with backoff up to `max_attempts`, then dead-lettered
+- `max_concurrency` cap on in-flight jobs
+- Idempotent enqueue via `dedup_key`
+- Delayed jobs (`delay_seconds`) and a dependency DAG (`depends_on`)
+
+## Quickstart
+
+```bash
+myapi queue create thumbnails --consumer-url https://your-handler.example.com
+myapi queue enqueue thumbnails --payload '{"asset_id":"a_123"}' --dedup-key a_123
+myapi queue jobs thumbnails
+```
+
+## Authentication
+
+```bash
+export MYAPI_KEY=mak_...
+```
+
+Requires `api_key` + `org_id` from **myapihq**.
+
+## Documentation
+
+Full command reference and the queue/workflow/task decision guide: see `SKILL.md`.
+
+Run `myapi queue --help` for inline reference.

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

@@ -0,0 +1,78 @@
+---
+name: my-queue-api
+version: 1.0.0
+description: >
+  Durable job queue — enqueue work and have it retried against your HTTP consumer, with concurrency caps and a dependency DAG.
+triggers: [queue, job queue, background job, enqueue, retry, async work, dead letter, delayed job, concurrency]
+checksum: sha256-528a48bc9adcde7c48ad7208db7796ec37032f6df31bf5a2ca1f2bf63f643fe9
+---
+
+# MyQueueAPI
+
+A queue is a named, durable pipeline of jobs. Each queue has an HTTP `consumer_url`; every job is POSTed there, and a 2xx response succeeds the job. Failed jobs retry with backoff up to `max_attempts`, then dead-letter.
+
+## Capabilities
+<!-- llm:start -->
+`queue` is the **durable async machine work** layer. Use it when work must run reliably, eventually — not inline with the request that triggered it.
+
+A queue is created with:
+
+| Field | Meaning |
+|---|---|
+| `consumer_url` | HTTP(S) endpoint each job payload is POSTed to. A 2xx succeeds the job. |
+| `max_attempts` | Retries before a job dead-letters (default 5). |
+| `max_concurrency` | Max jobs dispatched at once (default 5). |
+
+A job carries an arbitrary JSON `payload` (≤256 KB). Jobs support:
+
+- `dedup_key` — idempotency: a repeated key returns the existing job.
+- `delay_seconds` — hold the job before it becomes eligible.
+- `depends_on` — job ids this job waits on. Immutable — a DAG by construction. A job with unsucceeded `depends_on` starts blocked.
+
+**queue vs workflow vs task** — see `docs/orchestration-decision-guide.md`. Short version: `workflow` reacts to inbound webhooks inline; `queue` runs durable retried machine work; `task` is for work that needs an agent/human decision.
+<!-- llm:end -->
+
+## Commands
+<!-- generated:start -->
+| Command | What it does |
+|---|---|
+| `myapi queue create <name> --consumer-url <url> [--max-attempts <n>] [--max-concurrency <n>]` | Create a queue |
+| `myapi queue list` | List queues in your org |
+| `myapi queue get <name>` | Show a queue's retry/concurrency policy |
+| `myapi queue enqueue <name> --payload <json> [--dedup-key <k>] [--delay <s>] [--depends-on <id,id>]` | Enqueue a job |
+| `myapi queue jobs <name> [--status <s>] [--limit <n>]` | List a queue's jobs |
+| `myapi queue job <job_id>` | Show a single job's status |
+<!-- generated:end -->
+
+## Examples
+<!-- llm:start -->
+```bash
+# 1. Create a queue whose jobs POST to your handler
+myapi queue create thumbnails \
+  --consumer-url https://fn.myapi.com/<org>/<fn_id> \
+  --max-attempts 5 --max-concurrency 10
+
+# 2. Enqueue work — idempotent on --dedup-key
+myapi queue enqueue thumbnails \
+  --payload '{"asset_id":"a_123","size":256}' \
+  --dedup-key a_123-256
+
+# 3. A job that waits on others (DAG)
+J1=$(myapi queue enqueue build --payload '{"step":1}' --json | jq -r .id)
+myapi queue enqueue build --payload '{"step":2}' --depends-on $J1
+
+# 4. Inspect
+myapi queue jobs thumbnails --status dead
+myapi queue job <job_id>
+```
+<!-- llm:end -->
+
+## Notes
+
+- A 2xx from the `consumer_url` succeeds the job; anything else counts as a failed attempt.
+- After `max_attempts` a job goes to `status: dead` (the dead-letter state) — it is not retried further.
+- Job status values: `pending`, `blocked`, `running`, `succeeded`, `dead`.
+- `depends_on` is immutable: the DAG is declared at enqueue time.
+- `payload` is capped at 256 KB.
+
+Run `myapi queue --help` for the full flag reference.

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

@@ -0,0 +1,7 @@
+{
+  "name": "my-queue-api",
+  "description": "Durable job queue — enqueue work and have it retried against your HTTP consumer, with concurrency caps and a dependency DAG.",
+  "version": "1.0.0",
+  "status": "preview",
+  "published": true
+}

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

@@ -4,7 +4,7 @@ version: 1.0.0
 description: >
   Edge-hosted asset storage. Upload local files (.png/.jpg/.gif/.webp) directly, or have the server fetch from a public URL. Each asset gets a stable public CDN URL.
 triggers: [storage, upload, ingest, asset, cdn, image hosting, file upload, get-url, download, public url]
-checksum: sha256-pending
+checksum: sha256-80f78e83d086ec5e312abbb2fc7c85a2c9a87043a94b7e4fccc13902d5455df1
 ---
 
 # MyStorageAPI

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

@@ -2,5 +2,6 @@
   "name": "my-storage-api",
   "description": "Edge-hosted asset storage. Upload local files or ingest from URLs, each gets a stable public CDN URL.",
   "version": "1.0.0",
+  "status": "ga",
   "published": true
 }

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

@@ -0,0 +1,36 @@
+---
+# my-task-api
+
+An agent-task queue. File units of work, rank them by score, claim one under a lease, then resolve or fail it — the substrate for an autonomous agent loop.
+
+## What it does
+
+- File tasks with a short triage `description` and a full Markdown `body` tier
+- Ranked `list` — the agent-loop hot path, with a backlog signal
+- Lease-based `claim` / `extend` — crash-safe, auto-reverts on expiry
+- Terminal `resolve` / `fail` / `cancel`, with dependency cascade
+- `depends_on` DAG, `dedup_key` idempotency, `assignee` magic-link email
+- `resolve_on` — auto-resolve when a matching platform event fires
+
+## Quickstart
+
+```bash
+myapi task create "Review the vendor contract" --body @notes.md --importance high
+myapi task list
+myapi task get <id> --body
+myapi task claim <id> && myapi task resolve <id>
+```
+
+## Authentication
+
+```bash
+export MYAPI_KEY=mak_...
+```
+
+Requires `api_key` + `org_id` from **myapihq**.
+
+## Documentation
+
+Full command reference, the agent loop, and the workflow/queue/task decision guide: see `SKILL.md`.
+
+Run `myapi task --help` for inline reference.

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

@@ -0,0 +1,74 @@
+---
+name: my-task-api
+version: 1.0.0
+description: >
+  Agent-task queue — file units of work, rank them, claim under a lease, then resolve, fail, or cancel. The agent-loop hot path.
+triggers: [task, task queue, agent loop, work queue, claim task, resolve task, lease, backlog, to-do, assignee]
+checksum: sha256-ead9513eafbdd4d384a3cb297facf934f786f7067028c75cc08ef2ba1ac61cf7
+---
+
+# MyTaskAPI
+
+A task is a unit of work that needs an agent or human to act on it. Tasks are ranked by score; a worker claims one under a time-limited lease, does the work, then resolves or fails it. This is distinct from `my-workflow-api` (event→action automation) and `my-queue-api` (durable machine jobs).
+
+## Capabilities
+<!-- llm:start -->
+`task` is the **"this needs a decision"** layer — the agent-loop hot path.
+
+The loop is: **`list` → `get <id> --body` → `claim` → `resolve`/`fail`**.
+
+- `list` returns the top open tasks ranked by score, projected to `{id, description, score}`, plus a backlog signal — `Showing N of M open task(s)`. It is deliberately small; do not expect the full task.
+- `get <id>` returns the full task object. It does **not** fetch the Markdown body.
+- `get <id> --body` additionally fetches the **body tier** — the full Markdown context. Read it once, when you commit to a task.
+- `claim <id>` takes an atomic lease (default 10 min). Lease expiry auto-reverts the task to open, so a crashed worker never strands a task. Heartbeat long work with `extend`.
+- `resolve <id>` is terminal and unblocks dependents. `fail <id> --reason` is terminal and does not auto-retry. `cancel <id>` is terminal, distinct from fail.
+
+Task fields at creation: `description` (~100-token triage key), `body` (full Markdown), `importance`, `due`, `assignee` (emails them a magic link), `tags`, `depends_on` (immutable DAG — a task with unresolved deps starts blocked), `dedup_key` (idempotent), `resolve_on` (an event matcher — a matching platform event auto-resolves the task), `source`.
+
+**task vs workflow vs queue** — see `docs/orchestration-decision-guide.md`.
+<!-- llm:end -->
+
+## Commands
+<!-- generated:start -->
+| Command | What it does |
+|---|---|
+| `myapi task create "<description>" [--body <md\|@file>] [--importance <i>] [--due <rfc3339>] [--assignee <email>] [--tag <t,t>] [--depends-on <id,id>] [--resolve-on <event[:field=value]>]` | File a task |
+| `myapi task list [--status <s>] [--tag <t>] [--importance <i>] [--limit <n>]` | Top open tasks, ranked |
+| `myapi task get <id> [--body]` | Show a task; `--body` also fetches the body tier |
+| `myapi task claim <id> [--lease <s>] [--worker <name>]` | Take an atomic lease |
+| `myapi task extend <id> [--lease <s>]` | Heartbeat a live claim |
+| `myapi task resolve <id>` | Resolve a task (terminal) |
+| `myapi task fail <id> --reason "<why>"` | Fail a task (terminal) |
+| `myapi task cancel <id>` | Cancel a task (terminal) |
+<!-- generated:end -->
+
+## Examples
+<!-- llm:start -->
+```bash
+# File a task with full Markdown context from a file
+myapi task create "Review the Q3 vendor contract" \
+  --body @contract-notes.md --importance high --due 2026-06-01
+
+# The agent loop
+myapi task list                          # ranked; pick the top id
+myapi task get <id> --body               # read the body, once, on commit
+myapi task claim <id> --worker agent-7   # lease it
+# ... do the work, heartbeat if long ...
+myapi task extend <id>
+myapi task resolve <id>                  # or: myapi task fail <id> --reason "blocked on legal"
+
+# Event-driven: auto-resolve when a matching platform event fires
+myapi task create "Ship once payment clears" \
+  --resolve-on payment.succeeded:order_id=o_42
+```
+<!-- llm:end -->
+
+## Notes
+
+- `list` is the hot path — it returns a small ranked projection plus `total_open`, not full tasks.
+- The body tier is fetched only with `get --body`. Read it once, on commit, to keep the loop token-cheap.
+- A claim is a lease: it expires (default 10 min) and auto-reverts the task to open. Heartbeat with `extend`.
+- `resolve` unblocks dependents; `fail` cascades to dependents that can never proceed.
+- `resolve_on` matches platform events. Today few event kinds are emitted in production — verify the kind exists before relying on it.
+
+Run `myapi task --help` for the full flag reference.

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

@@ -0,0 +1,7 @@
+{
+  "name": "my-task-api",
+  "description": "Agent-task queue — file units of work, rank them, claim under a lease, then resolve, fail, or cancel. The agent-loop hot path.",
+  "version": "1.0.0",
+  "status": "preview",
+  "published": true
+}