@rubytech/create-maxy-lite 0.1.4 → 0.1.5

package/payload/skills/calendar-site/template/public/booking.js

@@ -0,0 +1,202 @@
+// Public booking page (calendar-site skill). Dependency-free.
+// 1. Fetch the static availability config shipped with the page.
+// 2. Compute open slots client-side: the weekly window minus a buffer, for the
+//    next two weeks. There is no live free/busy merge, so a slot can collide
+//    with an existing event; the device-side reconcile pass rejects a colliding
+//    booking when it pulls submissions into the vault.
+// 3. Let the visitor pick a slot, collect name/email/note, and POST to the
+//    same-origin Pages Function (/api/book -> D1).
+
+// Pure slot computation, exported for test and reused by the browser code below.
+// availability: { timezone, durationMins, bufferMins, weekly: { mon: [["09:00","17:00"]], ... } }
+// from: a Date marking "now". daysAhead: how many days forward to offer.
+// Returns [{ start, end }] as timezone-naive ISO strings (YYYY-MM-DDTHH:MM:00).
+function computeSlots(availability, from, daysAhead) {
+  var DAY_KEYS = ['sun', 'mon', 'tue', 'wed', 'thu', 'fri', 'sat'];
+  var durationMins = availability.durationMins;
+  var stepMins = availability.durationMins + availability.bufferMins;
+  var weekly = availability.weekly || {};
+  var out = [];
+
+  function pad(n) { return (n < 10 ? '0' : '') + n; }
+  function toMinutes(hhmm) {
+    var parts = hhmm.split(':');
+    return parseInt(parts[0], 10) * 60 + parseInt(parts[1], 10);
+  }
+  function naive(date, mins) {
+    var y = date.getFullYear();
+    var m = pad(date.getMonth() + 1);
+    var d = pad(date.getDate());
+    var hh = pad(Math.floor(mins / 60));
+    var mm = pad(mins % 60);
+    return y + '-' + m + '-' + d + 'T' + hh + ':' + mm + ':00';
+  }
+
+  for (var dayOffset = 0; dayOffset < daysAhead; dayOffset++) {
+    var day = new Date(from.getFullYear(), from.getMonth(), from.getDate() + dayOffset);
+    var windows = weekly[DAY_KEYS[day.getDay()]] || [];
+    for (var w = 0; w < windows.length; w++) {
+      var winStart = toMinutes(windows[w][0]);
+      var winEnd = toMinutes(windows[w][1]);
+      for (var t = winStart; t + durationMins <= winEnd; t += stepMins) {
+        var startStr = naive(day, t);
+        if (new Date(startStr) < from) continue; // drop past slots
+        out.push({ start: startStr, end: naive(day, t + durationMins) });
+      }
+    }
+  }
+  return out;
+}
+
+if (typeof module !== 'undefined' && module.exports) {
+  module.exports = { computeSlots };
+}
+
+(function () {
+  'use strict';
+  if (typeof document === 'undefined') return; // running under Node for tests
+
+  var DAYS_AHEAD = 14;
+
+  var statusEl = document.getElementById('bk-status');
+  var slotsEl = document.getElementById('bk-slots');
+  var formEl = document.getElementById('bk-form');
+  var chosenEl = document.getElementById('bk-chosen');
+  var doneEl = document.getElementById('bk-done');
+  var doneMsg = document.getElementById('bk-done-msg');
+  var durationEl = document.getElementById('bk-duration');
+  var backBtn = document.getElementById('bk-back');
+
+  var chosenSlot = null;
+
+  function setStatus(msg) {
+    statusEl.textContent = msg || '';
+  }
+  function fmtDayHeading(d) {
+    return d.toLocaleDateString([], { weekday: 'long', month: 'long', day: 'numeric' });
+  }
+  function fmtTime(d) {
+    return d.toLocaleTimeString([], { hour: 'numeric', minute: '2-digit' });
+  }
+
+  function renderSlots(slots, durationMins) {
+    if (durationMins) {
+      durationEl.textContent = durationMins + ' minute meeting';
+    }
+    if (slots.length === 0) {
+      setStatus('No open times in the next two weeks. Please check back later.');
+      return;
+    }
+    setStatus('');
+
+    var byDay = {};
+    var order = [];
+    slots.forEach(function (s) {
+      var start = new Date(s.start);
+      var key = start.toDateString();
+      if (!byDay[key]) {
+        byDay[key] = [];
+        order.push(key);
+      }
+      byDay[key].push(s);
+    });
+
+    order.forEach(function (key) {
+      var group = document.createElement('div');
+      group.className = 'bk-day';
+      var h = document.createElement('h2');
+      h.className = 'bk-day-title';
+      h.textContent = fmtDayHeading(new Date(key));
+      group.appendChild(h);
+
+      var row = document.createElement('div');
+      row.className = 'bk-day-slots';
+      byDay[key].forEach(function (s) {
+        var btn = document.createElement('button');
+        btn.type = 'button';
+        btn.className = 'bk-slot';
+        btn.textContent = fmtTime(new Date(s.start));
+        btn.addEventListener('click', function () {
+          chooseSlot(s);
+        });
+        row.appendChild(btn);
+      });
+      group.appendChild(row);
+      slotsEl.appendChild(group);
+    });
+  }
+
+  function chooseSlot(slot) {
+    chosenSlot = slot;
+    var start = new Date(slot.start);
+    chosenEl.textContent = fmtDayHeading(start) + ' at ' + fmtTime(start);
+    slotsEl.hidden = true;
+    formEl.hidden = false;
+  }
+
+  backBtn.addEventListener('click', function () {
+    chosenSlot = null;
+    formEl.hidden = true;
+    slotsEl.hidden = false;
+  });
+
+  formEl.addEventListener('submit', function (e) {
+    e.preventDefault();
+    if (!chosenSlot) return;
+    var fd = new FormData(formEl);
+    var payload = {
+      slotStart: chosenSlot.start,
+      slotEnd: chosenSlot.end,
+      name: fd.get('name'),
+      email: fd.get('email'),
+      note: fd.get('note'),
+      company: fd.get('company'),
+    };
+    var submitBtn = formEl.querySelector('.bk-submit');
+    submitBtn.disabled = true;
+    submitBtn.textContent = 'Booking…';
+
+    fetch('/api/book', {
+      method: 'POST',
+      headers: { 'content-type': 'application/json' },
+      body: JSON.stringify(payload),
+    })
+      .then(function (res) {
+        return res.json().then(function (body) {
+          return { ok: res.ok, body: body };
+        });
+      })
+      .then(function (r) {
+        if (!r.ok || !r.body.ok) {
+          throw new Error((r.body && r.body.error) || 'Booking failed');
+        }
+        formEl.hidden = true;
+        doneEl.hidden = false;
+        var start = new Date(chosenSlot.start);
+        doneMsg.textContent = 'Confirmed for ' + fmtDayHeading(start) + ' at ' + fmtTime(start) + '. A confirmation will follow by email.';
+      })
+      .catch(function (err) {
+        submitBtn.disabled = false;
+        submitBtn.textContent = 'Confirm booking';
+        setStatus('Sorry, that did not go through: ' + err.message + '. Please try again.');
+      });
+  });
+
+  function load() {
+    setStatus('Loading available times…');
+    fetch('/availability.json')
+      .then(function (res) {
+        if (!res.ok) throw new Error('HTTP ' + res.status);
+        return res.json();
+      })
+      .then(function (availability) {
+        var slots = computeSlots(availability, new Date(), DAYS_AHEAD);
+        renderSlots(slots, availability.durationMins);
+      })
+      .catch(function () {
+        setStatus('Could not load available times right now. Please refresh in a moment.');
+      });
+  }
+
+  load();
+})();

