@extuitive/skill 0.1.0

package/skills/extuitive/references/upload-status.md

@@ -0,0 +1,102 @@
+# `/extuitive upload-status` — how is an upload going
+
+Reports where an Extuitive upload has got to, and finishes by saying what was actually
+accepted.
+
+A `batchId` given with the command arrives in `$ARGUMENTS`.
+
+## Why this is not just "did the transfer finish"
+
+Bytes arriving at storage is not the same as a file being accepted. Every file is checked
+after it lands, and it can still be rejected. `READY` is the only status that means a file
+uploaded successfully, and it arrives some time after the transfer completes.
+
+So "the upload finished" is never the answer on its own. The answer is how many reached
+`READY`, and which ones did not, and why.
+
+## Steps
+
+### 1. Find the batch
+
+In order of preference:
+
+1. The `batchId` the person gave you, or the one from a `create_upload_batch` call earlier in
+   this conversation.
+2. Otherwise call `list_upload_batches` for the workspace. It returns batches newest first
+   with `fileCount`, `pending`, and `statusCounts` per batch. The first entry is the current
+   one. This is also the right call when someone uploaded through a browser link, since you
+   never saw a `batchId` for that.
+
+If you do not know which workspace, use the one chosen earlier in this conversation, or call
+`list_workspaces` first when there was none. A `batchId` belongs to the workspace it was
+created in, so a batch from before a switch needs the workspace it was made in rather than the
+current one.
+
+A single file uploaded on its own has no `batchId` at all. Use `get_upload_content` with its
+`contentId` instead — same status rules apply.
+
+### 2. Poll
+
+Call `get_upload_batch_content` with the `batchId` about **every 5 seconds** until `settled`
+is `true`.
+
+Give up after about **5 minutes**. Say that you stopped waiting and what the counts were when
+you did. Do not describe an unfinished batch as finished.
+
+`list_upload_batches` is the cheaper call if you only need "is it done yet" across a whole
+batch — it returns no file rows. Use `get_upload_batch_content` when you need to name
+individual files.
+
+### 3. Report periodically, not only at the end
+
+This is the part that matters most, and it is the one that is easy to skip.
+
+**While polling, tell the person where things stand roughly every 15–30 seconds.** Something
+as short as "18 of 30 accepted, 12 still being checked" is enough. A silent two-minute wait is
+indistinguishable from a hang, and the person cannot tell whether to keep waiting.
+
+**When `settled` becomes `true`, report once more and stop polling.** That final report needs:
+
+- how many reached `READY`, out of how many in the batch
+- every `REJECTED` file by name, each with its `rejectionReason`
+- anything left in a non-final state, if you stopped on the timeout rather than on `settled`
+
+Then stop. Do not keep polling a settled batch.
+
+### 4. Read the numbers correctly
+
+`statusCounts`, `pending`, and `settled` always describe the **whole batch**. `count`
+describes only the rows the call returned.
+
+That distinction bites when you filter. Asking for `status: ["READY"]` gives you just the
+accepted rows, which is often what you want for a list — but `count` is then the number of
+accepted files, not the batch size. Read progress from `statusCounts` and `pending`, never
+from `count`.
+
+Only `READY`, `REJECTED`, and `ABORTED` are final. `VALIDATING` and `EXPIRED` are both still
+counted in `pending`, so a batch is not settled while either remains.
+
+| Status | Means | Final |
+| --- | --- | --- |
+| `CREATED` | Destination minted, bytes not sent yet | no |
+| `UPLOADING` | Transfer in progress | no |
+| `VALIDATING` | Landed, being checked | no |
+| `READY` | Accepted. A `READY` image carries a short-lived `url` | yes |
+| `REJECTED` | Refused — report `rejectionReason` | yes |
+| `ABORTED` | Abandoned | yes |
+| `EXPIRED` | Destination went unused; can still land | no |
+
+## When a batch will never settle
+
+A batch whose files sit at `CREATED` forever was opened by something that could not send the
+bytes. That happens when `create_upload_batch` is called from a host with no way to make HTTP
+requests. Say so plainly rather than polling for five minutes: the fix is
+`create_browser_upload_link`, and the person uploads from their browser instead.
+
+A file stuck at `UPLOADING` on a large video usually means its multipart upload was never
+completed — `complete_upload` has to be called with the part ETags before the object is
+assembled. `list_upload_parts` shows what storage actually holds.
+
+## More detail
+
+`tools.md` has every tool's arguments and the full error vocabulary.

