open-walnut 0.3.0

package/dist/daemon-binaries/acp-worker.js.version

@@ -0,0 +1 @@
+walnut-daemon-e146d633443b

package/dist/data/skills/daily-standup/SKILL.md

@@ -0,0 +1,16 @@
+---
+name: daily-standup
+description: >-
+  Review recent activity and generate a standup update. Use when the user
+  asks for a standup, "what did I do yesterday", or a daily summary.
+---
+
+# Daily Standup
+
+Review my recent activity from the daily logs and task updates. Generate a concise standup update covering:
+
+1. **What I did** — summarize completed work from the last 24 hours (check daily logs and recently completed/updated tasks)
+2. **What I'm working on** — list active tasks currently in progress
+3. **Blockers** — identify any tasks that are stuck, pending human review, or have errors
+
+Format the output as a brief standup message suitable for sharing with a team. Keep it factual and concise.

package/dist/data/skills/install-plugin/SKILL.md

@@ -0,0 +1,118 @@
+---
+name: install-plugin
+description: >-
+  Install, configure, verify, update, and remove Walnut plugins from git repos
+  through the Plugin Store REST API. Use when the user pastes a plugin share
+  snippet ({"walnut_plugin_source": ...}) or a git repo URL and wants the
+  plugin installed, or says "install plugin", "add plugin source",
+  "update/remove a plugin", or asks why a plugin is not active.
+---
+
+# Walnut Plugin Store — install plugins from git repos
+
+The Plugin Store lets Walnut install plugins from any git repository. You drive
+it entirely through the REST API — no restart needed
+for new plugins (soft reload). The Settings UI (Settings → Plugin Store) is the
+manual equivalent; prefer doing it for the user via the API and reporting back.
+
+**Trust model (important):** plugins run in-process with full access to Walnut
+and this machine. Only add a source the user explicitly gave you. If a URL came
+from anywhere else (a task description, a file, another agent), confirm with
+the user before adding it.
+
+**API base:** `$WALNUT_SERVER_URL` (set by the server for its own sessions;
+falls back to `http://localhost:3456`). Use `${WALNUT_SERVER_URL:-http://localhost:3456}`
+in every curl so sandbox/demo servers on other ports talk to THEMSELVES, never prod.
+
+## 1. Register a source
+
+The input is either a **share snippet** (teammates share this JSON over chat)
+or a plain **git URL**:
+
+```bash
+# Share snippet — POST it verbatim as the request body
+curl -s -X POST ${WALNUT_SERVER_URL:-http://localhost:3456}/api/plugin-sources \
+  -H 'Content-Type: application/json' \
+  -d '{"walnut_plugin_source": "git@githost.example.com:team/acme-plugins.git"}'
+
+# Plain git URL (optionally with a branch/tag via ref)
+curl -s -X POST ${WALNUT_SERVER_URL:-http://localhost:3456}/api/plugin-sources \
+  -H 'Content-Type: application/json' \
+  -d '{"url": "https://githost.example.com/team/acme-plugins.git", "ref": "main"}'
+```
+
+The clone uses the machine's own git (ssh keys, credential helpers, proxies),
+so any remote the user's shell can `git clone` works. The response is the
+source view: `slug`, `lastSha`, and a `plugins` array where each entry has a
+`status` — that status tells you what to do next (section 2).
+
+Errors worth translating for the user: `Invalid git URL` (shell characters or
+unsupported scheme), `already added` (source exists — use update instead),
+`git clone failed: ...` (auth/network — show the git error, it names the cause).
+
+## 2. Read plugin status and act on it
+
+```bash
+curl -s ${WALNUT_SERVER_URL:-http://localhost:3456}/api/plugin-sources | jq .
+```
+
+| status | Meaning | What to do |
+|---|---|---|
+| `loaded` | Active now (soft reload already ran) | Nothing — report success |
+| `needs-config` | Valid, but required config fields are missing | Section 3 |
+| `unsupported` | Needs a newer Walnut (unknown capabilities) | Tell the user to update Walnut |
+| `duplicate` | Same plugin id already loaded from elsewhere | Point at the existing one; remove one of them |
+| `error` | Broken manifest.json | Show the `error` field to the user |
+| `pending-restart` | Code on disk changed after load | Restart Walnut to pick it up |
+
+## 3. Configure a needs-config plugin
+
+Field definitions (labels, help text with links, defaults, which are required)
+come from the plugin's manifest:
+
+```bash
+curl -s ${WALNUT_SERVER_URL:-http://localhost:3456}/api/integrations/settings | jq '.[] | select(.id=="<plugin-id>")'
+```
+
+`missing` lists the required keys that are empty; `uiHints.<key>.help` tells
+the user exactly where to find each value — quote it when asking them.
+
+Save values with a config update. **`PUT /api/config` replaces the whole
+`plugins` key, so read-merge-write** — never send just the one plugin:
+
+```bash
+# 1. Current plugins map
+current=$(curl -s ${WALNUT_SERVER_URL:-http://localhost:3456}/api/config | jq '.config.plugins // {}')
+# 2. Merge in the new plugin's values (enabled: true activates it)
+merged=$(echo "$current" | jq '. + {"<plugin-id>": {"enabled": true, "<key>": "<value>"}}')
+# 3. Write back
+curl -s -X PUT ${WALNUT_SERVER_URL:-http://localhost:3456}/api/config \
+  -H 'Content-Type: application/json' \
+  -d "{\"plugins\": $merged}"
+```
+
+Saving triggers a soft reload automatically. Verify: re-run the section 2 GET
+and confirm the plugin is now `loaded`. If it stays `needs-config`, re-read
+`missing` — a required value is still empty or wrong.
+
+## 4. Update / remove / share
+
+```bash
+curl -s -X POST ${WALNUT_SERVER_URL:-http://localhost:3456}/api/plugin-sources/<slug>/update   # git pull + soft reload
+curl -s -X POST ${WALNUT_SERVER_URL:-http://localhost:3456}/api/plugin-sources/<slug>/check    # commits behind, no change
+curl -s -X DELETE ${WALNUT_SERVER_URL:-http://localhost:3456}/api/plugin-sources/<slug>        # remove source + clone
+```
+
+Update/remove responses carry `restartRequired: true` when already-loaded
+plugin code changed or was removed — the in-memory version keeps running until
+a restart. Tell the user; do not restart the server yourself.
+
+To share a source with a teammate, use the `shareSnippet` field from the
+section 2 GET (absent for URLs with embedded credentials — never share those).
+
+## 5. Report back
+
+Summarize honestly: which plugins were found, which are active, which need
+what config (with the uiHints help text), and any restart needed. If nothing
+was found in the repo: it must have a `manifest.json` at the root or in
+top-level subdirectories — say so.

