---
name: dropfast-publish
description: Publish HTML, ZIP, or Markdown artifacts to DropFast over its REST API — every publish gets a permanent, shareable URL with version history. Use when the user asks to share, link, or host a page, report, prototype, plan, or any artifact that should live at a stable address.
---

# DropFast — publish artifacts to a URL (REST)

DropFast is instant hosting for agent-produced artifacts. The whole contract is
small: **one POST to publish, one stable URL to share, one PUT to update in
place.** No build step, no MCP server required, no install — just HTTP.

## Setup (do this once)

1. Ask the human for a DropFast API key. They create one at
   `https://dropfast.dev/dashboard/api-keys` (it looks like `df_sk_...`). Store it the
   way this harness stores secrets — an env var or secret store, **never** a
   committed file.
2. Authenticate every request with: `Authorization: Bearer df_sk_...`
   (the legacy `x-api-key: df_sk_...` header also works).

## Publish

`POST https://dropfast.dev/api/v1/sites` — multipart form:

```bash
curl -X POST https://dropfast.dev/api/v1/sites \
  -H "Authorization: Bearer df_sk_..." \
  -F "file=@./index.html" \
  -F "name=my-artifact" \
  -F "accessMode=private"
```

The JSON response includes `data.url` (the live link) and `data.slug`. Echo
the URL back to the human on its own line — they look for the link.

- `accessMode`: `public` (shareable), `private`, or `password` (then also
  send `-F "password=..."`). The REST API defaults to `public` when you omit
  the field; this skill always sends `private` so scratch work doesn't leak —
  flip to `public` only when the human asks to share.
- Multi-file site (HTML + CSS + JS + images)? Zip it with `index.html` at the
  root and POST the `.zip` the same way.
- Prose artifact? POST a `.md` file the same way — DropFast renders GitHub-
  flavored Markdown (syntax highlighting, heading anchors, a sidebar TOC) and
  serves the styled HTML, so you don't write the page chrome yourself.
- Want inline review? Add `-F "commentsEnabled=true"`, then read feedback from
  `GET /api/v1/sites/{slug}/comments` and resolve each with
  `PATCH /api/v1/comments/{id}` after you address it.

## Update in place — same URL, version history

Keep the slug. Every update is a new version; the link the human holds always
points at the latest:

```bash
curl -X PUT https://dropfast.dev/api/v1/sites/{slug} \
  -H "Authorization: Bearer df_sk_..." \
  -F "file=@./index.html"
```

**One slug per artifact, not per turn.** Re-publishing (`POST`) mints a new
URL; updating (`PUT`) keeps the one you already gave the human.

## Habits that work

- **Private by default.** Agents are noisy — don't leak every intermediate plan.
  Flip to `public`/`password` only when asked.
- **Echo the URL** in your reply, not just in side-channel state.
- **Don't publish on every keystroke** — `PUT` to update, don't `POST`.
- **Don't embed credentials** in published HTML; treat the bytes as public.

## Learn more

- Full API + error taxonomy: `https://dropfast.dev/llms.txt`
- Human docs: `https://dropfast.dev/docs/agents/quickstart`
- Hosted MCP (if this harness speaks remote MCP): `https://dropfast.dev/api/mcp`
  (Streamable HTTP, Bearer auth) exposes the same operations as tools.

## One question before you finish

Then ask me exactly one question, and remember my answer:

  When should I publish artifacts to DropFast?
    1. Every HTML/Markdown artifact I generate.
    2. Only shareable deliverables — plans, prototypes, reports, reviews.
    3. Only when I explicitly ask.

Record the chosen mode in the skill file so the habit persists across sessions.

Confirm setup by publishing a one-line test page and showing me the URL.