@topy-ai/maggie 0.7.49 → 0.7.51

package/bundled-skills/catalog.json

@@ -2,6 +2,10 @@
   "schemaVersion": "maggie-skill-catalog.v1",
   "generatedFrom": "skills/*/SKILL.md",
   "skills": [
+    {
+      "name": "maggie-assistant-tools",
+      "description": "Build an AI assistant's tools once and expose them safely to an in-app agent, an MCP server and ChatGPT/Claude apps. Use for tool registries, risk levels and gates, approval cards with signed one-time tokens, audit logs, MCP annotations, user-facing capability pages, publishing product CLI/MCP packages and app reviews, and multi-tenant assistant bridge hosts."
+    },
     {
       "name": "maggie-auth-reference",
       "description": "Generate and validate a provider-neutral traditional email/password auth reference with secure server sessions and production security gates."
@@ -54,6 +58,10 @@
       "name": "maggie-memory",
       "description": "Persist and retrieve confirmed user preferences, project conventions, lessons from repaired mistakes, and structured error history across Maggie skill runs."
     },
+    {
+      "name": "maggie-mobile-app",
+      "description": "Ship a cross-platform product app from one Expo / React Native codebase to web, iOS and Android. Use for the dev server, web deploy, EAS build profiles, TestFlight and Play internal testing, EAS Update channels and runtime versions, store-review rules, and a release preflight with a cost notice before every build."
+    },
     {
       "name": "maggie-ops",
       "description": "Build, connect, operate, upgrade, and verify a private Maggie Ops dashboard for blog content, API Pull, sitemap matching, rewrite approvals, reports, and integrations. Use when the user asks for Ops/admin functionality or lifecycle operations rather than public blog pages."

package/bundled-skills/maggie-assistant-tools/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: maggie-assistant-tools
+description: Build an AI assistant's tools once and expose them safely to an in-app agent, an MCP server and ChatGPT/Claude apps. Use for tool registries, risk levels and gates, approval cards with signed one-time tokens, audit logs, MCP annotations, user-facing capability pages, publishing product CLI/MCP packages and app reviews, and multi-tenant assistant bridge hosts.
+metadata:
+  version: 1.0.0
+---
+
+# Maggie Assistant Tools
+
+## Automatic memory hook
+
+Follow [Maggie Memory Hook](../../references/memory-hook.md) at invocation and completion.
+
+Use the shared [Maggie decision loop](../../references/decision-loop.md) before changing risk levels, publishing a package, or submitting an app for review.
+
+## One registry, many surfaces
+
+Define every tool once in product code and export it as
+`maggie-assistant-tool-registry.v1` JSON
+([schema](../../bundled-contracts/maggie-assistant-tools/tool-registry-v1.schema.json),
+[example](../../bundled-contracts/maggie-assistant-tools/tool-registry-example-v1.json)).
+The in-app agent, the MCP server, ChatGPT/Claude apps and the capability page
+all read that one definition. Per tool:
+
+| Field | Meaning |
+|---|---|
+| `name` | snake_case, stable; model-facing only |
+| `description` | model-facing; never shown to people |
+| `user.label` / `user.detail` | what people see (≤ 60 characters / one line) |
+| `user.confirm` | the approval-card sentence; required for every write |
+| `risk` | `read`, `write-reversible`, `write-spends` (credits, quota, AI generation), `write-public` (public or hard to undo), `never` (the assistant must not do it) — `R0`…`W4` are accepted aliases |
+| `gates` | declared preconditions, e.g. `verified-site`, `credits`, `ai-generation` |
+| `scope` | `account` or `workspace`; account writes are audited at account scope |
+| `channels` | `in-app`, `mcp`, `chatgpt`, `claude`, `cli` |
+
+Write user copy by hand. Rewriting model descriptions with regexes ("the
+user" → "you", dropping `(from connected_apps_list)`) needs overrides for a
+large share of tools and drifts. The validator rejects user copy that
+contains snake_case names, "the user", or "(from tool)" references.
+
+```bash
+maggie assistant registry-validate --registry tools.registry.json
+maggie assistant annotations --registry tools.registry.json --mcp-tools tools-list.json
+maggie assistant capability-page --registry tools.registry.json --output docs/assistant-can-do.md
+```
+
+`annotations` derives MCP hints from risk — `readOnlyHint` for `read`,
+`destructiveHint` for `write-public`/`never` and destructive-sounding names
+(`*_delete`, `*_remove`, `*_revoke`, `*_discard`, as app reviewers expect),
+`idempotentHint` for reads and declared idempotent writes, `openWorldHint` for
+public writes — and reports drift against an exported `tools/list`. `never`
+tools are not served on MCP; list them on the capability page instead.
+
+`capability-page` groups tools into "looks things up", "changes things after
+you approve" and "publishes or is hard to undo", plus a "can't do" section
+from `cantDo` entries and `never` tools, using only user copy.
+
+## Approvals and audit
+
+Read [approvals and audit](references/approvals-and-audit.md) before
+implementing writes. In short: a write runs only with a signed, short-lived,
+single-use approval bound to the exact calls, caller and scope; the token is
+stored with the model turn on the server so a client answering only yes/no
+works; every write produces one audit entry with a readable summary.
+
+```bash
+maggie assistant approval-selftest
+maggie assistant audit-check --registry tools.registry.json --session recorded-session.json
+```
+
+## Publishing product CLIs and MCP servers
+
+See [product release](references/product-release.md):
+
+```bash
+maggie product release-check --package apps/cli --server-json apps/cli/server.json --changelog apps/cli/CHANGELOG.md --pack
+maggie product smoke --package apps/cli
+maggie product mcp-check --mcp-url https://mcp.example.com/mcp
+maggie product review-status --reviews reviews.json --chatgpt-plugin apps/mcp/chatgpt-plugin/plugin.json
+```
+
+## Hosting many users' assistant sessions
+
+See [bridge host](references/bridge-host.md) and
+`maggie deployment bridge-plan|bridge-collect-script|bridge-check`.
+
+## Hard boundaries
+
+- Never let the model see or choose an approval token; never accept a write
+  without one.
+- Never expose `never` tools or billing changes on MCP or third-party apps.
+- Never publish a package or submit an app for review without an explicit
+  yes; these commands only check.

package/bundled-skills/maggie-assistant-tools/references/approvals-and-audit.md

@@ -0,0 +1,54 @@
+# Approvals and audit for assistant writes
+
+## Approval token
+
+Reference implementation: `tools/runtime/assistant_approval.py` (exercised by
+`maggie assistant approval-selftest`).
+
+- Payload: `{id, calls: [{name, args}], principal, scope, expires}`.
+  `principal` is a hash of the caller identity (API key or user), never the
+  raw key. `scope` is `account` or the workspace/site ID.
+- Token: `base64url(canonical JSON) + "." + base64url(HMAC-SHA256)`, TTL
+  about 10 minutes, secret held by the server only.
+- Verify signature, expiry, principal, scope and the exact canonical calls.
+  If the model changes an argument after approval, the call is refused.
+- Single use is enforced on the server: delete the token when it is used.
+- Every write gets `Idempotency-Key = sha256(approvalId:canonical call)[:48]`,
+  so a retried request cannot run twice.
+
+### Where the token lives
+
+**In-app agent.** When the model proposes a write, the server emits an
+approval card (`{actions: [{tool, summary, risk}], token}`) and stores the
+token with that model turn in conversation history, stripped from what the
+model sees. The client answers yes/no. On yes, the server uses the stored
+token (or one the client echoes) and deletes it. A client that returns only
+`{approved: true}` must work: expecting the client to send the token back made
+every approval look "expired".
+
+**MCP / ChatGPT / Claude apps.** Two calls: the first (without `confirm`)
+returns `{status: "needs_confirmation", preview, confirmation}`; the second
+repeats the call with `confirm: true` and the `confirmation` token. A client
+that may only preview (for example a bridge running on behalf of another
+product) is refused on the second call.
+
+## Audit entry
+
+One entry per write, written by the server after the call:
+
+```json
+{"scope": "account | <workspace id>", "channel": "app | mcp | chatgpt | claude | cli",
+ "actions": [{"tool": "post_schedule", "summary": "Scheduled a post for Monday 9:00",
+              "ok": true, "error": null, "actionId": "<approval id>"}]}
+```
+
+- `summary` is readable: when the model gives no title, fall back to the
+  tool's `user.label` plus the object's name — never a bare UUID.
+- Account-level writes (add a website, invite a teammate) are audited at
+  account scope, or under the object they created, not under whichever site
+  was open.
+- Failed calls are audited with `ok: false` and a short error.
+
+`maggie assistant audit-check` replays a recorded session
+(`{calls: [{tool, workspace, actionId, ok}], audit: [...]}`) against the
+registry and fails on missing, duplicate, unreadable or mis-scoped entries.

package/bundled-skills/maggie-assistant-tools/references/bridge-host.md

@@ -0,0 +1,56 @@
+# Multi-tenant assistant bridge host
+
+A bridge host runs many users' assistant sessions (an assistant CLI plus its
+MCP servers and skills) in one container on a VPS, behind a reverse proxy.
+Declare it in `maggie-bridge-host.v1`
+([example](../../../bundled-contracts/maggie-deployment/bridge-host-example-v1.json)) and check it:
+
+```bash
+maggie deployment bridge-plan --plan bridge-host.json
+maggie deployment bridge-collect-script --plan bridge-host.json > collect.sh
+ssh <host> 'sh -s' < collect.sh > observed.json
+maggie deployment bridge-check --plan bridge-host.json --observed observed.json
+```
+
+## Isolation
+
+- One OS uid per tenant from a dedicated range (for example 20000+).
+- Tenant folders `0700`, owned by the tenant uid. The tenants root (and any
+  bridge-owned parents) `0711`: tenants can traverse to their own folder but
+  cannot list others. With `0700` parents, tenant uids cannot reach their
+  folders at all.
+- Start each session with a clean, allowlisted environment (no host tokens),
+  pin it to its owner, and mark it non-dumpable after dropping privileges.
+
+## Network
+
+- Public API on a loopback port behind the proxy (`/t/<tenant>` routes).
+- Admin API on a different loopback port, never proxied.
+
+## Capacity and recycling
+
+- A session cap with LRU eviction of idle sessions, plus an idle timeout.
+- Recycle sessions when MCP servers, skills or the CLI update: idle sessions
+  restart at once, busy ones after the current reply.
+
+## Images and rollout
+
+- Label every image (`com.example.app=bridge-host`) and keep only current +
+  previous (`retain: 2`).
+- Switch with a health check (`/health`, ~30 attempts) and roll back to the
+  previous container on failure. Run with a read-only root filesystem,
+  `cap-drop ALL`, `no-new-privileges` and a pids limit.
+
+## Third-party AI accounts
+
+Record each provider's terms URL and review date. A shared account may serve
+several users only when its terms allow hosted multi-user use; otherwise each
+user brings their own account. Review terms again at least every six months.
+
+## Remote shell pitfalls
+
+- Send scripts over stdin (`ssh host 'sh -s' < script.sh`) instead of quoting
+  JSON or lists into an ssh argument; quotes are lost one layer down.
+- When an argument must be passed, escape each one with `printf %q`.
+- zsh does not word-split unquoted variables, so `for x in $list` sees one
+  item; write remote scripts for `sh` and iterate explicitly.

package/bundled-skills/maggie-assistant-tools/references/product-release.md

@@ -0,0 +1,57 @@
+# Publishing product CLIs and MCP servers
+
+Maggie's own release gates cover `@topy-ai/maggie`. Apply the same discipline
+to the CLI and MCP packages a product ships.
+
+## Package metadata — `maggie product release-check`
+
+- `bin` targets exist, start with `#!/usr/bin/env node`, and are covered by
+  `files`; a bundled single-file CLI (esbuild with a shebang banner) is the
+  simplest shape.
+- `license`, `repository` (with `directory` inside a monorepo), `engines.node`,
+  `publishConfig.access: "public"` for scoped names, and
+  `publishConfig.provenance: true` when publishing from CI with OIDC.
+- The changelog's top entry equals the package version.
+- For the official MCP registry: `package.json` `mcpName` (a namespace you can
+  prove, such as `io.github.<owner>/<name>`) equals `server.json` `name`, and
+  `server.json` `version` and its npm package `identifier`/`version` match.
+- `--pack` inspects `npm pack --dry-run`: bins are in the tarball and no
+  `.env`, `.npmrc`, private keys or service-account files are.
+
+## Installed binary — `maggie product smoke`
+
+Packs the package, installs the tarball into an empty folder, and runs each
+binary with `--version` (must print the package version) and `--help`. Run it
+before publishing; after publishing, the registry may take 30–60 seconds
+before `npx <package>@<version>` resolves.
+
+## Remote MCP endpoint — `maggie product mcp-check`
+
+Read-only checks of an OAuth-protected MCP server:
+
+- `/.well-known/oauth-protected-resource[/<path>]` returns RFC 9728 metadata
+  with `resource` on this origin, `authorization_servers`, and `header` in
+  `bearer_methods_supported`;
+- an unauthenticated `initialize` returns `401` with
+  `WWW-Authenticate: Bearer resource_metadata="…"` so clients can discover
+  the authorization server.
+
+## Third-party reviews — `maggie product review-status`
+
+Track each surface in `reviews.json` (`maggie-product-reviews.v1`):
+
+```json
+{"schemaVersion": "maggie-product-reviews.v1", "reviews": [
+  {"surface": "chatgpt-app", "status": "in-review", "version": "1.4.0", "submittedAt": "2026-10-01"},
+  {"surface": "claude-directory", "status": "changes-requested", "nextAction": "add privacy policy link"}
+]}
+```
+
+Surfaces: `chatgpt-app`, `claude-directory`, `mcp-registry`, `app-store`,
+`google-play`, `npm`. States: `draft`, `submitted`, `in-review`,
+`changes-requested`, `approved`, `rejected`, `live`. The check warns after 14
+days in review, requires a `nextAction` for changes-requested/rejected, flags
+an approved version that differs from the release, and checks a ChatGPT app's
+`review.test_cases` (at least 5 positive with `tools_triggered`, 3 negative,
+each with description, prompt and expected behaviour). Keep a demo video
+script and a review account with the submission; reviewers need both.

package/bundled-skills/maggie-deployment/SKILL.md

@@ -7,6 +7,19 @@ metadata:
 
 # Maggie Deployment
 
+## Product apps and assistant hosts
+
+- An Expo / React Native app (web, iOS, Android) uses the
+  [`maggie-mobile-app`](../maggie-mobile-app/SKILL.md) lane:
+  `maggie mobile preflight` before any EAS build (auto-submit `ascAppId`,
+  channels, fingerprint runtime policy, cost notice) and `maggie mobile plan`.
+  Its web export deploys through this skill's Cloudflare target.
+- A multi-tenant assistant bridge host on a VPS is declared and checked with
+  `maggie deployment bridge-plan`, `bridge-collect-script` and `bridge-check`;
+  see [bridge host](../maggie-assistant-tools/references/bridge-host.md).
+- Product CLI and MCP packages: `maggie product release-check|smoke|mcp-check`
+  ([product release](../maggie-assistant-tools/references/product-release.md)).
+
 ## Edge and rendered canary
 
 After staging or production deployment, verify that the edge serves the

package/bundled-skills/maggie-design/SKILL.md

@@ -315,30 +315,64 @@ sitemap semantics from `maggie-service-booking`.
 
 ## Mobile app surfaces
 
-Use the app surface contract for camera, scan, inventory, valuation, or other
-authenticated app views. It is a general host contract, not a replacement for
-the project's auth or camera implementation:
-
-    maggie design app-init --project . --route /app/valuation \
-      --auth-mode email-password --confirm
-
-The initializer records the fixed header/footer, one-scroll-owner rule,
-camera permission/ready/gallery/scan/unavailable states, decision-critical UI,
-and desktop/tablet/mobile evidence requirements. It never collects credentials
-or copies private project data. Use `existing-session` only when the host
-already supplies a safe signed-in session; use `none` for public app surfaces.
-
-After implementation, validate sanitized runtime evidence and screenshots:
+Use the app surface contract for authenticated app views (web, or an Expo /
+React Native Web route). It is a general host contract, not a replacement for
+the project's auth or device-capability implementation:
+
+    maggie design app-init --project . --route /inbox \
+      --auth-mode existing-session --capabilities none \
+      --pane list-detail:1024:2 --pattern site-switcher --confirm
+
+- `--capabilities` takes `none` or a comma list of `camera`, `location`,
+  `notifications`, `media-library`; each adds its required states. The
+  default stays `camera` for older plans; `--camera none` is a shorthand.
+  Inbox, settings, and account routes need no camera states.
+- `--pane NAME:MIN_WIDTH:OWNERS` declares an intentional multi-pane layout
+  (list + detail from 1024 px). Without one, every viewport must have exactly
+  one scroll owner.
+- `--viewport tablet=768x1024` overrides a plan viewport; the evidence and
+  screenshots must then match it.
+- `--pattern` attaches acceptance rules from
+  [app UI patterns](references/app-ui-patterns.md) to the QA scenarios.
+
+Expo Router files (`app/<route>.tsx`, `app/<route>/index.tsx`) are detected as
+the route source. The plan never collects credentials or copies private data.
+
+Collect runtime evidence with the browser instead of hand-written scripts:
+
+    maggie design app-collect --plan .maggie/design/app-view/app-<id>/plan.json \
+      --base-url http://localhost:8081 --profile-dir ~/.maggie-qa-profile \
+      --read-only --allow-write /auth/refresh --confirm
+
+`app-collect` renders each plan viewport in one tab, one at a time, at the
+real viewport size, and writes `runtime-evidence.json` plus PNGs. It counts
+scroll owners per viewport (skipping React Native Web wrappers that hold an
+owner without overflowing), proves the header and footer stay put while every
+owner scrolls, and records the tab bar position and pinned regions as
+geometry only. Use `--cdp-url http://127.0.0.1:9222` to reuse a Chrome you are
+already signed in to, or a dedicated `--profile-dir` (sign in once with
+`--headed`). Apps that rotate refresh tokens must never be rendered in two
+instances at once; see `maggie qa app-preflight`. `--read-only` fails every
+non-GET request except `--allow-write` matches, for local servers that talk to
+production APIs. Capability states (camera and others) still come from
+scenario QA and are preserved when evidence is recollected.
+
+Then validate:
 
     maggie design app-validate --project . \
-      --plan .maggie/design/app-view/app-<id>/plan.json \
-      --runtime-evidence ./qa/mobile-app-evidence.json \
-      --rendered-dir ./qa/screenshots --confirm
-
-The evidence must prove the auth state, fixed shell, exactly one scroll owner,
-all required camera states, and valid PNGs at 390px, 768px, and desktop
-widths. The machine-readable contract is
+      --plan .maggie/design/app-view/app-<id>/plan.json --confirm
+
+Validation reads per-viewport evidence only. Each viewport's recorded
+width/height must equal the plan viewport, its `scrollOwners` must be 1 unless
+a declared pane applies at that width, and each PNG's real width/height must
+equal the plan viewport times the recorded `deviceScaleFactor` (taller only
+when `fullPage: true`). A top-level `shell.scrollOwnerCount` is ignored with a
+warning, and a signature-only or scaled screenshot fails. The machine-readable
+contract is
 [mobile-app-surface-v1.schema.json](../../bundled-contracts/maggie-design/mobile-app-surface-v1.schema.json).
+Keep `maggie design pressable-check` in the same loop for React Native Web
+apps: together they caught nested pressables and shell regressions during
+repeated sheet and modal changes.
 
 ### Onboarding wizards
 

package/bundled-skills/maggie-design/references/app-ui-patterns.md

@@ -0,0 +1,66 @@
+# App UI patterns
+
+Reusable patterns for signed-in product apps (Expo / React Native Web, or a
+web SPA), alongside the onboarding-wizard and picker guidance in the
+`maggie-design` skill. Each pattern has acceptance rules; `maggie design
+app-init --pattern <id>` copies them into the route's QA scenarios so they
+are checked with the rest of the surface.
+
+Shared rules for every pattern:
+
+- One scroll owner per screen region. A modal, sheet, or tab body owns its
+  own scroll; the screen behind it does not scroll while it is open.
+- Breakpoints: phone layout below 768 px, card/dialog presentation from
+  768 px, list + detail panes from 1024 px (declare them with
+  `--pane list-detail:1024:2`).
+- Capture evidence at the real viewport (`maggie design app-collect`),
+  never in a scaled frame.
+
+## `tabbed-modal` — tabbed modal route
+
+A route presented over the current screen (Expo Router
+`presentation: "transparentModal"`, fade animation), used for multi-section
+settings such as "Your business" or "What the assistant can do".
+
+- Full screen below 768 px; from 768 px a centred card (about 720–820 px
+  wide, max 90% of the viewport height) over a dimmed backdrop.
+- Pill tabs, optionally with counts, scroll sideways. The active pill
+  scrolls into view on open and on change.
+- Each tab body is its own scroll owner and resets to the top when the tab
+  changes.
+- Close button, backdrop tap (card mode) and Escape close it and return
+  focus to the element that opened it.
+
+## `editor-sheet-assistant` — editor sheet with an in-place assistant
+
+An edit sheet (bottom sheet on phones, max ~85% height, one scroll owner,
+backdrop closes) whose "Ask the assistant" action turns the same sheet into
+a short contextual chat instead of navigating away.
+
+- Every message carries a context line (what is being edited).
+- The assistant never writes directly: a change arrives as an approval card
+  (summary, risk, Approve / No). Nothing changes until it is approved; see
+  `maggie-assistant-tools` for the approval token contract.
+- After an approval, the screen behind refreshes; dismissing the chat
+  returns to the editor with any unsaved edit intact.
+
+## `usage-hero` — plan usage hero
+
+The first block of an inbox or account screen when usage limits matter.
+
+- Plan name, used and remaining quota are visible without scrolling.
+- Meters sit in two columns from about 360 px of card width, one column
+  below. A meter turns amber at 80% and red at the limit.
+- The over-limit state names the next action. Hide purchase links where the
+  store forbids them (for example on iOS, App Store guideline 3.1.1); the
+  rule belongs in one helper, not in each screen.
+
+## `site-switcher` — searchable site or workspace switcher
+
+- Each row shows the site icon; a failed or tiny (under 32 px) favicon falls
+  back to the site's first letter. Cache icon results per domain.
+- A search field appears from 5 sites; below that it is noise.
+- The current site is marked, and every row is keyboard reachable and has an
+  accessible name.
+- Account-level actions (add a site) are visually separated from per-site
+  rows, and are audited at account scope, not under the open site.

package/bundled-skills/maggie-feedback/SKILL.md

@@ -154,9 +154,26 @@ maggie feedback session-summary --project . \
 The helper reads commit subjects only (no diffs, paths, or file contents) and
 redacts secrets and local paths. `fix:` commits become fixed `bug` items with a
 `commit:<sha>` evidence reference; `feat:`, `perf:` and `refactor:` commits
-become `improvement` candidates; other commits are skipped and counted. It also
-adds one placeholder for an open ask. It writes a draft batch file under
-`.maggie/feedback/batches/` and does not create or submit feedback.
+become `improvement` candidates. Plain-sentence subjects without a prefix are
+classified by keywords ("no longer", "prevent", "crash" → bug; "add",
+"replaces", "support", "show" → improvement); `docs:`, `chore:`, version bumps
+and unclassified subjects are skipped and counted, or kept as `general` items
+with `--all`. `--merges` includes merge commits and classifies a PR merge by
+its branch name. It also adds one placeholder for an open ask. It writes a
+draft batch file under `.maggie/feedback/batches/` and does not create or
+submit feedback.
+
+One session often spans several repositories (app, backend, edge). Repeat
+`--repo` with a label and use a date, because revisions differ per repo:
+
+```bash
+maggie feedback session-summary --project . \
+  --repo app=../app --repo api=../api --repo edge=../edge \
+  --since-date 2026-10-12 --batch-id product-session-2026-10-12
+```
+
+Evidence then reads `commit:<label>@<sha>`; unlabeled repositories become
+`repo1`, `repo2`, so local folder names never leave the machine.
 
 Review the file: delete items that concern the project rather than a Maggie
 skill or CLI, and replace every `REVIEW:` field (expected, actual, validation).

package/bundled-skills/maggie-marketplace/SKILL.md

@@ -195,6 +195,34 @@ The local export is copied as the final homepage input before completion; the
 clone run still supplies responsive screenshots, source evidence, manifests,
 and `DESIGN.md`. No interactive approval is required during the command.
 
+## Third-party skill catalogs
+
+A product that ships its own Agent Skills (tens or hundreds of them) can use
+the same validation Maggie applies to its own skills, plus Claude Code plugin
+packaging:
+
+```bash
+maggie skills scaffold --root skills --category social --name cmo-thread \
+  --description "Turn an article into a social thread; use after an article is approved."
+maggie skills validate --root skills [--catalog catalog.json] [--require-pinned]
+maggie skills package --root skills --out dist/marketplace --prefix cmo --owner "Example Ltd" --version 1.0.0
+maggie skills smoke --out dist/marketplace --claude
+```
+
+- `validate` checks front matter (`name` equals its folder, lower-case,
+  ≤ 64 characters; `description` ≤ 1024, no tags), duplicate names,
+  placeholders, relative links, optional catalog parity, and with
+  `--require-pinned` that `references` entries pin a 40-character commit.
+  Maggie's own `skills/` pass the same validator.
+- `package` writes one plugin per category (`metadata.category` or the
+  top-level folder) plus an all-in-one plugin, each with
+  `.claude-plugin/plugin.json`, and `.claude-plugin/marketplace.json`.
+- `smoke` re-checks names, versions, sources and every packaged skill, and
+  with `--claude` runs `claude plugin validate`.
+
+Nothing is published; push the output folder to the marketplace repository
+yourself after review.
+
 ## Rules
 
 1. Extract the template detail page first and save title, description,

package/bundled-skills/maggie-mobile-app/SKILL.md

@@ -0,0 +1,122 @@
+---
+name: maggie-mobile-app
+description: Ship a cross-platform product app from one Expo / React Native codebase to web, iOS and Android. Use for the dev server, web deploy, EAS build profiles, TestFlight and Play internal testing, EAS Update channels and runtime versions, store-review rules, and a release preflight with a cost notice before every build.
+metadata:
+  version: 1.0.0
+---
+
+# Maggie Mobile App
+
+## Automatic memory hook
+
+Follow [Maggie Memory Hook](../../references/memory-hook.md) at invocation and completion.
+
+For builds, submissions and OTA updates, follow the shared [Maggie decision loop](../../references/decision-loop.md): inspect, propose, checkpoint, then confirm. Every cloud build spends quota; never start one without showing the cost notice and getting a yes.
+
+This lane covers a product app the way `maggie-deployment` covers a website:
+one Expo codebase serving web, iOS and Android. It does not own the app's
+auth, payments, or data; the host app does.
+
+## 1. Dev server and browser QA
+
+- Start Metro from the app folder (`apps/app` in a monorepo), never from the
+  repository root, and never with `CI=1`: CI mode disables file watching, so
+  the browser keeps the old bundle and a working change looks broken.
+- Before browser QA, run `maggie qa app-preflight --project . --app-dir apps/app`.
+  It catches both mistakes and warns about rotating refresh tokens and
+  production-backed local servers (see `maggie-qa-workflow`).
+- Design and validate signed-in routes with `maggie design app-init`,
+  `app-collect` and `app-validate` (see `maggie-design`, including the
+  [app UI patterns](../maggie-design/references/app-ui-patterns.md)).
+
+## 2. Web deploy
+
+`npx expo export --platform web` writes a static single-page app to `dist/`.
+Serve it with a single-page-app fallback (Cloudflare Workers static assets:
+`"not_found_handling": "single-page-application"`), security headers in
+`public/_headers`, and a custom domain. Use `maggie-deployment` for the
+Cloudflare target, canaries and rollback.
+
+## 3. Release preflight (before any build)
+
+```bash
+maggie mobile preflight --project . --app-dir apps/app \
+  --profile production --platform ios --auto-submit
+```
+
+It reads `app.json` (or `npx expo config --json --type public` output passed
+with `--config-json` when the config is dynamic), `eas.json` and
+`package.json`, and fails before quota is spent when:
+
+- `--auto-submit --non-interactive` would fail at submission: iOS needs
+  `submit.<profile>.ios.ascAppId` (the numeric App Store Connect app ID),
+  Android needs a service-account key path (kept out of git);
+- EAS Update is installed but the profile has no `channel`, the update URL is
+  missing, or there is no `runtimeVersion`;
+- `runtimeVersion` uses `appVersion`/`nativeVersion` while
+  `cli.appVersionSource` is `remote` and `expo.version` never changes: every
+  future binary would accept any JS update, including one that needs a new
+  native module. Use one top-level `{"policy": "fingerprint"}`.
+
+It warns about missing export-compliance (`usesNonExemptEncryption`), an
+unpinned `cli.version`, per-platform-only runtime versions (what
+`eas update:configure` writes) and tab-indented `app.json` that
+`update:configure` would reformat. Prefer editing these fields by hand.
+
+Recommended `eas.json` shape:
+
+```json
+{
+  "cli": {"version": ">= 16.0.0", "appVersionSource": "remote"},
+  "build": {
+    "preview": {"distribution": "internal", "channel": "preview"},
+    "production": {"autoIncrement": true, "channel": "production"}
+  },
+  "submit": {"production": {"ios": {"ascAppId": "<numeric id>"}, "android": {"track": "internal"}}}
+}
+```
+
+## 4. Build, submit, update
+
+```bash
+maggie mobile plan --project . --app-dir apps/app --platform ios --auto-submit
+```
+
+prints the exact commands with the cost notice and runs nothing:
+
+1. `npx eas-cli build -p ios --profile production --non-interactive --auto-submit`
+   → TestFlight (iOS) or the Play internal track (Android). Add testers in
+   App Store Connect / Play Console; internal testing needs no review.
+2. Without `--auto-submit`: `npx eas-cli submit -p ios --profile production --latest`.
+3. JS-only fixes: `npx eas-cli update --channel production --platform ios --message "…"`.
+   A native change (new module, permission, SDK upgrade) needs a new build;
+   the fingerprint policy stops an incompatible update from reaching old
+   binaries.
+
+Show the plan's `costNotice` and wait for confirmation before step 1.
+
+## 5. Store-review rules
+
+- iOS (App Store guideline 3.1.1): no links or buttons to buy digital goods
+  outside in-app purchase. Keep the rule in one helper (for example
+  `canLinkToPurchase = Platform.OS !== "ios"`) and apply it to assistant
+  tools that return purchase links, not only to screens.
+- Provide a working review account and notes; reviewers sign in.
+- Declare export compliance, data collection (privacy labels / Data safety)
+  and every permission's purpose string.
+- Account deletion must be reachable in the app when sign-up is.
+
+## 6. Readiness report
+
+Before a store submission, record: preflight passed, app-validate passed for
+each signed-in route, QA run summary (`maggie qa summary`), the build and
+update commands that ran, and the review status
+(`maggie product review-status`, surfaces `app-store` and `google-play`).
+
+## Hard boundaries
+
+- Never run `eas build`, `eas submit` or `eas update` without an explicit yes
+  after the cost notice.
+- Never commit App Store Connect API keys, Play service-account JSON, or
+  keystores; reference them by path or environment variable name.
+- Do not change bundle identifiers or package names of a published app.