package/skills/extuitive/references/upload.md

@@ -0,0 +1,160 @@
+# `/extuitive upload` — send creative into a workspace
+
+Uploads a set of local files to an Extuitive workspace and reports which ones were accepted.
+
+Any folder or file paths the person gave follow the command in `$ARGUMENTS`. If they gave
+none, ask what to upload before doing anything else.
+
+## Before you start
+
+**The MCP tools never carry file bytes.** `create_upload_batch` returns presigned storage
+URLs; whoever has the files sends the bytes to those URLs directly.
+
+So decide which case you are in. The question is whether you can **read the person's files**,
+which is not the same as whether you can run code:
+
+- **You can open the paths they gave you.** Use `../scripts/upload.mjs`, as below.
+- **You cannot.** Do not call `create_upload_batch` — a batch you cannot fill sits unfinished
+  and later reads as a failed upload. Call `create_browser_upload_link`, give the person the
+  link, and skip to step 6.
+
+Some hosts run your code in a container that holds this skill but not the person's disk, so a
+working `node` and a readable `../scripts/upload.mjs` prove nothing about `~/creative/`. If a
+path they named does not open, you are in the second case — say so and hand over the link,
+rather than asking them to attach thirty files to the conversation.
+
+If the Extuitive tools are missing entirely, read `init.md` instead.
+
+## 1. Pick the workspace
+
+If one was already chosen earlier in this conversation, use it, and name it in the first thing
+you say — a mistaken choice is cheap to correct before the files move and expensive after.
+
+Otherwise call `list_workspaces`. If there is more than one and the person did not say which,
+ask; `select.md` covers how to lay the options out.
+
+Ask even when two rows share a `facebookAdAccountId`. They are two workspaces, and the files
+land in whichever one you use. **Do not pick by `role` or `isOwner`** — those govern who can
+reconnect Meta and say nothing about uploading, so a workspace where they are `viewer` may
+take files that the one where they are `owner` refuses. Describe both rows and let them
+choose.
+
+If it comes back **empty**, they have no workspace rather than no access. Read `connect.md`.
+There is nothing to upload into yet.
+
+## 2. Check the files against the limits
+
+Call `get_upload_limits` for the workspace. It returns `maxFiles`, `multipartThresholdBytes`,
+`recommendedPartBytes`, `maxParts`, and separate `maxBytes` and `contentTypes` for images and
+for video — the two ceilings differ by orders of magnitude, so check each file against the one
+for its own kind.
+
+Never hardcode these numbers. They are server-owned and they change.
+
+Set aside anything oversized or of a disallowed type and tell the person which and why. Do not
+silently drop files.
+
+## 3. Open the batch
+
+Call `create_upload_batch` with every remaining file declared at once: `fileName`,
+`contentType`, and the real size in `bytes`. Split into several batches if there are more than
+`maxFiles`.
+
+You get back a `batchId` and one destination per file, in the order you sent them. Keep the
+`batchId` — step 6 and `upload-status.md` both need it.
+
+If it refuses with `workspace_access_denied`, that workspace will not take these files no
+matter what its row said. Move to another workspace they have, and tell them the batch is in
+that one instead — including if it contradicts a workspace you named earlier. Do not retry the
+refused id, and do not explain the refusal in terms of their role; it does not follow from it.
+
+Each destination is one of two kinds:
+
+- **`PUT`** — the whole file in one request. Carries `url`, `headers`, and `expiresIn`.
+- **`MULTIPART`** — a large video. Carries `uploadId` and `partBytes`, and needs step 4 first.
+
+## 4. Sign the parts of any MULTIPART file
+
+Skip this if every destination is a `PUT`. Images never take the multipart path.
+
+Work out the part count yourself: `ceil(bytes / partBytes)`, using the `bytes` you declared in
+step 3 and the `partBytes` on that destination. You do not need to touch the file to do this.
+
+Then call `sign_upload_part` for each part number from 1 to N. Each returns `{ url, headers,
+expiresIn }`. Signing needs only the part number — no bytes, no checksum — so sign them all up
+front, before any transfer starts.
+
+Attach them to the destination as a `parts` array, each entry `{ partNumber, url, headers }`.
+
+A 4 GB video is roughly 256 parts. If that is more calls than you want to make in one go, say
+so and offer `create_browser_upload_link`, which handles large video without any of this.
+
+## 5. Send the bytes
+
+Write a plan file pairing each local path with its destination:
+
+```json
+{
+  "workspaceId": "<workspace id>",
+  "files": [
+    {
+      "path": "/abs/path/one.png",
+      "destination": { "method": "PUT", "...": "..." }
+    },
+    {
+      "path": "/abs/path/big.mp4",
+      "destination": {
+        "method": "MULTIPART",
+        "uploadId": "...",
+        "partBytes": 16777216,
+        "parts": [{ "partNumber": 1, "url": "...", "headers": {} }]
+      }
+    }
+  ]
+}
+```
+
+Run the script using the absolute path of the skill directory this file sits in:
+
+```bash
+node <skill directory>/scripts/upload.mjs plan.json
+```
+
+It prints a JSON report with `uploaded`, `multipart`, `failed`, `needsResign`, and
+`needsPartResign`. It handles retries, concurrency, and the CRC32C checksum each multipart
+chunk needs. It holds no credential and makes no MCP call — it only sends bytes to URLs you
+signed.
+
+Three things it hands back rather than solving itself:
+
+- **`multipart`** lists each large file with its `uploadId` and the `{ PartNumber, ETag }`
+  array storage returned. Call `complete_upload` once per entry, passing those parts through
+  exactly as given. Note the capitalisation — `PartNumber` and `ETag` are S3's own casing and
+  the only fields in this surface that are not camelCase. **A multipart file is not uploaded
+  until you do this.**
+- **`needsResign`** lists `contentId`s whose presigned PUT expired. Every URL in a batch is
+  signed at the same moment and lasts about 30 minutes, so in a large batch the last files can
+  expire while the first are still going. Call `resign_upload` for each, put the fresh
+  destination in a new plan, and run the script again for just those.
+- **`needsPartResign`** is the same problem on one part of a multipart file. Call
+  `sign_upload_part` again for that part number and re-run with just that file.
+
+## 6. Report what was actually accepted
+
+**A finished transfer is not an accepted file.** The bytes arriving only means storage has
+them; the file is then checked, and it can still be rejected.
+
+Poll `get_upload_batch_content` with the `batchId` about every 5 seconds until `settled` is
+`true`. Give up after about 5 minutes and say so rather than claiming success.
+
+**Report as you go — do not go silent.** Roughly every 15–30 seconds, say how many have
+reached `READY` out of the batch, so a long upload does not look like a hang. Report once more
+when `settled` is `true`.
+
+`upload-status.md` covers the polling, the status table, and the reporting rules in full. Read
+it rather than repeating the logic here.
+
+## 7. Stop there
+
+Report what landed and wait. Uploading is not an instruction to do anything further with the
+files.