package/dist/data/skills/learn/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: learn
+description: >-
+  Distill a workflow, doc, or conversation into a reusable skill. Use when
+  the user says "learn this", "save this as a skill", or wants a procedure
+  captured for reuse.
+---
+
+# Learn a Reusable Skill
+
+The user wants you to learn a reusable skill from their request and save it.
+
+The request is open-ended and may mix two kinds of content, in any order: SOURCES to gather (directories, file paths, URLs, "what we just did", pasted notes) AND REQUIREMENTS that shape the skill (what to focus on, what to leave out, scope, naming). Treat EVERY part of the request as load-bearing — prose after a path or link is the user telling you what they want from that source. Never gather the first source and ignore the rest. If no request text was given, distill the workflow from THIS conversation: review the steps taken and capture them.
+
+Do this:
+1. Gather every source the user named, using the tools you already have — `file_read` for local files, `web_fetch` for URLs, the current conversation history if they referred to something you just did, and pasted text as-is. For codebase exploration, delegate to a session. If scope is ambiguous, make a reasonable choice and note it; do not stall.
+2. Apply every requirement/focus/constraint in the request to the skill you author — these govern what the SKILL.md covers, not just which sources you read.
+3. Confirm the skill name + category + one-line description with the user (creating a NEW skill always requires confirmation), then author ONE skill via `skill_manage` (action="create").
+
+Follow these authoring standards exactly (HARDLINE — same rules a maintainer enforces in review):
+
+**Frontmatter (passed as skill_manage params):**
+- name: lowercase-hyphenated, ≤64 chars, no spaces.
+- description: ONE sentence, **≤60 characters**, ends with a period. State the capability, not the implementation. No marketing words (powerful, comprehensive, seamless, robust). Do NOT repeat the skill name. This rule is NOT cosmetic: the skill index injects the description into every session and routing depends on it — anything vague or over-long breaks routing. COUNT the characters before saving; skill_manage hard-rejects >60.
+  - Good (≤60): `Search arXiv papers by keyword, author, or ID.`
+  - Bad: `A comprehensive skill that lets the agent search arXiv for academic papers using keywords and authors.`
+- type: `action` for a procedure/how-to; `knowledge` for curated stable facts about a topic.
+- category: pick a sensible grouping (finance, career, projects, walnut, ...). Reuse an existing category when one fits.
+
+**Body — action skills use this section order (omit a section only if genuinely empty):**
+1. `# <Human Title>` + 2-3 sentence intro: what it does, what it does NOT do, key dependency stance.
+2. `## When to Use` — bullet list of concrete trigger phrases.
+3. `## Prerequisites` — exact env vars, install steps, credentials.
+4. `## Procedure` — numbered steps with copy-paste-exact commands.
+5. `## Pitfalls` — known limits, things that look broken but aren't.
+6. `## Verification` — a single check that proves it worked.
+
+**Body — knowledge skills:** freeform but concise (~100 lines): stable facts, decisions and their WHY, key references. No episodic events ("last Tuesday we...") — those belong in the daily log.
+
+**Quality bar:**
+- Prefer exact commands, URLs, signatures, and config keys that appear VERBATIM in the source. NEVER invent flags, paths, or APIs — if you didn't see it in the source, don't write it.
+- Keep it tight and scannable: ~100 lines simple, ~200 complex. Don't re-paste source docs.
+- Don't write a router/index skill that only points at other skills.
+- When updating later: replace outdated facts in place — never append duplicates.
+
+When done, tell the user the skill name, its category, and a one-line summary of what it captured.

