@rubytech/create-maxy-lite 0.1.4 → 0.1.6

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.