package/payload/skills/calendar-site/template/public/index.html

@@ -0,0 +1,44 @@
+<!DOCTYPE html>
+<html lang="en">
+<head>
+  <meta charset="UTF-8" />
+  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
+  <title>Book a time</title>
+  <link rel="stylesheet" href="/booking.css" />
+</head>
+<body>
+  <main class="bk-card">
+    <h1 class="bk-title">Book a time</h1>
+    <p class="bk-sub" id="bk-duration"></p>
+
+    <div id="bk-status" class="bk-status" role="status"></div>
+
+    <section id="bk-slots" class="bk-slots" aria-label="Available times"></section>
+
+    <form id="bk-form" class="bk-form" hidden>
+      <p class="bk-chosen" id="bk-chosen"></p>
+      <label class="bk-label">Name
+        <input class="bk-input" type="text" name="name" required autocomplete="name" />
+      </label>
+      <label class="bk-label">Email
+        <input class="bk-input" type="email" name="email" required autocomplete="email" />
+      </label>
+      <label class="bk-label">Note (optional)
+        <textarea class="bk-input" name="note" rows="3"></textarea>
+      </label>
+      <!-- honeypot: hidden from people, tempting to bots -->
+      <input class="bk-hp" type="text" name="company" tabindex="-1" autocomplete="off" aria-hidden="true" />
+      <div class="bk-actions">
+        <button class="bk-back" type="button" id="bk-back">Back</button>
+        <button class="bk-submit" type="submit">Confirm booking</button>
+      </div>
+    </form>
+
+    <div id="bk-done" class="bk-done" hidden>
+      <h2 class="bk-done-title">You are booked</h2>
+      <p id="bk-done-msg" class="bk-done-msg"></p>
+    </div>
+  </main>
+  <script src="/booking.js"></script>
+</body>
+</html>