package/dist/data/skills/register-repo/SKILL.md

@@ -0,0 +1,20 @@
+---
+name: register-repo
+description: >-
+  Register a repository — delegate a Claude Code session to explore the
+  codebase and create a structured profile. Use when the user says
+  "register repo", "add this repo", or wants a repository profile created.
+---
+
+# Register Repository (delegate)
+
+The user wants to register a repository. Delegate to a Claude Code session — the session does the exploration, not you.
+
+1. **Figure out the path** — from user input, task context, or ask if unclear.
+2. **Find the session-side skill** — look in `<available_skills>` for `walnut-register-repo` and note its `<location>` path.
+3. **Start a session** with:
+   - `working_directory`: the target repo path
+   - `prompt`: "Read the skill at {location} and follow its instructions to explore this codebase and register it as a repository." Include any extra context the user provided.
+4. **After session completes** — verify with `file_read source='repos/{slug}'`.
+
+Do NOT investigate the codebase yourself. Do NOT ask the user a bunch of questions. The session + skill handles everything.

package/dist/data/skills/setup-cloud-companion/SKILL.md

@@ -0,0 +1,326 @@
+---
+name: setup-cloud-companion
+description: >-
+  Set up the self-hosted cloud companion — provision a small always-on VM, wire
+  data sync to it, and get the user's phone working off Wi-Fi. Use when the user
+  says "set up my cloud companion", "I want to reach Walnut from my phone
+  anywhere / away from home", "set up cloud sync", "deploy the cloud box", or
+  asks why their phone only works on the home network.
+type: action
+---
+
+# Set up the cloud companion
+
+The cloud companion is a small always-on VM the user owns. It receives the Mac's
+data repo over git-smart-HTTP, serves the phone over HTTPS from anywhere, and
+relays live session traffic. Setting one up means: provision a VM → point a
+hostname at it → wait for first boot → claim it → verify sync.
+
+You do **not** re-implement that sequence. A resumable job on this machine owns
+it, and you drive that job over REST — the same endpoints the Settings →
+Cloud Companion wizard uses. The job survives your session ending, a server
+restart, and a long poll; your role is to explain, collect choices, answer the
+job's questions, and narrate progress.
+
+**API base:** `$WALNUT_SERVER_URL` (set by the server for its own sessions;
+falls back to `http://localhost:3456`). Use
+`${WALNUT_SERVER_URL:-http://localhost:3456}` in every curl so a sandbox or demo
+server on another port talks to ITSELF, never to the user's real server.
+
+## 0. Money and consent — before anything billable
+
+Provisioning creates **real, recurring, billed cloud resources in the user's own
+account**. Say so plainly, in this order, and get an explicit yes before you
+POST anything:
+
+1. What gets created: one small VM with a public IP, an encrypted disk that is
+   *kept* if the VM is terminated, daily disk snapshots, and (on AWS) a
+   CloudFormation stack that owns them.
+2. What it costs per month — read the real number from `costHint` in step 1
+   below, do not quote a figure from memory.
+3. That the bill runs until they tear it down, and that teardown is manual
+   (section 9).
+
+Then ask for confirmation in one question ("Ready for me to create this?") and
+**wait for a real yes.** If the user is only asking how it works, answer and
+stop — do not start a job.
+
+Two hard rules:
+
+- **Never invent credentials, tokens, domains, or hostnames.** The user supplies
+  the domain and any provider API token. If something is missing, ask.
+- **Never echo a secret back.** Provider tokens go into one POST body and
+  nowhere else — not into your reply, not into a file, not into a task note.
+  The pairing code that authorizes the claim is generated server-side and
+  redacted from every response you can see (`redactCloudSetupJob`), so you will
+  never hold it; the one place it appears is the boot-script blob in section 7.
+
+## 1. Check what this machine can provision
+
+```bash
+curl -s ${WALNUT_SERVER_URL:-http://localhost:3456}/api/cloud-setup/providers
+```
+
+Returns `{ providers: [{ id, label, costHint, canProvision, detect }] }`:
+
+| Field | Meaning for the user |
+|---|---|
+| `label` | Human name, e.g. "AWS (EC2 + CDK)" |
+| `costHint` | Rough monthly cost — quote this verbatim in section 0 |
+| `canProvision` | `true` = Walnut creates the VM itself. `false` = manual path (section 7) |
+| `detect.available` | `true` = credentials are already usable, nothing to collect |
+| `detect.detail` | One sentence to relay as-is — it says exactly what is missing |
+| `detect.needs` | `nothing` / `cli-login` (user fixes their own CLI) / `api-token` (you collect it) |
+
+Report readiness in plain language, e.g. "AWS is ready (credentials found), and
+'Any VM (paste a script)' always works if you'd rather use a host you already
+have." If a provider is `available: false` with `needs: 'cli-login'`, relay
+`detail` — that is the fix — and do not try to log them in yourself.
+
+Do not read `needs: 'cli-login'` as "this provider is unavailable". Azure and
+Google Cloud provision through the user's own `az` / `gcloud` login, so they
+report `cli-login` until that CLI is installed and signed in — and they become
+one-click the moment it is. Relay the one-line fix from `detail`, and offer the
+manual path as the alternative rather than the only option.
+
+## 2. Collect the two choices
+
+**Provider** — one of the `id` values from step 1.
+
+**Domain mode** — this is the choice users get wrong, so present the trade-off:
+
+- `own-domain` — they own a hostname (e.g. `wn.example.com`) and add one DNS
+  A record. **Recommended for anything long-term**: the address is theirs, it
+  survives rebuilds, and certificate issuance is not shared with strangers.
+  Requires access to their DNS registrar during setup.
+- `sslip` — free automatic address derived from the VM's IP
+  (`<dashed-ip>.sslip.io`). **Fastest start**, zero DNS work. Caveat worth
+  stating: `sslip.io` shares one certificate rate-limit bucket across all its
+  users, so issuance can occasionally be slow or throttled, and the address
+  changes if the IP ever changes.
+
+If they pick `own-domain`, get the exact hostname. Optionally collect `region`
+and `instanceType` if they care; otherwise omit them and let the defaults win.
+
+## 3. Start the job
+
+```bash
+curl -s -X POST ${WALNUT_SERVER_URL:-http://localhost:3456}/api/cloud-setup/start \
+  -H 'Content-Type: application/json' \
+  -d '{"provider":"aws","domainMode":"own-domain","domain":"wn.example.com"}'
+```
+
+Body fields: `provider` (required), `domainMode` (required, `own-domain` or
+`sslip`), `domain` (required when `own-domain`), `region`, `instanceType`,
+`credentials` (only when step 1 said `needs: 'api-token'`), `force`.
+
+- **202** `{ job }` — started. Go to section 4.
+- **400** `{ error }` — bad input, or preflight refused. The most common one:
+  cloud sync is **already configured on this machine**. Do not pass `force`
+  reflexively — tell the user they already have a companion wired up, and only
+  start over (with `"force": true`) if they explicitly say they want to replace
+  it.
+- **409** `{ error }` — a job is already in flight. Fetch it and describe it
+  before doing anything:
+
+```bash
+curl -s ${WALNUT_SERVER_URL:-http://localhost:3456}/api/cloud-setup/job
+```
+
+Then act on that job's `status`: `awaiting-input` → answer it (section 6);
+`running` → just resume narrating (section 5); `failed` → section 8;
+`done` → it already finished (section 9). Offer
+`POST /api/cloud-setup/job/cancel` if the user wants to abandon it, and
+`DELETE /api/cloud-setup/job` to clear a finished/failed/cancelled record
+(409 while one is still in flight — cancel first).
+
+## 4. Read the job shape once
+
+Every job response is `{ job: {...} }` with:
+
+- `status` — `running` | `awaiting-input` | `failed` | `done` | `cancelled`
+- `currentStep` — where it is now
+- `steps` — every step id → `{ status: pending|running|done|error|skipped }`
+- `awaitingInput` — `{ kind, prompt }` when blocked (section 6)
+- `logTail` — recent operator-visible lines (ring-capped)
+- `domain`, `ip`, `error`
+
+Step order, with what to tell the user each means:
+
+| Step | Plain language | Rough ETA |
+|---|---|---|
+| `preflight` | checking credentials and that sync isn't already set up | seconds |
+| `generate` | writing the first-boot script | seconds |
+| `provision` | creating the VM | ~5 min (AWS: 3-6 min, longer on a first-ever deploy that installs CDK deps) |
+| `await-vm` | waiting for the IP of a VM you created | manual path only |
+| `dns` | waiting for the A record to point at the VM | minutes to ~30 min; skipped in sslip mode |
+| `await-server` | first boot: clone, build, certificate | ~10 min (budget 20 min) |
+| `claim-and-wire` | claiming the box and configuring the git remote | seconds |
+| `verify-sync` | first push + independent auth check | seconds |
+| `done` | ready | — |
+
+A `skipped` step is normal, not a failure (`dns` in sslip mode, `await-vm`
+whenever Walnut provisioned the VM itself).
+
+## 5. Poll — one short command per poll
+
+```bash
+curl -s ${WALNUT_SERVER_URL:-http://localhost:3456}/api/cloud-setup/job
+```
+
+**Each poll must be its own separate short command, roughly 30s apart.** Do
+not write a `sleep`/`while` loop inside a single call: `shell_exec` is capped at
+600s (default 120s), so a loop that waits out a 10-minute first boot gets killed
+mid-wait and you lose the thread — while the job itself keeps running fine.
+Polling is cheap and the job is authoritative, so a dropped poll costs nothing.
+
+Between polls, narrate transitions in the user's language, not step ids: "the VM
+is up, now waiting for it to finish building Walnut — usually about ten
+minutes." Only surface `logTail` lines when something is slow or wrong; a
+healthy provision does not need its CDK output pasted at the user.
+
+If `GET /job` returns **404**, no job exists — it was deleted, or you never
+started one.
+
+## 6. Answer the job's questions (`status: awaiting-input`)
+
+`awaitingInput.kind` tells you what to ask. Relay `awaitingInput.prompt` too —
+it is written for the user. All three answers go to the same endpoint:
+
+```bash
+curl -s -X POST ${WALNUT_SERVER_URL:-http://localhost:3456}/api/cloud-setup/job/input \
+  -H 'Content-Type: application/json' -d '<one of the bodies below>'
+```
+
+**`dns-confirm`** — the A record still doesn't resolve to the VM's IP after the
+patience window. Show the user the exact record to create, built from the job's
+own fields:
+
+```
+Type: A    Name: <job.domain>    Value: <job.ip>    Proxy/CDN: OFF (DNS-only)
+```
+
+The CDN-proxy warning matters: an orange-cloud/proxied record breaks both the
+certificate challenge and TLS termination. Then tell them Walnut **keeps
+checking in the background**, so if they add the record now it will continue on
+its own with no further action. Only POST the override once they confirm they
+either added it or want to proceed regardless:
+
+```json
+{"confirmDnsSkip": true}
+```
+
+(Anything else on a `dns-confirm` job is rejected — the field name is exact.)
+
+**`vm-ip`** — manual path: ask for the VM's public IPv4 address and post it.
+Must be a plain dotted IPv4; a hostname is rejected.
+
+```json
+{"ip": "203.0.113.10"}
+```
+
+In sslip mode the hostname is derived from this IP automatically — nothing else
+to collect.
+
+**`credentials`** — the provider needs an API token (also happens after a server
+restart mid-setup, since tokens are held in memory only and never persisted).
+Ask the user to paste it, post it, and then **forget it**: do not repeat it, do
+not save it anywhere, do not put it in a summary.
+
+```json
+{"credentials": "<token the user pasted>"}
+```
+
+Each of these returns **200** `{ job }` and the job continues. **409** means the
+job is not actually waiting for input (someone else answered, or it moved on) —
+re-read `GET /job` before trying again. **400** means the value was rejected
+(bad IPv4, missing field); relay the `error` and ask again.
+
+## 7. Manual path — the user brings their own VM
+
+When `canProvision` is `false` (provider `manual`), or the user prefers a host
+they already have: **start the job first** (section 3), then fetch the boot
+script, which needs the job's pairing code to exist.
+
+```bash
+curl -s "${WALNUT_SERVER_URL:-http://localhost:3456}/api/cloud-setup/user-data?provider=manual"
+```
+
+Optional query params `domainMode` and `domain` default to the job's own values,
+so normally you pass neither. Returns `{ userData, steps, consoleUrl }`.
+**409** means no job with a pairing code exists yet — start the job first.
+
+Print `steps` as the checklist and `userData` verbatim in a fenced code block,
+telling the user to paste it as the VM's cloud-init / user-data (or run it as
+root on the box). This blob is the one thing you handle that contains the
+pairing code by design — it has to, that is what lets the box be claimed. Say
+that plainly: it is a one-time secret, so it belongs in the VM's user-data
+field, not in a chat, a gist, or a ticket.
+
+Then continue from `await-vm`: the job will ask for the VM's public IP
+(section 6, `vm-ip`), and from there polling is identical to section 5.
+
+## 8. When it fails (`status: failed`)
+
+Show two things: `job.error` (the actual cause) and the last few `job.logTail`
+lines (the evidence). Do not paraphrase the error into something vaguer.
+
+Common causes worth translating: a provider CLI that isn't signed in; a
+CloudFormation/quota rejection (the log names it); the box not answering within
+its 20-minute budget — for which the log itself points at
+`/var/log/walnut-setup.log` on the VM; or a box that is already claimed by
+another device, which needs its auth wiped or a redeploy before the code works.
+
+Retry re-runs from the failed step and keeps everything already done:
+
+```bash
+curl -s -X POST ${WALNUT_SERVER_URL:-http://localhost:3456}/api/cloud-setup/job/retry
+```
+
+**200** `{ job }` → resume polling. **409** means it can't be retried right now
+(already running, or already finished). If the user wants to stop instead, use
+`POST /api/cloud-setup/job/cancel` (**200**, or **404** if no job exists).
+
+Retry is safe to offer for infrastructure hiccups — steps are idempotent and an
+AWS re-deploy converges on the same stack rather than creating a second one. If
+the same step fails twice for the same reason, stop retrying and fix the cause.
+
+## 9. Done — and the one step you cannot do
+
+At `status: done`, data sync is live: the Mac's data repo now pushes to the
+companion, so tasks and notes appear there automatically. Tell the user the
+address (`job.domain`).
+
+**The last step is human-only: pairing the phone requires scanning a QR code.**
+Point them at **Settings → Cloud Companion → "Connect your phone"**, which mints
+a device credential and shows the QR for the Walnut iOS app. You cannot scan it
+for them, and you should not try to mint a device token as a substitute — say
+this clearly instead of implying setup is 100% complete.
+
+Then, briefly:
+
+- Costs are running now and are the user's, not Walnut's.
+- **Teardown, if they ever want out: revoke the device tokens FIRST**
+  (Settings → Devices, or `DELETE /api/devices/<name>?target=cloud`), then
+  destroy the infrastructure — on AWS `cd infra && npx cdk destroy
+  WalnutCloudStack`; on Azure `az group delete -n walnut-cloud` (one command,
+  because everything Walnut made lives in that group); on Google Cloud
+  `gcloud compute instances delete walnut-cloud --zone <zone>` **plus**
+  `gcloud compute addresses delete walnut-cloud-ip --region <region>` — the
+  reserved address starts charging once it is no longer attached, so deleting
+  only the instance leaves a small ongoing cost; otherwise delete the VM in the
+  provider console. Order
+  matters: destroying the box first leaves live credentials pointing at an
+  address someone else may later be handed. Note the root volume is deliberately
+  retained on termination, so it may need deleting separately, and it holds
+  their data.
+- Reference docs: `docs/reference/cloud-sync.md` (sync + troubleshooting) and
+  `infra/README.md` (what the stack contains).
+
+## Reporting back
+
+Be honest about state. Good report: which provider and address, which steps
+completed, that sync is verified live, that phone pairing is still pending on
+them, and the monthly cost they've taken on. Never claim "fully set up" while
+the QR hasn't been scanned, and never report success from a `start` 202 alone —
+202 means the job began, not that it worked.

