@prismer/runtime 2.0.8 → 2.2.55

package/built-in-skills/tasks/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: tasks
+scope: common
 description: Manage Prismer workspace tasks across the full Kanban lifecycle — create, list, inspect, update, complete, approve, reject, cancel. Use whenever the user asks to add a card to the board, dispatch work to another agent, track progress, or move a task between states. Executes via the `cloud task` CLI.
 ---
 
@@ -11,13 +12,22 @@ Use this skill to drive the **workspace Kanban** end-to-end. Tasks are durable b
 
 When the user asks you to **assign / delegate / hand off** work to ANOTHER agent (e.g. "create kanban tasks and assign to @research-agent", "give this to Bob"):
 
-1. **Call `cloud task create --assignee-name <agent>` (or `--assignee-id`).** That is the ONLY legitimate delegation path. The cloud routes the task to the target agent's daemon, and the target agent picks it up via its own dispatch loop.
+1. **Call `cloud task create --assignee-name <agent>` (or `--assignee-id`).** That is the ONLY legitimate delegation path. A delegation is a **tracked board card that ALSO auto-dispatches**: the card shows on the Kanban (留痕/可观测) *and* the cloud routes it to the target agent's daemon the moment the assignee is set — the target picks it up via its own dispatch loop, no manual "drag to Running" needed. (A `--no-card` pure run exists for internal orchestrator sub-steps that should NOT surface a card.)
 2. **STOP** as soon as `cloud task create` returns task IDs. Reply to the user with the IDs / titles. **Do not** invoke any other tool to "also do the research yourself" or "make sure it gets done".
 3. **NEVER use a generic `Task` / subagent / fan-out / parallel-agent tool to silently do the work in-process.** That bypasses the kanban board, the assignee never sees the card, the user's mental model ("an agent is working on this") is violated, and the delegation is fake. If you find yourself reaching for any tool whose name is "Task", "Subagent", "Worker", "Fanout", "ParallelAgents", or anything else that spawns an inline executor — **stop and re-read this section**.
 4. The phrase **"I've also started working on these"** after a `cloud task create` is a red flag that you violated rule 3. The correct phrase is **"Tasks created and assigned. @research-agent will pick up the cards."**
 
 This is non-negotiable. Bypassing it makes the agent ecosystem look broken even when the cards are correct, because the user sees the answer come back too fast and notices that the supposed assignee was never @-mentioned in the conversation.
 
+## ↩️ 结果回流 — 委派后怎么拿到结果（HARD）
+
+委派出去之后，**结果不会自动回流**到你的对话或 run —— 没有回调、没有自动推送。被派的 agent 在它**自己的独立 context** 里执行（不进你当前这条会话、也不会在这里发言），产物落在 **task 卡 + 看板**上。所以：
+
+- **要看结果，你必须主动拉**：`cloud task get <taskId>` 读 `status` / `result` / 附件。`status=completed` 才算交付；`review` 等你 approve/reject。
+- **编排节奏**：`cloud task create --assignee-name <peer>` → 拿到 taskId → 反复 `cloud task get <taskId>` 直到 `status` 进终态 → 读产物 → 决定下一步。（有 `cloud task wait <id>` 时优先用它，省手搓轮询。）
+- **「看不到对方回复 ≠ 它没在干」**。被派 agent 沉默是正常的——它在独立 context 里跑，结果只在卡上。**绝不要**因为对话里没动静就自己把活重做一遍（那就是影子执行，违反上面的 Hard rules）。
+- 派完先停、把 taskId 报给用户；之后用 `cloud task get` 跟进，而不是把委派和自办混在一条回复里。
+
 ## When to use
 
 - The user asks to **create**, **assign**, **schedule**, or **track** work ("add to kanban", "give Bob this task", "remind me to ship X by Friday").
@@ -33,11 +43,17 @@ This is non-negotiable. Bypassing it makes the agent ecosystem look broken even
 
 ```
 pending → assigned → running → review → completed | failed | cancelled
-                                     ↓
-                                  approved / rejected (review only)
+              ↑                     ↓
+              └──── blocked ────────┤  (unblock returns to assigned)
+                                    ↓
+                             awaiting_approval
+                                    ↓
+                        approved / rejected (back to review)
 ```
 