package/skills/extuitive/scripts/upload.mjs

@@ -0,0 +1,340 @@
+#!/usr/bin/env node
+/**
+ * Sends creative files to storage for a batch the MCP tools already opened.
+ *
+ * This exists because the MCP tools deliberately never carry bytes: `create_upload_batch`
+ * returns presigned destinations and something has to PUT to them. Doing that by hand from a
+ * chat turn is not practical — every part of a large video needs a CRC32C over its own
+ * bytes, plus retries.
+ *
+ * **This script holds no credential and makes no MCP call.** It is handed presigned URLs and
+ * it sends bytes to them. Signing, opening the batch, completing a multipart upload, and
+ * reporting the outcome are all tool calls the agent makes, which is what keeps the access
+ * token in the host's credential store where it belongs. An earlier version called
+ * `sign_upload_part` itself over raw HTTP and therefore needed a token in its plan; that was
+ * a choice this script made, not something the protocol required, and it is gone.
+ *
+ * Usage:  node upload.mjs plan.json      (or: cat plan.json | node upload.mjs -)
+ *
+ * Plan:
+ *   {
+ *     "workspaceId": "...",
+ *     "files": [
+ *       { "path": "/abs/a.png", "destination": { …a PUT entry from create_upload_batch… } },
+ *       {
+ *         "path": "/abs/big.mp4",
+ *         "destination": {
+ *           "method": "MULTIPART",
+ *           "contentId": "...", "fileName": "...", "uploadId": "...", "partBytes": 16777216,
+ *           // One entry per part, from sign_upload_part. Parts are numbered from 1.
+ *           "parts": [{ "partNumber": 1, "url": "...", "headers": { … } }]
+ *         }
+ *       }
+ *     ]
+ *   }
+ *
+ * Prints a JSON report on stdout. Exit code is 0 when every file landed, 1 otherwise.
+ */
+import { readFile, open, stat } from "node:fs/promises";
+
+/** How many files move at once. Files, not parts: a multipart file is already several requests. */
+const FILE_CONCURRENCY = 4;
+const ATTEMPTS = 4;
+const RETRY_BASE_MS = 500;
+
+/** Castagnoli polynomial, reversed. Not the CRC32 used by zip — they are not interchangeable. */
+const CRC32C_POLYNOMIAL = 0x82f63b78;
+
+let crcTable = null;
+
+function getCrcTable() {
+  if (crcTable !== null) {
+    return crcTable;
+  }
+  const table = new Uint32Array(256);
+  for (let index = 0; index < 256; index += 1) {
+    let value = index;
+    for (let bit = 0; bit < 8; bit += 1) {
+      value = (value & 1) === 1 ? (value >>> 1) ^ CRC32C_POLYNOMIAL : value >>> 1;
+    }
+    table[index] = value >>> 0;
+  }
+  crcTable = table;
+  return table;
+}
+
+/**
+ * The value S3 expects for `x-amz-checksum-crc32c`: big-endian four bytes, base64.
+ *
+ * Byte order is not cosmetic. Little-endian produces a well-formed base64 string that S3
+ * rejects on every part, which reads as a signing problem rather than a checksum one.
+ */
+function crc32cBase64(bytes) {
+  const table = getCrcTable();
+  let crc = 0xffffffff;
+  for (let index = 0; index < bytes.length; index += 1) {
+    crc = (crc >>> 8) ^ table[(crc ^ bytes[index]) & 0xff];
+  }
+  const checksum = (crc ^ 0xffffffff) >>> 0;
+
+  const view = Buffer.alloc(4);
+  view.writeUInt32BE(checksum, 0);
+  return view.toString("base64");
+}
+
+function sleep(ms) {
+  return new Promise((resolve) => setTimeout(resolve, ms));
+}
+
+class UploadFailure extends Error {
+  constructor(message, options = {}) {
+    super(message);
+    this.name = "UploadFailure";
+    this.needsResign = options.needsResign === true;
+    this.partNumber = options.partNumber ?? null;
+  }
+}
+
+/**
+ * Retries only what retrying can fix.
+ *
+ * A 403 on a presigned URL is almost always an expired signature, and re-sending the same
+ * URL will fail identically however many times it is tried — it needs a new signature, which
+ * only the agent can ask for. Reporting it as needing a re-sign is the useful answer;
+ * retrying it would just spend four attempts arriving at the same place.
+ */
+async function sendWithRetry(label, send, { partNumber = null } = {}) {
+  let lastError = null;
+
+  for (let attempt = 1; attempt <= ATTEMPTS; attempt += 1) {
+    try {
+      const response = await send();
+      if (response.ok === true) {
+        return response;
+      }
+
+      if (response.status === 403) {
+        throw new UploadFailure(`${label}: signature rejected or expired (403).`, {
+          needsResign: true,
+          partNumber,
+        });
+      }
+      if (response.status < 500 && response.status !== 429) {
+        throw new UploadFailure(`${label}: refused with ${response.status}.`);
+      }
+      lastError = new UploadFailure(`${label}: ${response.status} from storage.`);
+    } catch (error) {
+      if (error instanceof UploadFailure && error.needsResign === true) {
+        throw error;
+      }
+      lastError = error instanceof Error ? error : new Error(String(error));
+    }
+
+    if (attempt < ATTEMPTS) {
+      await sleep(RETRY_BASE_MS * 2 ** (attempt - 1));
+    }
+  }
+
+  throw lastError ?? new UploadFailure(`${label}: failed.`);
+}
+
+/** One request, whole file. Headers go verbatim: the signature covers them. */
+async function sendSinglePut(file, destination) {
+  const body = await readFile(file.path);
+
+  await sendWithRetry(destination.fileName, () =>
+    fetch(destination.url, {
+      method: "PUT",
+      headers: destination.headers ?? {},
+      body,
+    }),
+  );
+
+  return {
+    kind: "put",
+    contentId: destination.contentId,
+    fileName: destination.fileName,
+  };
+}
+
+/**
+ * Send every chunk of a multipart upload against signatures the agent already obtained.
+ *
+ * The part count is checked rather than trusted. The agent derives it from the `bytes` it
+ * declared in the manifest, so a file edited between declaring and uploading would leave the
+ * last chunk unsent and the object silently short — cheaper to refuse here than to discover
+ * after `complete_upload` assembled something wrong.
+ */
+async function sendMultipart(file, destination) {
+  const { size } = await stat(file.path);
+  const partBytes = destination.partBytes;
+
+  if (typeof partBytes !== "number" || partBytes <= 0) {
+    throw new UploadFailure(`${destination.fileName}: destination has no usable partBytes.`);
+  }
+
+  const signedParts = Array.isArray(destination.parts) === true ? destination.parts : [];
+  if (signedParts.length === 0) {
+    throw new UploadFailure(
+      `${destination.fileName}: no presigned parts in the plan. Call sign_upload_part for parts 1..N and put them on the destination as "parts".`,
+    );
+  }
+
+  const expectedCount = Math.max(1, Math.ceil(size / partBytes));
+  if (signedParts.length !== expectedCount) {
+    throw new UploadFailure(
+      `${destination.fileName}: ${signedParts.length} presigned part(s) for a file needing ${expectedCount} at ${partBytes} bytes each. The file on disk is ${size} bytes; re-declare it and sign again.`,
+    );
+  }
+
+  const byNumber = new Map();
+  for (const part of signedParts) {
+    byNumber.set(part.partNumber, part);
+  }
+
+  const parts = [];
+  const handle = await open(file.path, "r");
+
+  try {
+    for (let partNumber = 1; partNumber <= expectedCount; partNumber += 1) {
+      const signed = byNumber.get(partNumber);
+      if (signed === undefined) {
+        throw new UploadFailure(
+          `${destination.fileName}: no presigned URL for part ${partNumber}.`,
+          { partNumber },
+        );
+      }
+
+      const offset = (partNumber - 1) * partBytes;
+      const length = Math.min(partBytes, size - offset);
+      const chunk = Buffer.alloc(length);
+      await handle.read(chunk, 0, length, offset);
+
+      // Computed over the exact bytes being sent. The upstream signed this header, so S3
+      // rejects the part if it is absent or does not match.
+      const checksum = crc32cBase64(chunk);
+
+      const response = await sendWithRetry(
+        `${destination.fileName} part ${partNumber}`,
+        () =>
+          fetch(signed.url, {
+            method: "PUT",
+            headers: { ...signed.headers, "x-amz-checksum-crc32c": checksum },
+            body: chunk,
+          }),
+        { partNumber },
+      );
+
+      const eTag = response.headers.get("etag");
+      if (eTag === null) {
+        throw new UploadFailure(
+          `${destination.fileName} part ${partNumber}: storage returned no ETag.`,
+          { partNumber },
+        );
+      }
+      parts.push({ PartNumber: partNumber, ETag: eTag });
+    }
+  } finally {
+    await handle.close();
+  }
+
+  return {
+    kind: "multipart",
+    contentId: destination.contentId,
+    fileName: destination.fileName,
+    uploadId: destination.uploadId,
+    parts,
+  };
+}
+
+async function sendOne(file) {
+  const destination = file.destination;
+  return destination.method === "MULTIPART"
+    ? sendMultipart(file, destination)
+    : sendSinglePut(file, destination);
+}
+
+async function run(plan) {
+  const queue = [...plan.files];
+  const uploaded = [];
+  const multipart = [];
+  const failed = [];
+  const needsResign = [];
+  const needsPartResign = [];
+
+  async function worker() {
+    for (;;) {
+      const file = queue.shift();
+      if (file === undefined) {
+        return;
+      }
+
+      const destination = file.destination ?? {};
+
+      try {
+        const result = await sendOne(file);
+        if (result.kind === "multipart") {
+          multipart.push({
+            contentId: result.contentId,
+            fileName: result.fileName,
+            uploadId: result.uploadId,
+            parts: result.parts,
+          });
+        } else {
+          uploaded.push({ contentId: result.contentId, fileName: result.fileName });
+        }
+      } catch (error) {
+        const entry = {
+          fileName: destination.fileName ?? file.path,
+          contentId: destination.contentId,
+          error: error instanceof Error ? error.message : String(error),
+        };
+        failed.push(entry);
+
+        if (error instanceof UploadFailure && error.needsResign === true) {
+          if (destination.method === "MULTIPART") {
+            needsPartResign.push({
+              fileName: entry.fileName,
+              contentId: entry.contentId,
+              uploadId: destination.uploadId,
+              partNumber: error.partNumber,
+            });
+          } else {
+            needsResign.push(entry.contentId);
+          }
+        }
+      }
+    }
+  }
+
+  await Promise.all(
+    Array.from({ length: Math.min(FILE_CONCURRENCY, plan.files.length) }, worker),
+  );
+
+  return { uploaded, multipart, failed, needsResign, needsPartResign };
+}
+
+async function readPlan(source) {
+  if (source === "-" || source === undefined) {
+    const chunks = [];
+    for await (const chunk of process.stdin) {
+      chunks.push(chunk);
+    }
+    return JSON.parse(Buffer.concat(chunks).toString("utf8"));
+  }
+  return JSON.parse(await readFile(source, "utf8"));
+}
+
+const plan = await readPlan(process.argv[2]);
+if (Array.isArray(plan.files) === false || plan.files.length === 0) {
+  console.error("Plan needs a non-empty files array.");
+  process.exit(2);
+}
+
+const report = await run(plan);
+console.log(JSON.stringify(report, null, 2));
+
+// Transfers finishing is not the same as files being accepted. Every entry in `multipart`
+// still needs a complete_upload call, and everything still needs polling with
+// get_upload_batch_content; this only reports what reached storage.
+process.exit(report.failed.length === 0 ? 0 : 1);