package/payload/skills/calendar-site/template/schema.sql

@@ -0,0 +1,19 @@
+-- D1 schema for the booking site (calendar-site skill).
+-- One row per public booking submission. Captured at the edge so a submission
+-- survives while the device is offline or asleep; the calendar-site reconcile
+-- pass later reads accepted, unswept rows and writes each into the vault as an
+-- Event (then marks the row swept).
+CREATE TABLE IF NOT EXISTS bookings (
+  id        INTEGER PRIMARY KEY AUTOINCREMENT,
+  bookingId TEXT UNIQUE NOT NULL,
+  slotStart TEXT NOT NULL,
+  slotEnd   TEXT NOT NULL,
+  name      TEXT NOT NULL,
+  email     TEXT NOT NULL,
+  note      TEXT,
+  status    TEXT NOT NULL DEFAULT 'accepted',
+  createdAt TEXT NOT NULL,
+  swept     INTEGER NOT NULL DEFAULT 0
+);
+
+CREATE INDEX IF NOT EXISTS bookings_unswept ON bookings (status, swept);

package/payload/skills/calendar-site/template/wrangler.toml

@@ -0,0 +1,14 @@
+# Cloudflare Pages config for the booking site (calendar-site skill).
+# The skill fills the placeholders at assemble time:
+#   __PROJECT_NAME__     the Pages project name
+#   __D1_DATABASE_NAME__ the D1 database name
+#   __D1_DATABASE_ID__   the id printed by `wrangler d1 create`
+name = "__PROJECT_NAME__"
+pages_build_output_dir = "public"
+compatibility_date = "2024-01-01"
+compatibility_flags = ["nodejs_compat"]
+
+[[d1_databases]]
+binding = "DB"
+database_name = "__D1_DATABASE_NAME__"
+database_id = "__D1_DATABASE_ID__"

