@heyamiko/amiko-cli 0.17.1 → 0.18.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@heyamiko/amiko-cli",
-  "version": "0.17.1",
+  "version": "0.18.0",
   "description": "Amiko CLI — swap tokens, manage credits, bridge cross-chain, and call marketplace agents",
   "type": "module",
   "bin": {

package/skills/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: amiko-cli
-description: The Amiko CLI lets an agent act on the Amiko platform end-to-end — read platform notifications (friend requests, mentions, system alerts), search and write **cross-agent memories** about the owner (what other agents already know — preferences, decisions, facts), manage Solana/Base wallets (create, swap via Jupiter, bridge USDC via Across, transfer tokens to external addresses), top up and spend credits, generate media — images, video, speech, music, and SFX — via Create Studio (`amiko create`, async and charged on success), call paid MPP marketplace services (X/Twitter search, Amazon product search, TTS/STT, AI chat), manage the twin's identity and drive (files, folders, RAG), voice and avatar, and social graph (friends, follows, private friend nicknames, posts/notes with titles, images and document attachments, comments, who liked a post, feed). Auth is automatic when run from the agent's workspace folder; payments are platform-custodied (no keys on disk). The owner's DMs and group chats are `amiko chat` (list / read / send / mark everything read / see which chats have unread @mentions or replies to the owner (`chat list --mentions`) / organize chats into private folders (`chat lists`) / create + manage group chats AS the owner, including sending GIFs (`chat gifs` search + `chat send --gif`), sharing a group's invite/join link + QR and @all group announcements, 人对人); the agent's OWN sessions are the openhermit gateway's session_list / session_send (AS the agent) — different identities, different surfaces. Use this skill whenever the user asks about their Amiko notifications, chats/DMs, drive, memory, social graph, wallets, credits, or marketplace services — anything that would show up in their Amiko account or cost AMIKO/credits.
+description: The Amiko CLI lets an agent act on the Amiko platform end-to-end — read platform notifications (friend requests, mentions, system alerts), search and write **cross-agent memories** about the owner (what other agents already know — preferences, decisions, facts), manage Solana/Base wallets (create, swap via Jupiter, bridge USDC via Across, transfer tokens to external addresses), top up and spend credits, generate media — images, video, speech, music, and SFX — via Create Studio (`amiko create`, async and charged on success), call paid MPP marketplace services (X/Twitter search, Amazon product search, TTS/STT, AI chat), manage the twin's identity and drive (files, folders, RAG), voice and avatar, and social graph (friends, follows, private friend nicknames, posts/notes with titles, images and document attachments, comments, who liked a post, feed). Auth is automatic when run from the agent's workspace folder; payments are platform-custodied (no keys on disk). The owner's DMs and group chats are `amiko chat` (list / read / send / mark everything read / see which chats have unread @mentions or replies to the owner (`chat list --mentions`) / organize chats into private folders (`chat lists`) / create + manage group chats AS the owner, run chat polls (`chat poll` create / vote / close, quizzes included), including sending GIFs (`chat gifs` search + `chat send --gif`), sharing a group's invite/join link + QR and @all group announcements, 人对人); the agent's OWN sessions are the openhermit gateway's session_list / session_send (AS the agent) — different identities, different surfaces. Use this skill whenever the user asks about their Amiko notifications, chats/DMs, drive, memory, social graph, wallets, credits, or marketplace services — anything that would show up in their Amiko account or cost AMIKO/credits.
 homepage: https://platform.heyamiko.com
 metadata: {"openclaw":{"emoji":"🤖","requires":{"bins":["node"]}}}
 ---
@@ -33,13 +33,13 @@ Call your shell tool (your runtime calls it `bash`, `shell`, `run`, or similar)
 | "what comments are on my post?" | shell → `amiko post comments --id <postId>` |
 | "谁给我点赞了 / which friends liked my post?" | shell → `amiko post likers <postId>` (own posts only) → cross-reference ids against `amiko friends list` |
 | "我有多少好友 / how many friends do I have?" | shell → `amiko friends list` — read the header total, don't count rows |
-| "发个笔记 / post this photo as a note" | draft-first → `amiko post create --title "…" --media ./photo.webp --draft` → show the owner → `amiko post publish <id> --yes` |
-| "post the audio/image from my Drive" | shell → `amiko drive list --json` (copy the `id`) → `amiko post create --title "…" --media drive:<docId> --draft` → owner reviews → `amiko post publish <id> --yes` |
-| "share this PDF on my feed" | `amiko post create --title "…" --doc ./report.pdf --draft` → owner reviews → `amiko post publish <id> --yes` |
+| "发个笔记 / post this photo as a note" | draft-first (`create` drafts by default) → `amiko post create --title "…" --media ./photo.webp` → `amiko post show <id>` show the owner → `amiko post publish <id> --yes` |
+| "post the audio/image from my Drive" | shell → `amiko drive list --json` (copy the `id`) → `amiko post create --title "…" --media drive:<docId>` → `amiko post show <id>` owner reviews → `amiko post publish <id> --yes` |
+| "share this PDF on my feed" | `amiko post create --title "…" --doc ./report.pdf` → `amiko post show <id>` owner reviews → `amiko post publish <id> --yes` |
 | "关注 / follow @mars" | shell → `amiko users follow mars` (confirm first — it notifies them) |
 | "what did the people I follow post?" | shell → `amiko feed --type following` |
