@moonpay/cli 1.79.1 → 1.81.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/{chunk-4WTM4REW.js → chunk-COK5Y4KF.js} +1 -1
- package/dist/{chunk-YMAC7EXH.js → chunk-K5EQ5EBV.js} +1 -1
- package/dist/{chunk-DNRFBEZH.js → chunk-N6PDZ2VX.js} +3 -3
- package/dist/{chunk-LMRP4L5V.js → chunk-Z75TS6OH.js} +2 -2
- package/dist/{client-V36OT3KR.js → client-NDHSYGQC.js} +1 -1
- package/dist/index.js +2 -2
- package/dist/{ledger-KW6YXBNS.js → ledger-2HSZUTMR.js} +2 -2
- package/dist/{mcp-JHM6DBX7.js → mcp-7JYFDAZJ.js} +1 -1
- package/dist/{store-GY4DANVF.js → store-XW74V75O.js} +1 -1
- package/package.json +1 -1
- package/skills/moonpay-fund-polymarket/SKILL.md +2 -2
- package/skills/moonpay-kalshi/SKILL.md +25 -2
- package/skills/moonpay-missions/SKILL.md +1 -1
- package/skills/moonpay-polymarket-feeds/SKILL.md +1 -1
- package/skills/moonpay-prediction-market/SKILL.md +4 -0
- package/skills/moonpay-artifact-builder/SKILL.md +0 -667
- package/skills/moonpay-automation-builder/SKILL.md +0 -148
- package/skills/moonpay-onboarding/SKILL.md +0 -171
- package/skills/moonpay-skill-builder/SKILL.md +0 -157
|
@@ -1,148 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: moonpay-automation-builder
|
|
3
|
-
description: Author new automations for the MoonPay Agents app. Use when the user wants to schedule a recurring task — a daily portfolio email, an hourly price check, a weekly rebalance, a cron-triggered prompt. Automations are JSON entries that fire a prompt or skill on a cron schedule via either the Claude Code or Codex backend. This skill defines the JSON schema, where to write it, and how to pick a sensible cron.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# MoonPay Automation Builder
|
|
7
|
-
|
|
8
|
-
An automation is a saved prompt that the MoonPay Agents app fires on a cron schedule. The first fire spawns a fresh agent session; every subsequent fire `--resume`s the same session so the agent keeps its memory across runs. This is how "every morning, summarize my portfolio" or "every Monday at 9am, run my DCA strategy" actually run.
|
|
9
|
-
|
|
10
|
-
This skill is how new automations get authored.
|
|
11
|
-
|
|
12
|
-
## When to use this skill
|
|
13
|
-
|
|
14
|
-
- The user wants something to run on a schedule, not just one-shot.
|
|
15
|
-
- The user already has a skill or a prompt that works once and wants to run it on repeat.
|
|
16
|
-
- The user describes the trigger with words like "every day", "every Monday", "hourly", "twice a week", "at 9am".
|
|
17
|
-
|
|
18
|
-
If the user wants a one-shot future action ("remind me at 3pm"), suggest the `schedule` skill instead — that's cloud-side and one-time.
|
|
19
|
-
|
|
20
|
-
## On-disk format
|
|
21
|
-
|
|
22
|
-
All automations live in a single file:
|
|
23
|
-
|
|
24
|
-
```
|
|
25
|
-
~/.moonpay-agents/automations.json
|
|
26
|
-
```
|
|
27
|
-
|
|
28
|
-
It's a JSON array of automation objects. Each object:
|
|
29
|
-
|
|
30
|
-
```json
|
|
31
|
-
{
|
|
32
|
-
"id": "<uuid v4>",
|
|
33
|
-
"name": "Morning portfolio check",
|
|
34
|
-
"body": "Run mp portfolio retrieve --json, summarize the top movers since yesterday, and Slack me a 3-bullet update.",
|
|
35
|
-
"cron": "0 9 * * *",
|
|
36
|
-
"backend": "claude",
|
|
37
|
-
"enabled": true,
|
|
38
|
-
"sessionId": null,
|
|
39
|
-
"lastRun": null,
|
|
40
|
-
"lastStatus": null,
|
|
41
|
-
"lastOutput": null,
|
|
42
|
-
"createdAt": "2026-05-14T17:00:00Z"
|
|
43
|
-
}
|
|
44
|
-
```
|
|
45
|
-
|
|
46
|
-
| field | required | notes |
|
|
47
|
-
|---|---|---|
|
|
48
|
-
| `id` | required | UUID v4. Generate one if creating new. |
|
|
49
|
-
| `name` | required | Short label shown in the Automations view. |
|
|
50
|
-
| `body` | required | The prompt the agent runs on each fire. Write it like a normal user message — the agent sees this verbatim. |
|
|
51
|
-
| `cron` | required | 5-field cron: `min hour dom month dow`. See "Picking a cron" below. |
|
|
52
|
-
| `backend` | required | `"claude"` or `"codex"`. Default to `"claude"` unless the user prefers Codex. |
|
|
53
|
-
| `enabled` | optional | Defaults to `true`. Set `false` to author the automation without firing it. |
|
|
54
|
-
| `sessionId` | optional | Leave `null` — the app fills this in after the first fire. |
|
|
55
|
-
| `lastRun`, `lastStatus`, `lastOutput` | optional | Leave `null` — written by the app after each fire. |
|
|
56
|
-
| `createdAt` | required | ISO-8601 timestamp. Use the current time. |
|
|
57
|
-
|
|
58
|
-
The app reloads `automations.json` on every save, so writing directly to disk works — no IPC needed.
|
|
59
|
-
|
|
60
|
-
## Picking a cron
|
|
61
|
-
|
|
62
|
-
The format is the standard 5-field Unix cron: `minute hour day-of-month month day-of-week`. **Day-of-week is 0–6 with 0 = Sunday.**
|
|
63
|
-
|
|
64
|
-
| Cadence | Cron | Notes |
|
|
65
|
-
|---|---|---|
|
|
66
|
-
| Every minute | `* * * * *` | Don't. Almost always a bug. |
|
|
67
|
-
| Every 5 minutes | `*/5 * * * *` | Polling. Fine for cheap checks. |
|
|
68
|
-
| Every hour on the hour | `0 * * * *` | |
|
|
69
|
-
| Daily at 9am | `0 9 * * *` | Local time of the device running the app. |
|
|
70
|
-
| Every weekday at 9am | `0 9 * * 1-5` | Mon–Fri. |
|
|
71
|
-
| Every Monday at 9am | `0 9 * * 1` | |
|
|
72
|
-
| First of the month at 9am | `0 9 1 * *` | |
|
|
73
|
-
|
|
74
|
-
The MoonPay Agents app uses a 6-field internal form (`sec min hour dom month dow`) — it prepends `0 ` automatically. Always write 5-field cron in the JSON.
|
|
75
|
-
|
|
76
|
-
### Cron gotchas
|
|
77
|
-
|
|
78
|
-
- **Day-of-month + day-of-week are OR'd**, not AND'd. `0 9 1 * 1` fires on the 1st of the month AND every Monday — usually not what people want.
|
|
79
|
-
- **App must be running.** The scheduler is in-process; if the app is closed, the automation doesn't fire. (No launchd integration today.)
|
|
80
|
-
- **Time zone** = local machine time. If the user moves time zones, the cron fires at the same local time, not the same UTC time.
|
|
81
|
-
|
|
82
|
-
## Writing the `body`
|
|
83
|
-
|
|
84
|
-
The body is the prompt the agent gets on every fire. Two things to get right:
|
|
85
|
-
|
|
86
|
-
### 1. Write it like a normal user message
|
|
87
|
-
|
|
88
|
-
```
|
|
89
|
-
Pull my Polymarket positions with mp polymarket positions list --json. For each position
|
|
90
|
-
where the current price has moved >5% from entry, draft a Slack message to #me with the
|
|
91
|
-
position name, entry price, current price, and PnL.
|
|
92
|
-
```
|
|
93
|
-
|
|
94
|
-
Not:
|
|
95
|
-
|
|
96
|
-
```
|
|
97
|
-
Execute polymarket position summary procedure
|
|
98
|
-
```
|
|
99
|
-
|
|
100
|
-
The agent reads the body the same way it reads a chat message. Be specific about what data to pull, what to do with it, and where to deliver the result.
|
|
101
|
-
|
|
102
|
-
### 2. Don't recreate skills inline
|
|
103
|
-
|
|
104
|
-
If the workflow already exists as a skill (`mp skill list`), invoke the skill instead of describing its steps:
|
|
105
|
-
|
|
106
|
-
> "Use the moonpay-portfolio skill. Compute drift from my target allocation and Slack me a one-line summary if drift > 5%."
|
|
107
|
-
|
|
108
|
-
This keeps the automation small and lets skill improvements propagate automatically.
|
|
109
|
-
|
|
110
|
-
### 3. Pick the right backend
|
|
111
|
-
|
|
112
|
-
- **`"claude"`** for anything that needs nuanced judgment, web research, or long-form output. Default.
|
|
113
|
-
- **`"codex"`** if the workflow is heavily code-modifying (e.g. "regenerate this report HTML and write it to disk") and you want Codex's editing harness.
|
|
114
|
-
|
|
115
|
-
## Authoring flow (what the agent should do)
|
|
116
|
-
|
|
117
|
-
When the user invokes you:
|
|
118
|
-
|
|
119
|
-
1. **Ask three things**:
|
|
120
|
-
- What should this automation do? (the body)
|
|
121
|
-
- How often? (the cron — in plain English, you'll convert)
|
|
122
|
-
- Backend? (default to claude unless they specify)
|
|
123
|
-
2. **Convert the cadence to a 5-field cron** and read it back to the user in plain English ("Every weekday at 9am — `0 9 * * 1-5`") to confirm.
|
|
124
|
-
3. **Read `~/.moonpay-agents/automations.json`** (create the file as `[]` if missing).
|
|
125
|
-
4. **Append a new automation object** with a freshly generated UUID v4, the current ISO-8601 timestamp for `createdAt`, the user's body, the cron, the backend, `enabled: true`, and `null` for `sessionId`/`lastRun`/`lastStatus`/`lastOutput`.
|
|
126
|
-
5. **Write the updated array back** to `~/.moonpay-agents/automations.json`. Pretty-print (2-space indent) — the user may edit it by hand.
|
|
127
|
-
6. **Tell the user**: when the next fire is, the name + cron, and that they can disable/edit it from the Automations view.
|
|
128
|
-
|
|
129
|
-
## Important rules
|
|
130
|
-
|
|
131
|
-
- **Never write to `automations.json` without reading it first.** Read → modify → write. Don't blow away other automations.
|
|
132
|
-
- **Always use UUID v4 for `id`** — incrementing IDs collide on import/export.
|
|
133
|
-
- **Use `null`, not `""` or `undefined`**, for the lifecycle fields the app fills in (`sessionId`, `lastRun`, etc).
|
|
134
|
-
- **Don't enable an automation that fires every minute** without warning the user. `*/5 * * * *` is usually the right floor.
|
|
135
|
-
- **Validate the cron** by running it through `cron --validate <expr>` or noting in the response that the app's scheduler will reject invalid expressions on save.
|
|
136
|
-
|
|
137
|
-
## Common pitfalls
|
|
138
|
-
|
|
139
|
-
- **Cron means local time.** Users who travel get surprises. Mention it on creation if the cadence is time-sensitive.
|
|
140
|
-
- **First fire is at the next match.** A 9am daily automation created at 10am won't fire until 9am tomorrow. Tell the user the expected next-fire time.
|
|
141
|
-
- **Body is too vague.** "Check my portfolio" produces wildly different output each fire. "Run mp portfolio retrieve --json and Slack me a 3-bullet summary of changes since yesterday" produces consistent output.
|
|
142
|
-
- **App-closed silence.** If a user complains an automation didn't fire, first thing to check: was the app actually running at the scheduled time?
|
|
143
|
-
|
|
144
|
-
## Related
|
|
145
|
-
|
|
146
|
-
- **moonpay-skill-builder** — author the underlying skill before scheduling it. Most good automations are "run this skill on a cron".
|
|
147
|
-
- **moonpay-artifact-builder** — for visual recurring reports, pair an automation that updates a JSON file with an artifact that reads it.
|
|
148
|
-
- **`schedule` skill** (cloud-side) — for one-shot future runs ("at 3pm tomorrow, do X"). Different system, persists across app closure.
|
|
@@ -1,171 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: moonpay-onboarding
|
|
3
|
-
description: First-run walkthrough for new MoonPay Agents users — sets up a Solana wallet, recommends funding via USDC (fee-free onramp) and SOL (deposit-from-elsewhere), guides the first swap into a tokenized stock (TSLAX, NEURALINK, SPACEX, ANTHRP, OPENAI), then takes them through authoring their first skill, automation, and artifact so they touch every surface of the product in one guided session. Use when the user has just installed the desktop app, says "I just got started", "help me get set up", "what should I do first", or when an empty-state CTA fires this skill.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# MoonPay Agents — Onboarding
|
|
7
|
-
|
|
8
|
-
The user just installed the app and doesn't know what to do first. Walk them through one happy path that touches every surface: wallet → funding → swap → author a skill → schedule an automation → build an artifact. End state: they can describe what each piece does and they have at least one durable thing of their own in each catalog.
|
|
9
|
-
|
|
10
|
-
**Solana only for v1.** Most of the artifact catalog and the xstock catalog live on Solana — focusing keeps the funnel short.
|
|
11
|
-
|
|
12
|
-
**Don't dump all six steps on them up front.** Walk one at a time, check in between, let them skip ahead if they want.
|
|
13
|
-
|
|
14
|
-
## Step 1 — Wallet
|
|
15
|
-
|
|
16
|
-
```bash
|
|
17
|
-
mp wallet list --json
|
|
18
|
-
```
|
|
19
|
-
|
|
20
|
-
- **At least one wallet has a Solana address** → surface the name + truncated address (`main-sol · 5Cy8…CGCB`). Skip to Step 2.
|
|
21
|
-
- **No wallets** → ask what to name it (default `main`), then:
|
|
22
|
-
|
|
23
|
-
```bash
|
|
24
|
-
mp wallet create --name main
|
|
25
|
-
```
|
|
26
|
-
|
|
27
|
-
The output includes the BIP39 mnemonic. **Surface it once, then tell the user clearly**: write it down or store it in a password manager — anyone with this phrase controls the wallet, MoonPay can't recover it for them.
|
|
28
|
-
|
|
29
|
-
Pause until they confirm they've saved it.
|
|
30
|
-
|
|
31
|
-
## Step 2 — Funding
|
|
32
|
-
|
|
33
|
-
```bash
|
|
34
|
-
mp token balance list --wallet <name> --chain solana --json
|
|
35
|
-
```
|
|
36
|
-
|
|
37
|
-
Note the response includes native SOL at the top of `items[]` when present (the address is `So11111111111111111111111111111111111111111`, symbol `SOL`).
|
|
38
|
-
|
|
39
|
-
Branch on what they have:
|
|
40
|
-
|
|
41
|
-
| State | What to say |
|
|
42
|
-
|---|---|
|
|
43
|
-
| Empty wallet | Two paths: **(a)** Onramp USDC via MoonPay buy link — **this is fee-free right now**, so leading with USDC is the cheapest first dollar in. **(b)** SOL is not fee-free to onramp; if you specifically want SOL, deposit it from an existing wallet or exchange via `mp deposit create --chain solana`. SOL is needed for gas on every transaction, so plan to get at least some. |
|
|
44
|
-
| Some USDC, no SOL | They've got the trading capital but no gas. Generate a SOL deposit link with `mp deposit create --chain solana` and explain SOL is needed for every tx. |
|
|
45
|
-
| Some SOL, no USDC | Funded for gas; recommend onramping USDC (fee-free) for swap capital, OR swap a bit of SOL → USDC right now via the `moonpay-swap-tokens` skill. |
|
|
46
|
-
| Both SOL + USDC | Skip to Step 3. |
|
|
47
|
-
|
|
48
|
-
For the fiat onramp, hand off to the `moonpay-buy-crypto` skill — it generates the right MoonPay buy URL and opens it in a browser. **Always mention the USDC fee-free angle** when the user is buying stablecoins.
|
|
49
|
-
|
|
50
|
-
## Step 3 — First position
|
|
51
|
-
|
|
52
|
-
The point here is to show the agent can do interesting trades, not just hold stablecoins. Start small ($10-50) and **give the user a choice** between a single position and a pre-built portfolio. Don't pick for them.
|
|
53
|
-
|
|
54
|
-
### Option A — Single tokenized stock
|
|
55
|
-
|
|
56
|
-
A focused bet on one company. Surface this list and let them pick one:
|
|
57
|
-
|
|
58
|
-
- **TSLAX** — Tesla
|
|
59
|
-
- **NEURALINK** — Neuralink
|
|
60
|
-
- **SPACEX** — SpaceX
|
|
61
|
-
- **ANTHRP** — Anthropic PreStock
|
|
62
|
-
- **OPENAI** — OpenAI PreStock
|
|
63
|
-
|
|
64
|
-
Once they choose:
|
|
65
|
-
|
|
66
|
-
```bash
|
|
67
|
-
mp token search --query <SYMBOL> --chain solana --limit 3 --json
|
|
68
|
-
```
|
|
69
|
-
|
|
70
|
-
Pluck the address, then hand off to `moonpay-swap-tokens` skill with `from` = USDC and `to` = their pick.
|
|
71
|
-
|
|
72
|
-
### Option B — Frontier Lab Portfolio
|
|
73
|
-
|
|
74
|
-
A pre-baked 50/50 split between the two leading frontier AI labs:
|
|
75
|
-
- 50% **ANTHRP** (Anthropic PreStock)
|
|
76
|
-
- 50% **OPENAI** (OpenAI PreStock)
|
|
77
|
-
|
|
78
|
-
If the user picks this, halve their chosen USD amount and run two swaps via `moonpay-swap-tokens`:
|
|
79
|
-
|
|
80
|
-
```bash
|
|
81
|
-
# First leg
|
|
82
|
-
mp token swap --wallet <name> --chain solana \
|
|
83
|
-
--from-token <USDC> --from-amount <HALF> \
|
|
84
|
-
--to-token <ANTHRP-mint>
|
|
85
|
-
|
|
86
|
-
# Second leg
|
|
87
|
-
mp token swap --wallet <name> --chain solana \
|
|
88
|
-
--from-token <USDC> --from-amount <HALF> \
|
|
89
|
-
--to-token <OPENAI-mint>
|
|
90
|
-
```
|
|
91
|
-
|
|
92
|
-
After both land, surface the combined position summary: "You now hold $X of ANTHRP and $Y of OPENAI — a Frontier Lab basket on Solana."
|
|
93
|
-
|
|
94
|
-
### Caveats to call out for either path
|
|
95
|
-
|
|
96
|
-
These are SPV-wrapped fractional exposure: owning the token gives you price exposure but not voting rights, dividends, or direct ownership in the underlying company. Settlement and price discovery happen on-chain, on Solana.
|
|
97
|
-
|
|
98
|
-
### After the swap(s) land
|
|
99
|
-
|
|
100
|
-
Point them at the **Token Deep Dive** artifact in the app — they can search for any of the tokens they just bought and see the chart + market data + their position.
|
|
101
|
-
|
|
102
|
-
## Step 4 — Author their first skill
|
|
103
|
-
|
|
104
|
-
Their first user-authored skill. Suggest a portfolio-rebalance skill since it's useful and read-only (no irreversible actions):
|
|
105
|
-
|
|
106
|
-
Invoke `moonpay-skill-builder`. Walk them through naming it (`my-portfolio-rebalance` is fine) and writing the description. The skill body should:
|
|
107
|
-
|
|
108
|
-
- Run `mp portfolio retrieve --json` to get the current allocation.
|
|
109
|
-
- Compare against a target allocation the user defines (e.g. 60% USDC, 20% SOL, 20% xstocks).
|
|
110
|
-
- Surface drift per position: which ones are over target (sell candidates), which are under (buy candidates).
|
|
111
|
-
- **Read-only** — don't actually trade. List recommendations only.
|
|
112
|
-
|
|
113
|
-
After save, the skill lands at `~/.moonpay-agents/.agents/skills/my-portfolio-rebalance/SKILL.md`. Tell the user it'll show up in the **Skills view → Yours** filter on next refresh.
|
|
114
|
-
|
|
115
|
-
## Step 5 — Schedule it as an automation
|
|
116
|
-
|
|
117
|
-
Now they have a useful skill — show them how to make it recurring.
|
|
118
|
-
|
|
119
|
-
Invoke `moonpay-automation-builder`. Recipe:
|
|
120
|
-
|
|
121
|
-
- **Name**: "Weekly portfolio check"
|
|
122
|
-
- **Body**: "Use the my-portfolio-rebalance skill. Run the drift report for my main-sol wallet."
|
|
123
|
-
- **Cron**: `0 9 * * 1` (Monday 9am local)
|
|
124
|
-
- **Backend**: `claude` (default)
|
|
125
|
-
|
|
126
|
-
The builder writes the entry into `~/.moonpay-agents/automations.json`. Tell the user it'll show up in the **Automations view** with an inline Switch they can flip if they want to pause it later.
|
|
127
|
-
|
|
128
|
-
## Step 6 — Build the visualization artifact
|
|
129
|
-
|
|
130
|
-
Last step — show them the artifact runtime by building a portfolio pie chart.
|
|
131
|
-
|
|
132
|
-
Invoke `moonpay-artifact-builder`. Recipe:
|
|
133
|
-
|
|
134
|
-
- **Slug**: `my-portfolio-pie`
|
|
135
|
-
- **Title**: "Portfolio"
|
|
136
|
-
- **What it does**: On load, call `mp portfolio retrieve --json` via `window.mp.run`. Render a Chart.js doughnut chart of holdings by USD value. Use the design-system tokens from the skill (color palette, font-mono for numbers, tabular-nums alignment). Add a refresh button that re-pulls the balances.
|
|
137
|
-
|
|
138
|
-
The artifact-builder skill has all the design system + bridge contract in its body — let it drive the authoring.
|
|
139
|
-
|
|
140
|
-
After save it lands at `~/.moonpay-agents/artifacts/my-portfolio-pie.html`. Tell the user it'll show up in the **Artifacts view → Yours** filter.
|
|
141
|
-
|
|
142
|
-
## Wrap-up recap
|
|
143
|
-
|
|
144
|
-
End the session with a one-shot summary listing exactly what they now have:
|
|
145
|
-
|
|
146
|
-
> You're set. Here's what you've got:
|
|
147
|
-
> - **Wallet**: `<name>` (`<truncated-address>`) — your mnemonic is safely stored
|
|
148
|
-
> - **Funded with**: $X USDC + Y SOL
|
|
149
|
-
> - **Position**: $X of <SYMBOL>
|
|
150
|
-
> - **Skill**: `my-portfolio-rebalance` (Skills view → Yours)
|
|
151
|
-
> - **Automation**: "Weekly portfolio check" runs Mondays at 9am (Automations view)
|
|
152
|
-
> - **Artifact**: `my-portfolio-pie` (Artifacts view → Yours)
|
|
153
|
-
>
|
|
154
|
-
> From here, try the **Token Deep Dive** artifact for any token, or ask me to set up a price alert, a trailing stop, or another recurring task. Run `mp skill list` to see every skill the agent knows.
|
|
155
|
-
|
|
156
|
-
## Important rules
|
|
157
|
-
|
|
158
|
-
- **Never auto-create a wallet without asking** — the mnemonic is a one-time-show secret, the user has to be ready to record it.
|
|
159
|
-
- **USDC fee-free is the only fiat onramp angle worth leading with right now** — don't promise fee-free SOL onramp; it isn't.
|
|
160
|
-
- **Don't skip steps** because you think they're obvious — the whole point is the user touches every surface.
|
|
161
|
-
- **Pause between steps** to let the user ask questions or peel off if they want to dig into one piece.
|
|
162
|
-
- **End with the recap** so the user remembers what they made.
|
|
163
|
-
|
|
164
|
-
## Related
|
|
165
|
-
|
|
166
|
-
- `moonpay-auth` — runs before this if the user isn't signed in yet.
|
|
167
|
-
- `moonpay-buy-crypto` — fiat onramp link generation (use this for the USDC-fee-free path).
|
|
168
|
-
- `moonpay-deposit` — crypto deposit links (use this for SOL from existing wallets).
|
|
169
|
-
- `moonpay-swap-tokens` — the actual swap execution in Step 3.
|
|
170
|
-
- `moonpay-skill-builder`, `moonpay-automation-builder`, `moonpay-artifact-builder` — Steps 4, 5, 6.
|
|
171
|
-
- **Token Deep Dive** artifact (in the desktop app) — recommended post-onboarding for exploring tokens.
|
|
@@ -1,157 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: moonpay-skill-builder
|
|
3
|
-
description: Author new agent skills for the MoonPay Agents app. Use when the user wants to teach the agent a new workflow, encode a procedure they keep repeating, or wrap a CLI sequence as a single invokable skill. Skills are markdown files with YAML frontmatter that both Claude Code and Codex pick up natively. This skill defines the contract, the save location, and how to write skills that don't suck.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# MoonPay Skill Builder
|
|
7
|
-
|
|
8
|
-
A skill is a markdown file the agent reads when it decides the user's request matches the skill's description. It's not a function call — it's an instruction set the agent follows. Used well, skills turn a 12-step chat into one prompt; used badly, they're just untested documentation.
|
|
9
|
-
|
|
10
|
-
This skill is how new skills get authored.
|
|
11
|
-
|
|
12
|
-
## When to use this skill
|
|
13
|
-
|
|
14
|
-
- The user has a procedure they've walked the agent through more than twice.
|
|
15
|
-
- The user wants to share an agent workflow with their team.
|
|
16
|
-
- The user wants to wrap a `mp` CLI command sequence (or any other tool sequence) as a single invocable thing.
|
|
17
|
-
|
|
18
|
-
Don't use this skill for one-off requests or things that are already a single `mp` command — those don't need a skill.
|
|
19
|
-
|
|
20
|
-
## On-disk format
|
|
21
|
-
|
|
22
|
-
A skill is a directory. The directory name is the skill slug (kebab-case, must match the frontmatter `name`).
|
|
23
|
-
|
|
24
|
-
```
|
|
25
|
-
<slug>/
|
|
26
|
-
├── SKILL.md # Required. Frontmatter + body.
|
|
27
|
-
├── scripts/ # Optional. Helper scripts the skill body calls.
|
|
28
|
-
├── references/ # Optional. Long-form docs the body links to.
|
|
29
|
-
└── templates/ # Optional. Reference files the agent can read or copy.
|
|
30
|
-
```
|
|
31
|
-
|
|
32
|
-
Only `SKILL.md` is required. Most useful skills stop there.
|
|
33
|
-
|
|
34
|
-
### `SKILL.md` frontmatter
|
|
35
|
-
|
|
36
|
-
Both Claude Code and Codex are strict — only **two fields** are portable across both engines:
|
|
37
|
-
|
|
38
|
-
```yaml
|
|
39
|
-
---
|
|
40
|
-
name: my-skill-slug
|
|
41
|
-
description: One paragraph explaining (a) WHEN the agent should invoke this skill, and (b) WHAT it does. The description is the matching surface — write it like a router, not a summary.
|
|
42
|
-
---
|
|
43
|
-
```
|
|
44
|
-
|
|
45
|
-
| key | required | notes |
|
|
46
|
-
|---|---|---|
|
|
47
|
-
| `name` | required | kebab-case slug, matches the directory name |
|
|
48
|
-
| `description` | required | The matching text. See "Writing the description" below — this is the highest-leverage part of the skill |
|
|
49
|
-
|
|
50
|
-
**Do not add other fields** (`tags`, `category`, `version`, `author`, etc). Codex's docs explicitly state "Do not include any other fields in YAML frontmatter." Claude has its own optional fields (`allowed-tools`, `disable-model-invocation`, `model`, `effort`, `paths`, etc.) but those are Claude-specific — using them breaks portability.
|
|
51
|
-
|
|
52
|
-
For app-side metadata that the MoonPay Agents app might want (filter chips, icons, etc.), the app derives those from the skill's filesystem location, not from frontmatter. Built-in skills come from the plugin path; user-authored skills come from `.agents/skills/`. No metadata required from the skill itself.
|
|
53
|
-
|
|
54
|
-
### Save location
|
|
55
|
-
|
|
56
|
-
Write user-authored skills here:
|
|
57
|
-
|
|
58
|
-
```
|
|
59
|
-
~/.moonpay-agents/.agents/skills/<slug>/SKILL.md
|
|
60
|
-
```
|
|
61
|
-
|
|
62
|
-
(The `.agents/skills/` path is Codex-native. The MoonPay Agents app symlinks `.claude/skills` → `.agents/skills` on startup so Claude Code picks them up too.)
|
|
63
|
-
|
|
64
|
-
Built-in MoonPay skills live under `~/.moonpay-agents/plugins/moonpay/skills/` and are managed by `mp plugin install/update` — don't write there.
|
|
65
|
-
|
|
66
|
-
## Writing the description
|
|
67
|
-
|
|
68
|
-
The description is the only thing the agent sees when deciding whether to invoke your skill. Write it like routing logic, not like documentation.
|
|
69
|
-
|
|
70
|
-
**Good** (specific triggers, concrete verbs, says what it does):
|
|
71
|
-
> Trade on Polymarket — search markets, buy/sell outcome shares, track positions and PnL. Use when the user names Polymarket explicitly, or wants politics, crypto, news, or general-events markets.
|
|
72
|
-
|
|
73
|
-
**Bad** (vague, no trigger words):
|
|
74
|
-
> Helps with prediction markets.
|
|
75
|
-
|
|
76
|
-
**Bad** (says what NOT to do without saying what to do):
|
|
77
|
-
> Don't use for Kalshi. Don't use for sports betting. Don't use for…
|
|
78
|
-
|
|
79
|
-
A good description answers two questions in one paragraph:
|
|
80
|
-
1. **When should the agent pick this skill?** (Specific triggers, user phrases, concrete situations.)
|
|
81
|
-
2. **What will the agent do once it picks it?** (One verb-led sentence: "search…, buy/sell…, track…")
|
|
82
|
-
|
|
83
|
-
If your description doesn't have at least two trigger phrases the user would actually say, rewrite it.
|
|
84
|
-
|
|
85
|
-
## Writing the body
|
|
86
|
-
|
|
87
|
-
The body is what the agent reads after picking the skill. It's read-only context, not executable — the agent decides what to actually do based on what the body says.
|
|
88
|
-
|
|
89
|
-
### Structure that works
|
|
90
|
-
|
|
91
|
-
```markdown
|
|
92
|
-
# <Skill Title>
|
|
93
|
-
|
|
94
|
-
One sentence: what this skill does and the one thing it's good for.
|
|
95
|
-
|
|
96
|
-
## When to use
|
|
97
|
-
|
|
98
|
-
Bullet list of concrete situations. Be specific. "When the user mentions X" beats "When relevant."
|
|
99
|
-
|
|
100
|
-
## Setup (if any)
|
|
101
|
-
|
|
102
|
-
Commands to run once before the skill's main flow. Skip the section entirely if there's no setup.
|
|
103
|
-
|
|
104
|
-
## The flow
|
|
105
|
-
|
|
106
|
-
Numbered steps. Each step:
|
|
107
|
-
- States the goal of the step in one line
|
|
108
|
-
- Shows the exact command(s) with example argv
|
|
109
|
-
- Says what to surface to the user between steps
|
|
110
|
-
|
|
111
|
-
## Important rules
|
|
112
|
-
|
|
113
|
-
Bullets of must / never. Use these for things that look optional but aren't (e.g. "Always pass --json", "Never click Pay Now").
|
|
114
|
-
|
|
115
|
-
## Related
|
|
116
|
-
|
|
117
|
-
Links to other skills the agent should bounce to.
|
|
118
|
-
```
|
|
119
|
-
|
|
120
|
-
### Body rules
|
|
121
|
-
|
|
122
|
-
- **Write commands literally**, with realistic example arguments. The agent will copy-paste them. `mp wallet list` is useful; `mp <whatever wallet command>` is not.
|
|
123
|
-
- **Don't paraphrase tool output.** If the skill processes the output of `mp foo --json`, name the actual fields (`data.items[0].balance`, not "the balance field").
|
|
124
|
-
- **Surface intermediate state to the user.** Between steps, the agent should tell the user what just happened in one line. Write that line in the skill body so the agent doesn't have to invent it.
|
|
125
|
-
- **Pause for confirmation before irreversible actions** — send money, sign tx, push to remote, click Pay. Spell out the pause in the body.
|
|
126
|
-
- **Bail to another skill** if pre-flight fails. Example: `moonpay-card-checkout` bails to `moonpay-card-onboarding` if there's no card yet.
|
|
127
|
-
|
|
128
|
-
### Body anti-patterns
|
|
129
|
-
|
|
130
|
-
- **"This skill is helpful for…"** — that's the description's job. The body is for the agent, not the user.
|
|
131
|
-
- **Explaining concepts at length.** If you find yourself writing two paragraphs of background, move it to `references/<topic>.md` and link to it.
|
|
132
|
-
- **Branching trees.** If the skill has 6 if/else paths, it's probably 2 skills.
|
|
133
|
-
- **No examples.** Every command needs at least one concrete example argv.
|
|
134
|
-
|
|
135
|
-
## Authoring flow (what the agent should do)
|
|
136
|
-
|
|
137
|
-
When the user invokes you:
|
|
138
|
-
|
|
139
|
-
1. **Ask what the skill should do** — one paragraph from the user describing the workflow, including the triggers ("when I say X").
|
|
140
|
-
2. **Propose the slug + description back to the user** for confirmation. The description is the highest-leverage part; don't move past this until the user says yes.
|
|
141
|
-
3. **Draft the body** following the structure above. Use real `mp` commands where possible — search `mp --help` if you're unsure.
|
|
142
|
-
4. **Save** to `~/.moonpay-agents/.agents/skills/<slug>/SKILL.md` (create the directory if needed).
|
|
143
|
-
5. **Show the user the saved path** and remind them they may need to restart the chat for the agent to pick up the new skill.
|
|
144
|
-
|
|
145
|
-
## Common pitfalls
|
|
146
|
-
|
|
147
|
-
- **Skill is too broad.** "moonpay-helper" with description "helps with MoonPay stuff" will never be selected reliably. Each skill should do one thing.
|
|
148
|
-
- **Skill is too narrow.** "moonpay-buy-eth-on-monday" should just be an automation, not a skill.
|
|
149
|
-
- **Skill description is the same as an existing skill.** Run `mp skill list` first; if there's overlap, edit the existing skill instead of adding a new one.
|
|
150
|
-
- **Skill calls `mp` commands that don't exist.** Run them in a shell first to confirm flags + output shape.
|
|
151
|
-
- **Skill body is a wall of prose.** The agent will read it, but the user won't review it. Keep it tight.
|
|
152
|
-
|
|
153
|
-
## Related
|
|
154
|
-
|
|
155
|
-
- **moonpay-artifact-builder** — sibling skill for authoring HTML artifacts (the visual side; this one is the procedural side).
|
|
156
|
-
- **moonpay-automation-builder** — sibling skill for scheduling existing skills on a cron.
|
|
157
|
-
- **`mp skill list`** — see what's already installed before authoring a new one.
|