package/payload/skills/contacts/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: contacts
+description: Create, look up, and update people and organizations in the vault. Use when the user mentions a person or company to remember, asks who someone is, wants a contact's email or phone, links someone to where they work, or asks to update a contact's details. Owns the Person and Organization entities of the maxy-lite SCHEMA.
+---
+
+# Contacts
+
+The address book lives in the vault as one markdown file per contact. A **Person** is a file in `people/`; an **Organization** is a file in `organizations/`. Each file is YAML frontmatter (the typed fields) plus a markdown body for free notes about the contact. The authoritative field list is [`SCHEMA.md`](../../schema/SCHEMA.md) under *Contacts*. Read it before writing fields you are unsure of; the validator parses the same tables.
+
+## Person (`people/<Full Name>.md`)
+
+Required: `type: person` and `name` (the full display name). Optional, all from vCard: `firstName`, `lastName`, `nickname`, `emails` (a list), `tels` (a list), `title`, `role`, `address`, `birthday` (`YYYY-MM-DD`), `anniversary`, `urls` (a list), `categories` (a list), `area`. Set only the fields you actually know; do not invent values to fill a field.
+
+```yaml
+---
+type: person
+name: Jane Doe
+firstName: Jane
+lastName: Doe
+emails:
+  - jane@acme.example
+tels:
+  - "+44 7700 900000"
+org: "[[Acme Ltd]]"
+title: Head of Design
+area: work
+---
+Met at the London conference. Prefers email over phone.
+```
+
+## Organization (`organizations/<Name>.md`)
+
+Required: `type: organization` and `name`. Optional: `domain`, `website`, `industry`, `companyType`, `employees` (number), `revenue` (number), `phone`, `city`, `state`, `country`, `area`.
+
+## Linking a person to where they work
+
+A Person's `org` field is a single link to an Organization file; an Organization's `members` field is a list of links to Person files. A link is the target's basename in wikilink form, e.g. `org: "[[Acme Ltd]]"`. The Organization file must already exist, or the link dangles and fails. When you link a person to an organization that is not in the vault yet, create the Organization file first, then set `org`.
+
+## Looking someone up
+
+The vault is the index. To find a contact, Grep the frontmatter, not your memory:
+
+- by name: `grep -rl "name: Jane" people/`
+- by email: `grep -rl "jane@acme.example" people/`
+- everyone at a company: `grep -rl "\[\[Acme Ltd\]\]" people/` (people whose `org` points at it)
+
+Read the matched file for the full record, and follow its `org` link to the organization. Keep each filename unique: the validator resolves links by basename, so two `Jane Doe.md` files in different folders cannot be told apart.
+
+## After every write, validate
+
+The SCHEMA is enforced by a deterministic validator, not by convention. After creating or editing any contact file, run it over the vault:
+
+```sh
+maxy-lite-validate "$HOME/maxy"
+```
+
+It prints one `[lite-schema] op=validate ... ok=<bool>` line per file and exits 0 only when every file conforms. If a line names the file you just wrote with `ok=false`, the bracketed error names the violation: `name:missing` (a required field is absent), `field:type` (wrong value type), `area:area` (an area outside the controlled vocabulary), `org:dangling` (the linked organization file does not exist), `org:target` (the link points at a file of the wrong type). Fix the named field and re-run until that file is `ok=true`. Never leave a contact you wrote in a failing state.

package/payload/skills/memory/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: memory
+description: Remember and recall facts across sessions. Use when the user says to remember something, asks what you know about a person or topic, refers to something told to you earlier, or when you need to recover context at the start of a session. The vault is the memory; this skill is the convention for writing facts into it and reading them back.
+---
+
+# Memory
+
+There is no separate memory store. The vault is the memory: every fact you need to keep lives as frontmatter or body text in a vault file, and recall is reading those files back. This skill is thin on purpose. It codifies two things: where a fact goes when you learn it, and how to find a fact when you need it. The entity field lists are in [`SCHEMA.md`](../../schema/SCHEMA.md); the `contacts`, `work`, and `projects` skills own their respective writes.
+
+## Where a new fact goes
+
+A fact almost always belongs to something that already has a file. Put it there, not in a parallel store:
+
+- A fact **about a person or organization** (a preference, a relationship, a detail) goes in the body of that contact's file, or as a typed field if the SCHEMA has one for it (a new email goes in `emails`, a birthday in `birthday`). Edit the existing file.
+- A fact that **is** a thing the SCHEMA already models (a task to do, an event, a document) is created with the matching skill, not written as loose memory.
+- A standalone fact that belongs to **no existing entity** becomes a **Note**: a file in `activities/` with `type: note`, a `title`, and the fact in the markdown body. Link it to whatever it concerns with `about` so it is reachable by traversal.
+
+```yaml
+---
+type: note
+title: Jane wine preference
+about: "[[Jane Doe]]"
+area: personal
+---
+Jane prefers Rioja. Mentioned at the conference dinner.
+```
+
+Prefer enriching an existing file over creating a new note. A note is for a fact with no better home.
+
+## How to recall
+
+Recall is search over the vault, in this order:
+
+1. **Grep the frontmatter and body** for the term: `grep -rl "Rioja" .` finds every file mentioning it; `grep -rl "name: Jane" people/` finds the contact.
+2. **Read the matched file** for the full record.
+3. **Follow the links** to pull in connected context: a note's `about`, a person's `org`, a task's `project`. Traversal is following basenames between files.
+
+At the start of a session with no context, recall is the same move: Grep for the names or topics the user raises, read what comes back, and follow the links. Nothing is remembered that is not in a file, so if a fact is not found by Grep it was never written; write it.
+
+## After writing a fact, validate
+
+When a fact is written as a new note or by editing an entity file, run the deterministic validator over the vault:
+
+```sh
+maxy-lite-validate "$HOME/maxy"
+```
+
+It exits 0 only when every file conforms. If a line names the note you just wrote with `ok=false`, the bracketed error names the violation: `title:missing` (a note needs a title), `area:area` (an area outside the controlled vocabulary), `about:dangling` (the linked file does not exist). Fix the named field and re-run until that file is `ok=true`. A fact left in a failing file is a fact that will not be trusted on recall.