-A `work_item` shows on the Kanban; a `goal` shows on the Goals lane. Filter at list time with `--kind work_item,goal` if you only want board projection.
+Nine-state lifecycle: `pending / assigned / running / review / blocked / awaiting_approval / completed / failed / cancelled`. `awaiting_approval` cards stay visible on the review column — never treat them as gone. `blocked` has its own column.
+
+A `work_item` shows on the Kanban; a `goal` shows on the Goals lane. Filter at list time with `--kind work_item,goal` if you only want board projection. A **delegation** (`cloud task create --assignee-name …`) is a `work_item` board card that also auto-dispatches (`dispatchPolicy=on-assign`) — it is BOTH visible on the board AND executing. A `work_item` you create for a human (or to drive yourself via the UI) stays `manual`: it only runs on an explicit drag-to-Running. **Only globally-visible formal tasks are board cards** — a chat `@mention` is a session-internal run, NOT a board card, and never produces one.
 
 ## Permission model (v2.0 — `release 200` state machine)
 
@@ -267,7 +283,7 @@ You MUST also confirm:
 
 ### As a verifier agent (when you receive task.verify.requested)
 
-You will receive an IM message:
+You will receive a task dispatch message:
 
     type: task.verify.requested
     taskId: ...
@@ -332,7 +348,7 @@ cloud task apply-template <taskId> --template <id>       # adopt a template
 
 ## 产物输出（user-deliverable）
 