package/dist/data/skills/triage/SKILL.md

@@ -0,0 +1,23 @@
+---
+name: triage
+description: >-
+  Triage and prioritize pending tasks. Use when the user asks to triage,
+  review priorities, clean up stale tasks, or decide what to work on next.
+---
+
+# Task Triage
+
+Review all my non-completed tasks and help me triage them. For each task, consider:
+
+1. **Priority assessment** — is the current priority (immediate/important/backlog/none) correct?
+2. **Staleness** — are there tasks that haven't been touched in a while and should be closed or deprioritized?
+3. **Quick wins** — identify tasks that could be completed quickly
+4. **Dependencies** — are any tasks blocked by other tasks?
+
+Group the output by recommended action:
+- **Do now** — high-impact tasks that should be tackled immediately
+- **Schedule** — important but not urgent, suggest when to work on them
+- **Delegate/Automate** — tasks that could be handled by a session
+- **Drop/Archive** — tasks that are stale or no longer relevant
+
+Be opinionated and direct. If something should be dropped, say so.

package/dist/data/skills/walnut-calendar/SKILL.md

@@ -0,0 +1,92 @@
+---
+name: walnut-calendar
+description: >-
+  Read and edit the user's real calendars (macOS Calendar: iCloud, Google,
+  Exchange accounts) through Walnut's /api/calendar REST endpoints. Use when
+  asked about the user's schedule, meetings, or availability, or to create,
+  move, retime, or delete calendar events. Covers listing events in a date
+  range, enumerating calendars, and write-back that syncs to the cloud
+  provider via macOS.
+---
+
+# Walnut Calendar API
+
+Walnut exposes the Mac's calendars (every account added in macOS System
+Settings → Internet Accounts: iCloud, Google, Exchange, …) over REST. Edits
+write back through macOS EventKit, so a change made here shows up in Google
+Calendar / iCloud within seconds — no separate login or OAuth involved.
+
+Base URL: `http://localhost:3456/api/calendar` (Walnut server).
+
+## Date format contract (IMPORTANT)
+
+All dates are **tz-less local ISO** — the server's local wall time, never a
+`Z` or `+hh:mm` suffix:
+
+- Timed: `2026-08-05T09:00:00`
+- All-day / date-only: `2026-08-05`
+
+## Read
+
+```bash
+# Events in a date range (inclusive days)
+curl -s 'http://localhost:3456/api/calendar/events?from=2026-08-03&to=2026-08-09'
+# → { "events": [ { "id", "title", "start", "end", "allDay", "calendarId",
+#      "calendarName", "accountName", "color", "location?", "readonly?" } ],
+#     "sources": [ { "id": "eventkit", "available", "enabled", "reason?", "message?" } ] }
+
+# List the calendars themselves (to pick a create target)
+curl -s 'http://localhost:3456/api/calendar/sources'
+# → { "sources": [...], "calendars": [ { "id", "title", "account", "color",
+#      "readonly", "hidden" } ] }
+```
+
+- If `sources[0].available` is `false`, read `reason`/`message` — e.g.
+  `permission-denied` means the user must grant Calendar access in System
+  Settings → Privacy & Security → Calendars. `GET /events` still returns
+  `{ events: [] }` in that case rather than erroring.
+- Event ids of recurring occurrences look like `<baseId>#<epoch>`; treat the
+  whole string as opaque and **URL-encode it** in paths (`#` → `%23`).
+
+## Write
+
+Only calendars with `readonly: false` accept writes (a write to a read-only
+calendar returns 409).
+
+```bash
+# Create (end defaults are NOT applied server-side — always send end)
+curl -s -X POST http://localhost:3456/api/calendar/events \
+  -H 'Content-Type: application/json' \
+  -d '{"calendarId":"<id from /sources>","title":"Dentist",
+       "start":"2026-08-05T15:00:00","end":"2026-08-05T16:00:00"}'
+# All-day: use date-only start/end (end inclusive) and "allDay": true.
+
+# Move / retime / rename (start AND end required; PATCH only that occurrence
+# for recurring events)
+curl -s -X PATCH 'http://localhost:3456/api/calendar/events/<url-encoded id>' \
+  -H 'Content-Type: application/json' \
+  -d '{"start":"2026-08-06T15:00:00","end":"2026-08-06T16:00:00","title":"Dentist (moved)"}'
+
+# Delete (only that occurrence for recurring events). Confirm with the user
+# before deleting anything you did not just create.
+curl -s -X DELETE 'http://localhost:3456/api/calendar/events/<url-encoded id>'
+```
+
+## Error codes
+
+| HTTP | code | meaning |
+|---|---|---|
+| 400 | `usage` | bad params / date format |
+| 403 | `permission-denied` | macOS Calendar access not granted (Full Access) |
+| 404 | `not-found` | event id doesn't resolve |
+| 409 | `readonly` | target calendar is read-only |
+| 503 | `disabled` / `cloud` / `not-configured` | source off in Settings, cloud companion (no Mac calendars), or helper unavailable |
+| 502 | other | EventKit helper failure — surface `message` to the user |
+
+## Tips
+
+- The Walnut web calendar (`/calendar`) live-updates after any write — no
+  refresh call needed on your side.
+- To answer "what's on my schedule", query a generous range and filter by
+  `calendarName`/`accountName` yourself if the user means one account.
+- Move = keep the duration: compute `new end = new start + (old end − old start)`.