MiniUp

View saved version →

---
name: miniup-app-lifecycle
description: Build, publish, update, or extend a MiniUp web app from generated files, uploaded project files, uploaded data, or an existing MiniUp site, including hosted data, Table APIs, and server-side Functions when needed.
---

Apply this workflow only to a user-requested MiniUp publish, update, or resource-management task. General questions, file analysis, calculations, and code-only requests do not authorize hosting. Clarify ambiguous publishing intent before writes.


# MiniUp app lifecycle

Use this skill only when the user asks to build, publish, update, or extend an app with MiniUp. Do not activate it for general coding, spreadsheet analysis without publishing intent, email or messaging, weather or search, GitHub operations, or unrelated hosting questions.

## Choose the workflow

- For generated HTML or project files, prefer complete-file staging followed by the normal publish workflow. Use a project for modular or multi-file apps. Do not base64-encode or chunk files when direct file handling fits.
- For an uploaded project, ZIP, or assets, use MiniUp's direct uploaded-file or project path and preserve its directory structure.
- For uploaded tabular or geospatial data plus an app request, prefer `create_app_from_uploaded_data_file`. Let MiniUp host and query large data instead of embedding it in HTML. Publish ArcGIS-compatible access only when relevant or requested.
- For an existing MiniUp app, resolve the Site and inspect its current details and content first. Update that same Site and preserve its URL unless the user requests a new app.
- Use Tables and Table APIs when the user explicitly requests a table API (including public read-only inventory with seed records), editable records, CRUD, or database-like behavior. For public read-only tables, set `apiScopes=["GET"]`, `requireReadKey=false`, and pass the requested rows in `seedRecords`. Use `site.siteId` from the new publish result. A hosted dataset is preferable for read-only uploaded data without an explicit table API request.
- Use Functions for backend logic, API endpoints, server-side computation, integrations, or authenticated Site Function behavior. Normally call `create_function`, then `test_function`, then `publish_function`. Read the new ID from `result.function.id`; verify `result.status` and `result.body` from the preview against the requested behavior before publishing. A completed tool call alone is not a successful preview. Publication returns `result.endpoint` and `result.docsUrl`. Link the Site or change access only according to user intent, and never publish after a failed preview.

## Reproducible creation and attachments

- Staged file references are temporary and consumed by publication. For an independent new publish, stage fresh files. For a timeout retry, reuse the original requestId. If MiniUp returns `staged_file_unavailable`, restage the original complete files; do not fabricate a reference.
- Each new app gets a new `requestId`; retry the same operation with the same ID. Omit site slugs unless requested. Each new Function needs a fresh unique slug; do not reuse `hello-world` across independent requests.
- Download reviewer fixtures and attach them to the conversation as files. A public fixture link is not a ChatGPT attachment download URL. Pass the real host-provided `download_url` and `file_id`; never invent attachment references. If a file was not handed off, request the attachment rather than claiming publication.
- For a requested ArcGIS map, pass `appKind="map"`, `publishArcgis=true`, and `enableArcgis=true`. Return the exact map and ArcGIS URLs from the result.

## Current app capabilities

Reuse compatible existing Tables, datasets, and Functions before creating more resources. Published eligible Tables and hosted datasets automatically reconcile app Agent Actions; current app discovery is available at `/.well-known/miniup.json` and `/openapi.json` on the published app. App-specific MCP and browse

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.