package/src/constants.mjs

@@ -0,0 +1,63 @@
+/**
+ * Values that appear in more than one place, defined once.
+ */
+
+/**
+ * The name people type. This is the unscoped launcher package on npm (`packages/extuitive`),
+ * which depends on `@extuitive/skill` — the package this file ships in — and does nothing
+ * but import `bin/cli.mjs`. The usage text shows the launcher's name because that is the
+ * command, not the implementation.
+ */
+export const PACKAGE_NAME = "extuitive";
+
+/** `owner/repo`, the one string that has to change if the repository moves. */
+export const GITHUB_REPO = "fl100inc/extuitive-skill";
+
+/**
+ * How to invoke this tool, for every message that tells someone to run it again.
+ *
+ * `npx extuitive` resolves the launcher from the npm registry, so it works from any
+ * directory with nothing installed. `npx github:fl100inc/extuitive-skill` still runs the
+ * unreleased `main` for anyone who wants that, but it is not what a fix message should
+ * suggest.
+ */
+export const NPX_COMMAND = `npx ${PACKAGE_NAME}`;
+
+/** Overridable with `--endpoint` for development against a local dev server. */
+export const DEFAULT_MCP_ENDPOINT = "https://www.extuitive.com/mcp";
+
+/**
+ * The name every host registers the server under.
+ *
+ * Not one of Claude Code's reserved names (`workspace`, `claude-in-chrome`, `computer-use`,
+ * `Claude Preview`, `Claude Browser`), which it refuses at add time.
+ */
+export const MCP_SERVER_NAME = "extuitive";
+
+/**
+ * One skill, whose directory name is also its command name.
+ *
+ * The CLI hosts key a skill on its directory, so this string is what someone types:
+ * `/extuitive` in Claude Code, `$extuitive` in Codex. Claude Desktop has no prefix at all
+ * and selects on the description instead, which is why `invocationNote` exists on a host
+ * rather than a prefix being assumed everywhere.
+ *
+ * The individual jobs are arguments to it rather than skills of their own — `/extuitive
+ * upload` — which is why there is only one entry here. It must equal the `name` in
+ * SKILL.md's frontmatter.
+ */
+export const SKILL_NAMES = ["extuitive"];
+
+/** The subcommands the skill routes, used for the usage text and nothing else. */
+export const SKILL_COMMANDS = ["init", "select", "upload", "upload-status", "connect"];
+
+/**
+ * What to suggest typing once the install is done.
+ *
+ * Natural language rather than `$extuitive init`, because that is how the skill is meant to
+ * be reached and because the slash-vs-dollar prefix differs by host. The first one routes to
+ * `init`, which verifies the connection end to end and is the right first thing to do; the
+ * second is the job most people installed it for. Both phrases appear in SKILL.md's
+ * description so the host's skill matcher recognises them.
+ */
+export const EXAMPLE_PROMPTS = ["Check my Extuitive connection", "Upload these images to Extuitive"];