package/payload/skills/projects/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: projects
+description: Create and track multi-step efforts in the vault and tie tasks, events, and documents to them. Use when the user describes something with several moving parts (a holiday, a house move, a renovation, a launch), asks to start a project, wants to see everything related to one, or wants to file a task or event under a project. Owns the Project entity of the maxy-lite SCHEMA.
+---
+
+# Projects
+
+A **Project** is a multi-step effort that ties together the tasks, events, and documents it involves. It is one file in `projects/`: YAML frontmatter plus a markdown body for the plan, status notes, and links. The authoritative field list is [`SCHEMA.md`](../../schema/SCHEMA.md) under *Projects*.
+
+## Project (`projects/<Name>.md`)
+
+Required: `type: project`, `name`, and `area` (one of the controlled areas in the SCHEMA). Optional: `status` (`active` / `done` / `someday`), `startDate`, `dueDate` (`YYYY-MM-DD`), `about` (a single link to anything the project centres on). `area` is required for a project, unlike for a contact or task, so always set it.
+
+```yaml
+---
+type: project
+name: House Move
+area: home
+status: active
+startDate: 2026-06-01
+dueDate: 2026-09-30
+---
+Moving from the London flat to the house in Bristol. Survey, mortgage, packers, schools.
+```
+
+## Tying tasks and events to a project
+
+A project does not list its members in its own frontmatter. Instead each Task or Event carries a `project` link back to the project. To file an item under a project, edit the item and set its `project` field to the project's basename in wikilink form, e.g. in a task file `project: "[[House Move]]"`. The project file must exist first. The `work` skill owns the Task fields; this skill owns the Project file.
+
+## Seeing everything in a project
+
+The links point inward, so Grep for the project's name across the activity and calendar folders:
+
+- tasks in a project: `grep -rl "\[\[House Move\]\]" activities/`
+- events in a project: `grep -rl "\[\[House Move\]\]" calendar/`
+
+Read the matched files for the detail. To close a project, edit its `status` to `done`; do not delete the file.
+
+## After every write, validate
+
+After creating or editing a project file (or after setting a `project` link on a task or event), run the deterministic validator over the vault:
+
+```sh
+maxy-lite-validate "$HOME/maxy"
+```
+
+It exits 0 only when every file conforms. If a line names the project you just wrote with `ok=false`, the bracketed error names the violation: `name:missing` or `area:missing` (a required field is absent), `area:area` (an area outside the controlled vocabulary), `about:dangling` (the linked file does not exist), `startDate:type` or `dueDate:type` (a malformed date). Fix the named field and re-run until that file is `ok=true`. Never leave a project you wrote in a failing state.

package/payload/skills/publish-site/SKILL.md