-**交付是显式的**（release202/09 P2 起）。把文件写进 `artifacts/` **不会**自动交付——`artifacts-watcher` auto-scan 默认 **OFF**（`2f3e901b` retire watcher auto-scan）。每个要给用户的产物都必须显式跑一条 `cloud deliver` / `cloud task attach`。
+**文件交付是显式的**（release202/09 P2 起）。把文件写进 `artifacts/` **不会**自动交付——`artifacts-watcher` auto-scan 默认 **OFF**（`2f3e901b` retire watcher auto-scan）。仅当 carrier 决策是文件时，才使用 `cloud deliver` / `cloud task attach` 显式交付该文件。
 
 ```bash
 # 1) 把最终产物写到 artifacts/（draft / 中间文件走 scratch，不会被交付）
@@ -345,39 +361,38 @@ cloud task attach  "${PRISMER_ARTIFACTS_DIR}/my-report.md"   # 动作 ③：挂
 
 > ⚠️ **写进 `artifacts/` ≠ 交付**。没有 auto-scan。每个文件都要显式 `cloud deliver`（聊天回复产物）或 `cloud task attach`（任务卡产物），否则用户收不到。`artifacts/` 放最终交付物，draft / 中间文件走 `scratch/`。
 
-> **Hermes 适配额外要求**：hermes 没有 per-dispatch env id（`PRISMER_RUN_ID` / `PRISMER_CONVERSATION_ID` 均 unset），裸 `cloud deliver <path>` 找不到 dispatch 会报错。必须从 `<execution_context>` 抄 `<run_id>` 和 `<conversation_id>` 当 flag 传：
+> **常态（含 hermes）：直接 `cloud deliver <abs-path>` 即可**——hermes 虽没有 per-dispatch env id（`PRISMER_RUN_ID` / `PRISMER_CONVERSATION_ID` unset），但 daemon（release203/15c）会按你的 agent 身份自动关联你**当前**的 dispatch，补全 run/conversation。spawn 适配器（claude-code / codex）env 已注入，同样无需 flag。
+> **仅以下情形才手传 flag**：(a) 你要对**另一个**（非当前）dispatch 交付；(b) daemon 返回 **409 歧义**（同 agent 多个并发 dispatch 无法区分）。这时才从 `<execution_context>` 抄 `<run_id>` / `<conversation_id>`：
 > ```bash
 > cloud deliver "<abs-path>" --run-id "<run_id>" --conversation-id "<conversation_id>"
 > ```
-> spawn 适配器（claude-code / codex / openclaw）env 已注入，无需这两个 flag。详见 `office-artifacts` SKILL（唯一交付契约）。
+> 详见 `office-artifacts` SKILL（唯一交付契约）。
 
 **Workflow**：
 
-1. 中间脚本 / draft 写到 `${PRISMER_SCRATCH_DIR}/`（scratch，不进 IMAsset、不交付）
+1. 中间脚本 / draft 写到 `${PRISMER_SCRATCH_DIR}/`（scratch，不进 Asset、不交付）
 2. 最终产物写到 `${PRISMER_ARTIFACTS_DIR}/`（agent process env; physically `${TASK_WORKDIR}/artifacts/`）
 3. **显式交付每个产物**：聊天回复用 `cloud deliver <abs-path>`（动作 A），任务卡用 `cloud task attach <abs-path>`（动作 ③）。命令成功会打印 `assetId`
 
-**禁止**：
-
-- 不要在对话里贴大段 markdown 充当 "产物"——实际产物必须落文件
-- 不要把 draft / 中间产物丢进 `artifacts/`——那里只放最终交付物（draft 走 `scratch/`）
-- 不要以为写进 `artifacts/` 就交付了——没有 auto-scan，必须显式 `cloud deliver` / `cloud task attach`
+### Carrier 选择与显式交付
 
-### 文档型交付物 = markdown 文件（不是 chat 长文）
+carrier 优先级是：**用户明确要求 > Runtime carrier directive > 已选内容 skill > task 默认**。`tasks` skill 只管任务与回执，不擅自把内容改成 Markdown 文件、Asset 或 Memory Page。
 
-**SOP（适用于一切「文档型」交付物：方案 / 报告 / 调研 / 规格 / 总结 / 评审记录…）**：
+1. **inline PKF**：按 Runtime carrier directive 返回单一 inline PKF ContentBlock / sentinel。不写文件，不调 `cloud deliver` / `cloud task attach`，不并行产出 `.md` / `.html` / `.css` / `.js`。
+2. **用户明确要求文件**：按用户指定格式或内容 skill 决定的格式写入 `${PRISMER_ARTIFACTS_DIR}/`，再显式调 `cloud deliver` / `cloud task attach`。不要另造 Markdown 投影。
+3. **Asset / Memory**：只有用户要求或 Runtime carrier directive 明确选中时才 materialize；必须以服务端返回的 id / path / version / hash 以及读回结果作为权威证据。
+4. **任务 evidence**：截图、benchmark JSON、日志等原始证据可作为明确文件附件显式 `cloud task attach`；它们不会改变主交付物的 carrier。
 
-1. 文档型最终产物**必须写成 markdown 文件**（`.md`），落到 `${PRISMER_ARTIFACTS_DIR}/`（agent process env；physically `${TASK_WORKDIR}/artifacts/`）。daemon artifacts-watcher 会自动把它注册成 task-bound IMAsset 并挂到本次 dispatch 的 `reply.assetIds`（见上「自动归档」）。
-2. chat 里的文字回复是 **summary / teaser**（一两句话点出产了什么、关键结论），**不是交付物本身**。交付物在产物资产里，用户在 task 详情的 Artifacts 看完整内容；下游 task 可经 Library 复用同一份 markdown 资产。
-3. **文件名 / 结构由 skill 按目的自定**——别套死 schema。一般约定：用有意义的文件名（如 `research-summary.md` / `design-review.md` / `q3-plan.md`），需要时拆多个文件。一个 task 可产多个 markdown。
-
-**为什么**：贴在对话里的长 markdown 是一次性的、不可复用、污染时间线、跨设备 / 刷新易丢；写成文件后它是有 hash、可预览、可 promote 到 Library Root、可被下游 task 引用的**资产**。chat 时间线的完成卡只 surface「N 个产物 →」，点进 task drawer 看正文。
+**禁止**：
 
-> 二进制 office 产物（DOCX/PPTX/XLSX/PDF）见 `office-artifacts` skill；markdown 文档型走本节。两者都落 `artifacts/`，区别只是格式。
+- inline 选中后并行生成 Markdown/HTML/CSS/JS 或附件；
+- 把 draft / 中间产物放进 `artifacts/`（draft 走 `scratch/`）；
+- 把“写进 `artifacts/`”当成已交付——auto-scan 是 OFF，文件 carrier 必须有显式 receipt；
+- 用 role 模板或 task 流程覆盖 Runtime carrier directive。
 
 **Self-check checkpoint**：
 
-`cloud task update --status review` 内嵌调用本地 daemon `/v1/checkpoints/pre_status_change`。该 hook 比较 `artifacts/` 内文件 sha256 与已 attach IMAsset.contentHash，若 diff 非空：
+`cloud task update --status review` 内嵌调用本地 daemon `/v1/checkpoints/pre_status_change`。该 hook 比较 `artifacts/` 内文件 sha256 与已 attach Asset.contentHash，若 diff 非空：
 
 - exit code = 12
 - stderr 列出未 attach 的文件路径 + hash + size

package/built-in-skills/tdd/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Matt Pocock
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/built-in-skills/tdd/SKILL.md

@@ -0,0 +1,110 @@
+---
+name: tdd
+scope: coding
+source: https://github.com/mattpocock/skills (MIT, © 2026 Matt Pocock)
+description: Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
+---
+
+# Test-Driven Development
+
+## Philosophy
+
+**Core principle**: Tests should verify behavior through public interfaces, not implementation details. Code can change entirely; tests shouldn't.
+
+**Good tests** are integration-style: they exercise real code paths through public APIs. They describe _what_ the system does, not _how_ it does it. A good test reads like a specification - "user can checkout with valid cart" tells you exactly what capability exists. These tests survive refactors because they don't care about internal structure.
+
+**Bad tests** are coupled to implementation. They mock internal collaborators, test private methods, or verify through external means (like querying a database directly instead of using the interface). The warning sign: your test breaks when you refactor, but behavior hasn't changed. If you rename an internal function and tests fail, those tests were testing implementation, not behavior.
+
+See [tests.md](tests.md) for examples and [mocking.md](mocking.md) for mocking guidelines.
+
+## Anti-Pattern: Horizontal Slices
+
+**DO NOT write all tests first, then all implementation.** This is "horizontal slicing" - treating RED as "write all tests" and GREEN as "write all code."
+
+This produces **crap tests**:
+
+- Tests written in bulk test _imagined_ behavior, not _actual_ behavior
+- You end up testing the _shape_ of things (data structures, function signatures) rather than user-facing behavior
+- Tests become insensitive to real changes - they pass when behavior breaks, fail when behavior is fine
+- You outrun your headlights, committing to test structure before understanding the implementation
+
+**Correct approach**: Vertical slices via tracer bullets. One test → one implementation → repeat. Each test responds to what you learned from the previous cycle. Because you just wrote the code, you know exactly what behavior matters and how to verify it.
+
+```
+WRONG (horizontal):
+  RED:   test1, test2, test3, test4, test5
+  GREEN: impl1, impl2, impl3, impl4, impl5
+
+RIGHT (vertical):
+  RED→GREEN: test1→impl1
+  RED→GREEN: test2→impl2
+  RED→GREEN: test3→impl3
+  ...
+```
+
+## Workflow
+
+### 1. Planning
+
+When exploring the codebase, read `CONTEXT.md` (if it exists) so that test names and interface vocabulary match the project's domain language, and respect ADRs in the area you're touching.
+
+Before writing any code:
+
+- [ ] Confirm with user what interface changes are needed
+- [ ] Confirm with user which behaviors to test (prioritize)
+- [ ] Identify opportunities for deep modules (small interface, deep implementation) — run the `/codebase-design` skill for the vocabulary and the testability checks
+- [ ] List the behaviors to test (not implementation steps)
+- [ ] Get user approval on the plan
+
+Ask: "What should the public interface look like? Which behaviors are most important to test?"
+
+**You can't test everything.** Confirm with the user exactly which behaviors matter most. Focus testing effort on critical paths and complex logic, not every possible edge case.
+
+### 2. Tracer Bullet
+
+Write ONE test that confirms ONE thing about the system:
+
+```
+RED:   Write test for first behavior → test fails
+GREEN: Write minimal code to pass → test passes
+```
+
+This is your tracer bullet - proves the path works end-to-end.
+
+### 3. Incremental Loop
+
+For each remaining behavior:
+
+```
+RED:   Write next test → fails
+GREEN: Minimal code to pass → passes
+```
+
+Rules:
+
+- One test at a time
+- Only enough code to pass current test
+- Don't anticipate future tests
+- Keep tests focused on observable behavior
+
+### 4. Refactor
+
+After all tests pass, look for [refactor candidates](refactoring.md):
+
+- [ ] Extract duplication
+- [ ] Deepen modules (move complexity behind simple interfaces)
+- [ ] Apply SOLID principles where natural
+- [ ] Consider what new code reveals about existing code
+- [ ] Run tests after each refactor step
+
+**Never refactor while RED.** Get to GREEN first.
+
+## Checklist Per Cycle
+
+```
+[ ] Test describes behavior, not implementation
+[ ] Test uses public interface only
+[ ] Test would survive internal refactor
+[ ] Code is minimal for this test
+[ ] No speculative features added
+```

package/built-in-skills/tdd/mocking.md

@@ -0,0 +1,59 @@
+# When to Mock
+
+Mock at **system boundaries** only:
+
+- External APIs (payment, email, etc.)
+- Databases (sometimes - prefer test DB)
+- Time/randomness
+- File system (sometimes)
+
+Don't mock:
+
+- Your own classes/modules
+- Internal collaborators
+- Anything you control
+
+## Designing for Mockability
+
+At system boundaries, design interfaces that are easy to mock:
+
+**1. Use dependency injection**
+
+Pass external dependencies in rather than creating them internally:
+
+```typescript
+// Easy to mock
+function processPayment(order, paymentClient) {
+  return paymentClient.charge(order.total);
+}
+
+// Hard to mock
+function processPayment(order) {
+  const client = new StripeClient(process.env.STRIPE_KEY);
+  return client.charge(order.total);
+}
+```
+
+**2. Prefer SDK-style interfaces over generic fetchers**
+
+Create specific functions for each external operation instead of one generic function with conditional logic:
+
+```typescript
+// GOOD: Each function is independently mockable
+const api = {
+  getUser: (id) => fetch(`/users/${id}`),
+  getOrders: (userId) => fetch(`/users/${userId}/orders`),
+  createOrder: (data) => fetch('/orders', { method: 'POST', body: data }),
+};
+
+// BAD: Mocking requires conditional logic inside the mock
+const api = {
+  fetch: (endpoint, options) => fetch(endpoint, options),
+};
+```
+
+The SDK approach means:
+- Each mock returns one specific shape
+- No conditional logic in test setup
+- Easier to see which endpoints a test exercises
+- Type safety per endpoint

package/built-in-skills/tdd/refactoring.md

@@ -0,0 +1,10 @@
+# Refactor Candidates
+
+After TDD cycle, look for:
+
+- **Duplication** → Extract function/class
+- **Long methods** → Break into private helpers (keep tests on public interface)
+- **Shallow modules** → Combine or deepen
+- **Feature envy** → Move logic to where data lives
+- **Primitive obsession** → Introduce value objects
+- **Existing code** the new code reveals as problematic

package/built-in-skills/tdd/tests.md

@@ -0,0 +1,61 @@
+# Good and Bad Tests
+
+## Good Tests
+
+**Integration-style**: Test through real interfaces, not mocks of internal parts.
+
+```typescript
+// GOOD: Tests observable behavior
+test("user can checkout with valid cart", async () => {
+  const cart = createCart();
+  cart.add(product);
+  const result = await checkout(cart, paymentMethod);
+  expect(result.status).toBe("confirmed");
+});
+```
+
+Characteristics:
+
+- Tests behavior users/callers care about
+- Uses public API only
+- Survives internal refactors
+- Describes WHAT, not HOW
+- One logical assertion per test
+
+## Bad Tests
+
+**Implementation-detail tests**: Coupled to internal structure.
+
+```typescript
+// BAD: Tests implementation details
+test("checkout calls paymentService.process", async () => {
+  const mockPayment = jest.mock(paymentService);
+  await checkout(cart, payment);
+  expect(mockPayment.process).toHaveBeenCalledWith(cart.total);
+});
+```
+
+Red flags:
+
+- Mocking internal collaborators
+- Testing private methods
+- Asserting on call counts/order
+- Test breaks when refactoring without behavior change
+- Test name describes HOW not WHAT
+- Verifying through external means instead of interface
+
+```typescript
+// BAD: Bypasses interface to verify
+test("createUser saves to database", async () => {
+  await createUser({ name: "Alice" });
+  const row = await db.query("SELECT * FROM users WHERE name = ?", ["Alice"]);
+  expect(row).toBeDefined();
+});
+
+// GOOD: Verifies through interface
+test("createUser makes user retrievable", async () => {
+  const user = await createUser({ name: "Alice" });
+  const retrieved = await getUser(user.id);
+  expect(retrieved.name).toBe("Alice");
+});
+```

package/built-in-skills/team/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: team
+scope: persistence
 description: Invite humans into a workspace, propose collaborators for a project, and inspect the current human team. Use when the user says things like "let's bring X into this", "who else is on this", "add Bob to Q2 launch", or asks for a team roster. NEVER mints invites silently — the human must press a button.
 ---
 
@@ -19,7 +20,7 @@ Use this skill when work needs another human in the loop. The workspace + projec
 - The user names someone who isn't already on the workspace: *"Have Maya look at this"*, *"Loop Bob in on Q2 launch"*.
 - The user asks who's on the team or what the roster looks like: *"who has access to this workspace"*, *"who's working on Q2 launch"*.
 - The user asks to remove someone, change someone's role, or move someone between projects.
-- An agent (e.g. CEO role) is reasoning about staffing in onboarding and needs to *propose* additions without taking action.
+- An agent (e.g. Team Manager role) is reasoning about staffing in onboarding and needs to *propose* additions without taking action.
 
 ## What the platform exposes
 

package/built-in-skills/web-artifacts-builder/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: web-artifacts-builder
+scope: coding
 description: Suite of tools for creating elaborate, multi-component claude.ai HTML artifacts using modern frontend web technologies (React, Tailwind CSS, shadcn/ui). Use for complex artifacts requiring state management, routing, or shadcn/ui components - not for simple single-file HTML/JSX artifacts.
 license: Complete terms in LICENSE.txt
 ---

package/built-in-skills/webapp-testing/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: webapp-testing
+scope: coding
 description: Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.
 license: Complete terms in LICENSE.txt
 ---

package/built-in-skills/wechat-pay/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: wechat-pay
+scope: persistence
+description: Collect a real WeChat Pay (微信支付) payment from inside an IM session. Use when a user in the conversation explicitly asks to pay / 下单 / 付款 / 收款 and has stated (or confirmed) an amount. Posts a Native 扫码 QR card into the session (which the bridge forwards to bound WeChat users), then confirms when the payment lands. Executes via `cloud pay create` / `cloud pay status`. This is the RUNTIME收款 capability — distinct from the wechatpay-skills coding-assistant skill, which only helps developers write integration code.
+---
+
+# WeChat Pay (收款) in a session
+
+This skill lets you collect a **real** WeChat Pay payment from a participant of the
+current conversation. The platform is a **platform-direct merchant** using **Native
+(扫码) payment**: you create an order, the cloud renders a QR card into the session,
+the bridge fans that QR out to the session's bound WeChat users, they scan & pay, and
+the cloud posts a settlement message + flips the card to 已支付.
+
+## ⛔ Guardrails — real money
+
+1. **Only on explicit user request with an explicit amount.** Never invent a price,
+   never round, never "helpfully" collect more. If the amount is unclear, ASK in the
+   conversation first.
+2. **Never alter the amount** the user agreed to.
+3. **One order per intent.** Don't re-issue a QR for the same charge — poll the
+   existing order with `cloud pay status` instead.
+4. This is **online-only**. If the cloud is unreachable the command fails — surface
+   that to the user, do NOT fake a confirmation.
+
+## When to use
+
+- A user says "帮我下单 / 付款 / 收款 ¥X" or agrees to a quoted price.
+- You're a 客服 / 销售 / 咨询 agent closing a paid action.
+
+## CLI
+
+```bash
+# Create an order + post the QR card (amount in YUAN on the CLI)
+cloud pay create --conversation <conversationId> --amount 9.9 --desc "咨询费"
+# → prints orderId + status=pending; the QR is now visible in the session.
+
+# Poll until paid (the cloud also posts a "✅ 已收款" message when it lands)
+cloud pay status <orderId>
+# → status: pending | succeeded | expired | closed
+```
+
+`--conversation` is the current session id. Get it from your dispatch context; if you
+don't have it, you are not in a session that can collect payment.
+
+## Flow
+
+1. Confirm the amount + purpose with the user (in YUAN).
+2. `cloud pay create --conversation <id> --amount <yuan> --desc "<purpose>"`.
+3. Tell the user the QR is posted and to scan it in WeChat.
+4. Poll `cloud pay status <orderId>` (or wait for the settlement message). On
+   `succeeded`, confirm to the user and continue your task.
+5. The Native QR expires in ~2h. If it expires before payment, create a new order.
+
+## Notes
+
+- Amounts: CLI takes **yuan** (`9.9`); the API stores **分**. ¥9.9 → 990 分.
+- Errors surface the WeChat `code` + `Request-Id` — if a user reports a failure, that
+  `Request-Id` is exactly what the wechatpay-skills troubleshooting flow consumes.