-| "save this as a post draft, don't publish yet" | shell → `amiko post create --content "…" --draft` |
-| "publish that draft" | shell → `amiko post drafts` (copy the id) → show the owner → `amiko post publish <postId> --yes` |
+| "save this as a post draft, don't publish yet" | shell → `amiko post create --content "…"` (drafts by default; `--draft` is optional/back-compat) |
+| "publish that draft" | shell → `amiko post drafts` (copy the id) → `amiko post show <postId>` show the owner → `amiko post publish <postId> --yes` |
 | "delete / 撤下 that post (it went out wrong)" | shell → `amiko post list` (copy the id) → confirm which one → `amiko post delete <postId> --yes` |
 | "search memory for X" | shell → `amiko memory search "X"` |
 | "share the group's invite link" (asked by an admin) | shell → `amiko chat group info "<group>"` (confirm they're admin) → `amiko chat group invite "<group>"` |
@@ -48,6 +48,9 @@ Call your shell tool (your runtime calls it `bash`, `shell`, `run`, or similar)
 | "did Sophie read my message about the demo?" | shell → `amiko chat read "Sophie"` (find the owner's message, copy its `id`) → `amiko chat receipts <messageId>` |
 | "pin that hackathon message in the builders group" | shell → `amiko chat read "<group>"` (find the message, copy its `id`) → `amiko chat pin <messageId> --yes` |
 | "what's pinned in the team chat?" | shell → `amiko chat pinned "<group>"` |
+| "start a poll in the team chat: pizza or sushi?" | confirm the question + options with the owner → `amiko chat poll create "<group>" "Pizza or sushi?" --option Pizza --option Sushi --yes` |
+| "vote Sushi on Mars's lunch poll" | shell → `amiko chat read "<group>"` (find the 📊 poll, copy its `id`) → `amiko chat poll vote <messageId> Sushi --yes` |
+| "how's my poll doing? / end the poll" | shell → `amiko chat poll show <messageId>` · to end it (permanent) → `amiko chat poll close <messageId> --yes` |
 | "mark all my chats as read" | shell → `amiko chat mark-read --all --yes` (after the owner confirms — it clears every badge and senders see read ticks) |
 | "any unread mentions or replies to me?" | shell → `amiko chat list --mentions` (chats whose unread messages @mention the owner or reply to them) |
 | "what chat lists do I have? what's in my Work list?" | shell → `amiko chat lists` |
@@ -73,7 +76,7 @@ Discover everything via `amiko --help` (or `amiko <group> --help` / `amiko <grou
 
 ## Critical Rules
 
-1. **Every paid / value-moving command is hard-gated on `--yes` in a non-interactive shell.** The CLI refuses to run `search *`, `markets *`, `create *`, `card mint`, `credits topup`, `wallets swap send`, `wallets bridge send`, `wallets transfer` unless `--yes` is passed. The refusal prints the cost and the re-run command. **Quote the cost, get explicit approval, THEN append `--yes`.** For `create *` there is a step before that — propose the model and settings and get the owner's sign-off on the *plan* first; see **Proposing, then quoting, before you generate**. The same `--yes` gate also covers **free outward social actions** — `chat send`, `chat pin` (the whole chat sees a pinned-message announcement), `chat group create`, `chat group add` (real people see them, so get the owner's explicit approval for the action itself) — and **destructive ops** like `chat unpin` (removes the pin for everyone), `chat mark-read --all` (irreversibly marks every conversation read — senders see read ticks), `chat group remove/leave/rename/promote/mention-all`, `chat lists create/rename/add/remove/delete` (private to the owner, but they reshape the owner's chat UI), `friends nickname set/remove` (private to the owner, but it changes how that friend is displayed everywhere in the owner's apps), `twin update --public`, `drive delete`, `drive share` / `drive folder share` (exposes the file — or the folder's ENTIRE subtree — to anyone with the link), `friends remove`, `friends reports request`, `avatar update`, `voice reset`, `review reject`. **For these free actions never mention cost, never say "the cost is 0", and never call it a paid operation** — ask for plain confirmation of the action itself (e.g. "Send "hi" to Mars — go ahead?").
+1. **Every paid / value-moving command is hard-gated on `--yes` in a non-interactive shell.** The CLI refuses to run `search *`, `markets *`, `create *`, `card mint`, `credits topup`, `wallets swap send`, `wallets bridge send`, `wallets transfer` unless `--yes` is passed. The refusal prints the cost and the re-run command. **Quote the cost, get explicit approval, THEN append `--yes`.** For `create *` there is a step before that — propose the model and settings and get the owner's sign-off on the *plan* first; see **Proposing, then quoting, before you generate**. The same `--yes` gate also covers **free outward social actions** — `chat send`, `chat pin` (the whole chat sees a pinned-message announcement), `chat poll create` / `chat poll vote` / `chat poll retract` (the chat sees the poll and the updated results), `chat group create`, `chat group add`, `friends add` / `friends accept` (real people see them — a friended user is notified — so get the owner's explicit approval for the action itself) — and **destructive ops** like `chat unpin` (removes the pin for everyone), `chat poll close` (ends the poll for everyone — it can't be reopened), `chat mark-read --all` (irreversibly marks every conversation read — senders see read ticks), `chat group remove/leave/rename/promote/mention-all`, `chat lists create/rename/add/remove/delete` (private to the owner, but they reshape the owner's chat UI), `friends nickname set/remove` (private to the owner, but it changes how that friend is displayed everywhere in the owner's apps), `twin update --public`, `drive delete`, `drive share` / `drive folder share` (exposes the file — or the folder's ENTIRE subtree — to anyone with the link), `friends remove`, `friends reports request`, `avatar update`, `voice reset`, `review reject`. **For these free actions never mention cost, never say "the cost is 0", and never call it a paid operation** — ask for plain confirmation of the action itself (e.g. "Send "hi" to Mars — go ahead?").
 2. **After every paid command, report the remaining balance.** The CLI prints a `Balance: N credits` line — include that figure in your reply.
 3. **Never retry a failed command.** Report and stop. Every paid call costs tokens even on failure.
 4. **Auth is automatic.** Never suggest `amiko login` / `amiko connect`. Run from the agent's workspace folder; if anything looks off, `amiko accounts` shows the resolved `userId` / `twinId`.
@@ -271,6 +274,17 @@ MiniMax Hailuo (02/2.3) is silent — there is no CLI mux step to attach a separ
 - **Pinned messages** — `amiko chat pin <messageId>`, `amiko chat unpin <messageId>`, `amiko chat pinned <target>`. Pins are **conversation-wide**: everyone sees them, and `pin` posts an "X pinned a message" announcement to the whole chat, so both `pin` and `unpin` are `--yes`-gated with a preview of the target message. The owner won't give you a message id — get it from `amiko chat read <target>` (or `amiko chat pinned <target>` when unpinning), matching by **content**. In **groups** only admins can pin/unpin (a 403 names that rule; check roles with `amiko chat group info`, report it, don't retry); in DMs either side can. Max 20 pins per conversation — a "Pin limit reached" error means unpin one first, ask the owner which. Re-pinning an already-pinned message is a harmless no-op. `pinned <target>` is an ungated read (same targets as `chat read`: conversation id, user id, `@handle`, or name; it never creates a DM) listing pins oldest-first with each message's `id` and who pinned it.
 - **Mark all read** — `amiko chat mark-read --all` marks EVERY conversation read as the owner in one shot: unread badges clear on all the owner's devices, the owner's chat/mention notifications clear, and senders see read ticks on their messages (the ~50 most recent conversations flip live; the rest on their next refresh). Irreversible — there is no "mark unread" — so it's `--yes`-gated: only run it when the owner explicitly asks to clear everything, never as routine tidying. The success line won't say how many conversations were affected (the server doesn't report a full count); don't invent a number.
 
+### Polls — `amiko chat poll`
+
+Chat polls in the owner's DMs and groups, **as the owner**: `create <target> <question> --option <text>…`, `show <messageId>`, `vote <messageId> <choice…>`, `retract <messageId>`, `close <messageId>`.
+
+- **Create:** 2–12 unique `--option`s (≤100 chars each; question ≤300). `--multiple` allows several answers, `--anonymous` hides who voted for what, `--quiz --correct <n>` (1-based) makes a quiz with one right answer, optional `--explanation` (≤200). Same targets as `chat send` (a DM with a person is opened after approval). Polls only work in **DMs and groups with at least two people** — never in channels, support chats, or the owner's own chat with you (their twin); the CLI and server both refuse those. Confirm the question and options with the owner before running with `--yes`.
+- **Find the poll:** the owner won't give you an id. `amiko chat read <target>` shows each poll as `📊 <question>` with its options, tallies and `●` on the owner's own choices — copy that message's `id`. `amiko chat poll show <id>` gives the full picture: voter names (non-anonymous polls), the owner's current vote, and which actions are still open.
+- **Vote:** `vote <id> <choice…>` **sets the owner's answer to exactly these choices** (replacing any earlier vote). A choice is the option's number from `show`, its text, or its id. Single-answer polls take one choice; for multi-answer polls pass them all. `retract <id>` removes the vote. You vote **as the owner** — never pick on your own; ask which option the owner wants.
+- **Quizzes:** results and the answer stay hidden until the owner answers; the answer is **final** (no changing or retracting); the owner can't answer their own quiz. Don't reveal a quiz's answer from a poll the owner created to other people.
+- **Close:** only the poll's creator can `close` it, and it's **permanent** — votes stop and a quiz's answer is revealed to everyone. Only close when the owner asks.
+- Errors like "This poll has ended", "quiz answers are final", or "Polls are only available in…" are final — report them, don't retry. `create`/`vote`/`retract`/`close` need `--yes` in your shell (see Critical Rules); `show` is a free, ungated read.
+
 ### Group chats — `amiko chat group`
 
 Create and manage the owner's group chats: `create <name> --member <who>…`, `list`, `info <group>`, `invite <group>`, `rename <group> <newTitle>`, `add <group> --member <who>…`, `remove <group> --member <who>…`, `promote <group> --member <who>`, `mention-all <group> <on|off>`, `leave <group>` (alias `delete`).
@@ -352,7 +366,9 @@ Two different relationships — pick the one the owner actually asked for:
 
 **"Notes" and "posts" are the same thing.** The web app calls the feed surface *notes* (小红书-style card grid); the CLI calls it `post` / `feed`. When the owner says "发个笔记" / "post a note", that is `amiko post create` — there is no separate notes command.
 
-> **⚠️ Draft-first, publish on the owner's word.** Publishing is outward and permanent — everyone sees it, and you cannot edit a published post from the CLI. Publishing goes wrong most often in exactly three ways: a **wrong link** in the body, a **stray test post** while you're trying out a format, and the **wrong version** of something you drafted more than once. So the default workflow is: **save a draft first** (`amiko post create … --draft`), show the owner the exact copy (and, for an image/media note, the actual attachment and any link in the body), and publish **only after they say go** — then `amiko post publish <postId> --yes`. Publishing and deleting are gated: `amiko post publish`, `amiko post delete`, and a direct `amiko post create` (no `--draft`) all **refuse without `--yes`** and will not run until the owner has approved the specific thing. `--yes` is *not* yours to add on your own initiative — add it only once the owner has seen what goes out and approved it. When in doubt, draft it and ask; do not publish to "check how it looks." (Scheduled/automated posting the owner set up is the exception — those runs carry `--yes` because the owner pre-approved the job.)
+> **⚠️ Draft-first, publish on the owner's word.** Publishing is outward and permanent — everyone sees it, and you cannot edit a published post from the CLI. Publishing goes wrong most often in exactly three ways: a **wrong link** in the body, a **stray test post** while you're trying out a format, and the **wrong version** of something you drafted more than once. So `amiko post create` **saves a draft by default** — a draft is owner-only, editable, and invisible to everyone else, so it is safe and never prompts. Show the owner the exact copy (`amiko post show <id>` — for an image/media note also the actual attachment and any link in the body), and publish **only after they say go**: `amiko post publish <postId> --yes`. The **outward** steps are what's gated: `amiko post publish`, `amiko post delete`, and `amiko post create --publish` (the one-step create-and-publish shortcut) all **refuse without `--yes`** and will not run until the owner has approved the specific thing. A bare `amiko post create` does NOT need `--yes` — it only makes a draft. `--yes` is *not* yours to add on your own initiative — add it only once the owner has seen what goes out and approved it. When in doubt, draft it and ask; do not publish to "check how it looks."
+
+> **⏰ Schedule mode — publishing needs `--publish` (the job is the owner's pre-approval).** When this run is a scheduled task — you'll see a `### Scheduled Task` block in your context — the owner set the job up in advance, so it *is* the approval. But draft-first still applies to the raw command: a bare `amiko post create` **drafts** even inside a schedule, so a post that stops appearing on the feed is the tell that the `--publish` flag is missing. If the job's purpose is to publish to the feed, create-and-publish in one step: **`amiko post create --publish --yes …`** (or, if you drafted first, `amiko post publish <id> --yes`). The `--yes` is what carries the owner's standing approval for the scheduled job — outside a schedule you would never add it on your own. If the job only says "draft" (e.g. a review-before-send flow), keep the bare `amiko post create` and deliver the draft to the owner instead of publishing.
 
 **A note is a card, so give it a `--title`.** `--title` (max 150 chars) is the heading shown on the feed card and is what a reader scans before deciding to open it; `--content` is the body they see after. For an image note, the title is doing nearly all the work — always pass one. Nothing about a published post can be edited from the CLI, so get the title right the first time — or save it with `--draft` and review it with the owner before publishing.