@@ -0,0 +1,21 @@
+---
+name: publish-site
+description: Put a built site or page online and hand back a live link. Use when the user says publish, host, put this online, make it live, or share a link to a deck or page. Routes to `site-deploy`, which deploys to Cloudflare Pages so the page stays up with the phone offline.
+---
+
+# Publish a site
+
+This is the intent router for "make it live". When the user wants a page online, you confirm what to publish and where the files are, then hand off to [`site-deploy`](../site-deploy/SKILL.md), which does the actual Cloudflare Pages deploy and returns the URL.
+
+## What you need before routing
+
+- A folder of static files ready to go: an [`slides`](../slides/SKILL.md) deck (the `.html` file plus its `media/` folder, if any), a landing page, or any HTML tree. If the site is not built yet, build it first; this skill does not generate content.
+- A project slug (lowercase, hyphenated). Offer one derived from the site's name and confirm it with the user, because the slug is the live address.
+
+## Where it gets hosted
+
+Cloudflare Pages is the lite default: the page is hosted on Cloudflare's edge and stays reachable when the phone is off. There is one hosting path in lite, so there is nothing to choose between; serving a page from the device itself is not part of lite. Hand the folder and the slug to `site-deploy` and relay the live URL it returns.
+
+## After it is live
+
+`site-deploy` gates "done" on a live `200` with the right content and gives back the URL. Surface that URL to the user as the result. If the deploy fails on authentication, the fix is `wrangler login`, per `site-deploy`.

package/payload/skills/scheduling/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: scheduling
+description: Create, update, and cancel calendar events as vault files, and sync them to Google Calendar. This is the skill behind "put a meeting on my calendar", "schedule a call", "move that appointment", "cancel the meeting", and "add this to Google Calendar". The vault Event file is the source of truth; the Google Calendar connector is pushed to after the file is written and validated. A push that fails leaves a correct local Event, never lost.
+---
+
+# Schedule, update, and cancel events
+
+An event in the vault is one file under `calendar/`, shaped by the Event entity in the SCHEMA (`schema/SCHEMA.md`). This skill writes that file, validates it, then pushes the change to Google Calendar. The order is fixed and it matters: the vault is authoritative, so the file is written and proven conformant before anything leaves the device.
+
+## The Event file
+
+Write `calendar/<summary>.md`. The frontmatter carries the typed fields; the markdown body holds the meeting notes, agenda, or call notes (free prose, never in frontmatter).
+
+```
+---
+type: event
+summary: Intro call with Acme
+start: 2026-07-01T15:00:00
+end: 2026-07-01T15:30:00
+location: Google Meet
+attendees:
+  - "[[Jane Doe]]"
+organizer: "[[John Smith]]"
+project: "[[Acme Onboarding]]"
+recurrence: FREQ=WEEKLY;BYDAY=TU
+status: CONFIRMED
+area: work
+---
+
+Agenda and notes live here.
+```
+
+Field rules, taken straight from the SCHEMA so a write never drifts:
+
+- `type` is always `event` and `summary` and `start` are required. Everything else is optional.
+- `start` and `end` are an ISO date (`2026-07-01`) or date-time (`2026-07-01T15:00:00`).
+- `attendees` is a list of `[[Person]]` links and `organizer` is a single `[[Person]]` link. Each link resolves by basename to a file in `people/`; create the Person first if it does not exist, so the link is not dangling.
+- `project` is a single `[[Project]]` link resolving into `projects/`.
+- `recurrence` is a raw iCalendar `RRULE` string (for example `FREQ=WEEKLY;BYDAY=TU`). It is stored only. This skill does not expand recurrences or fire anything on a schedule.
+- `status` mirrors iCalendar: `CONFIRMED`, `TENTATIVE`, or `CANCELLED`.
+- `area` is one of the SCHEMA Areas, when the event belongs to one.
+
+## The fixed order: write, validate, then push
+
+Every create, update, and cancel follows the same three steps in this order.
+
+1. Write the Event file to `calendar/`.
+2. Run the validator over the vault and read its exit code:
+
+   ```bash
+   maxy-lite-validate <vault>
+   ```
+
+   Exit 0 means every file conforms. A non-zero exit with `ok=false` on the Event you just wrote means the file drifted from the SCHEMA (a missing required field, a bad area, a dangling `[[Person]]` link). Fix the file and re-run until it exits 0. Never leave a non-conformant Event.
+
+3. Only after the validator exits 0, push the event to the Google Calendar connector: create the calendar event for a new file, update it for an edited file, cancel it for a cancellation. Use whatever the Google Calendar connector exposes for that action; do not hardcode a tool name.
+
+This order is what "vault-authoritative" means here. The local file is correct and proven before the network is touched.
+
+## When the push fails
+
+A Google Calendar push can fail while the local Event is perfectly valid. That is a sync problem, not data loss. Keep the local file exactly as written, report that the calendar push did not land and why, and offer to retry the push. Do not roll back, do not delete the Event, and do not treat it as a schema problem. The two failure modes are distinct:
+
+- Validator non-zero on the Event: schema drift. Fix the file.
+- Validator 0 but the push returned an error: sync issue. The file is correct; retry the push.
+
+## Update and cancel
+
+- Update: edit the Event file in place, run the validator to 0, then push the update to Google Calendar.
+- Cancel: set `status: CANCELLED` in the frontmatter, run the validator to 0, then push the cancellation to Google Calendar. Keep the file. A cancelled event is a retained record with a cancelled status, not a deleted file.
+
+## Conflicts
+
+The vault wins. If the same event differs between the vault and Google Calendar, the vault file is correct and the connector is brought into line with it on the next push. Richer two-way merge is out of scope for this skill.

package/payload/skills/site-deploy/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: site-deploy
+description: Deploy a folder of static HTML and assets to Cloudflare Pages and return a live URL that stays up with the phone offline. Use when a site or page is built and ready to go live, or when a live site is stale and needs redeploying. Runs `wrangler pages deploy` over Bash; the page is edge-hosted, not served from the device. This is the implementer behind `publish-site`.
+---
+
+# Deploy a site to Cloudflare Pages
+
+You take one folder of static files (an [`slides`](../slides/SKILL.md) deck, a landing page, any HTML tree) and put it live on Cloudflare's edge. Cloudflare hosts the build, so the page stays reachable when the phone is off. The live URL is the deliverable.
+
+The mechanism is the `wrangler` CLI, run over Bash. It is already available through Node; invoke it with `npx wrangler` if it is not on the path. Nothing here uses an MCP connector: the Cloudflare connector cannot deploy Pages, and its login is not reachable from the shell.
+
+## Auth, once
+
+`wrangler` needs to be signed in to the Cloudflare account. Two ways, in order of preference:
+
+- `npx wrangler login` opens the Cloudflare OAuth page in the browser and persists the session. Do this once; later deploys reuse it. This is the on-device default.
+- Or set `CLOUDFLARE_API_TOKEN` (a token with **Account · Cloudflare Pages · Edit**) and `CLOUDFLARE_ACCOUNT_ID` in the environment. Never write the token into the project folder, never commit it, never print it.
+
+If neither is present, `wrangler` reports it is not authenticated. Stop and tell the user to run `wrangler login`; do not guess a token.
+
+## Deploy
+
+Pick a project slug (lowercase, hyphenated, derived from the site's name). The first deploy of a new slug creates the project.
+
+```bash
+npx wrangler pages deploy <output-dir> --project-name <slug> --branch=main
+```
+
+`--branch=main` deploys to the production alias `https://<slug>.pages.dev`; any other branch name produces a preview URL instead. `wrangler` prints the deployment URL. Surface the operation as verb plus target ("deploying Pages project `<slug>`"); the token value never appears in chat or stdout.
+
+## Custom domain (optional)
+
+By default the site answers on `<slug>.pages.dev`, which is enough for most uses. To serve it on the user's own domain, attach the domain to the Pages project in the Cloudflare dashboard (**Workers & Pages → the project → Custom domains → Set up a domain**). When the zone is on the same Cloudflare account, Cloudflare provisions the certificate and the DNS record itself. A custom domain is optional polish; do not block the deploy on it.
+
+## Done is a live 200, not a clean exit
+
+A successful `wrangler` run is not the finish line. The finish line is the live URL serving the new content. Check it, cache-busted, and read the first line:
+
+```bash
+curl -s "https://<slug>.pages.dev/?cb=$(date +%s)" -D - -o /tmp/site.html | head -1
+```
+
+Done holds only when all are true:
+
+- the status line is `HTTP/2 200` (or `HTTP/1.1 200 OK`); a `522` is the certificate window on a fresh custom domain, so wait and re-curl rather than calling it done,
+- the body carries a content marker you can name in advance (a headline or title from this site), not a leftover from whatever the folder was copied from.
+
+Any other status, or a missing or stale marker, blocks done and is reported with the exact failing URL. Record the live URL and this check in the result so it can be re-run later to confirm the site is still up without reading the source.
+
+## Out of scope
+
+Building the HTML (that is [`slides`](../slides/SKILL.md) or whatever produced the folder), form-to-database capture, and serving from the device over a tunnel. The lite default is Pages, which survives the phone going offline; device-origin hosting is not part of lite.

package/payload/skills/slides/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: slides
+description: Build a slide deck or a single web page as one self-contained HTML file from vault content. Use when the user asks for a deck, slides, a presentation, a pitch, a talk, a one-pager, or a landing page, or wants to turn notes, a project, or a meeting into something they can present or publish. Produces one HTML file with inline CSS and JS, no build step. Pair with `publish-site` / `site-deploy` to put it online.
+---
+
+# Slides and pages
+
+You produce **one self-contained HTML file**: inline CSS and JS, no build step, no dependencies beyond the Inter web font. It opens straight in a browser, navigates with arrow keys, space, or swipe, and exports to PDF with `P`. To put it online, hand the file to [`publish-site`](../publish-site/SKILL.md).
+
+The starting point is [`deck.html`](deck.html) in this folder. Copy it, then change only the content. It carries the design tokens, the component library (21 components, indexed in a comment at the top of the file), the headline pattern, and the keyboard/swipe/PDF behaviour. Stay on its tokens; do not invent a new colour scheme or font.
+
+## Use what the user gave you
+
+The user's message and the vault are the brief. Pull the content from where it already lives: a Project file and its linked Tasks, a set of Notes, a meeting, a person or organization. Read those files, do not re-ask for what the vault already holds. Only ask once, in one short question, if you genuinely have no idea what the deck is about.
+
+## Pick the shape, then outline
+
+Most decks fit the six-beat story arc. Choose the timing to the format; the proportions hold.
+
+| Beat | ~Share | Purpose |
+|------|--------|---------|
+| Open | 10% | Hook the room with a confession, a contradiction, or a surprising fact |
+| The world before | 15% | The status quo the audience already lives in, to build recognition |
+| The turn | 15% | Name the one thing that changed, cleanly |
+| The evidence | 40% | Three to five concrete proof points: pain → action → result |
+| The honest part | 15% | The caveat, the cost, the open question; this earns trust |
+| Close | 5% | Land one line |
+
+For a pitch lean into problem → market → product → traction → ask; for a one-pager or landing page drop the navigation idea and write a single long scrolling section. The arc is a default, not a cage.
+
+Write the slide-by-slide outline first (number, component, headline, which beat) and show it to the user before you write HTML. Get a nod, then build.
+
+## Write the HTML
+
+Copy the matching component from `deck.html` and swap the text. The headline pattern is the visual identity: a bold anchor phrase plus a dim extension that fades.
+
+```html
+<h1>Anchor. <span class="dim">Extension that fades.</span></h1>
+```
+
+One dark slide per deck at most; it loses its weight if every slide is dark. Keep claims true to the vault; do not invent numbers to fill a stat grid. Drop images into a `media/` folder beside the HTML and reference them with relative paths.
+
+## When the user wants it online
+
+A deck or page is a static HTML file, so it deploys to Cloudflare Pages like any site. When the user asks to publish, host, or share a live link, hand the file (and its `media/` folder, if any) to [`publish-site`](../publish-site/SKILL.md), which routes to [`site-deploy`](../site-deploy/SKILL.md). The result is an edge-hosted URL that stays live with the phone offline.