deed.page publish

deed.page publish is a skill for putting static files on a public deed.page address. It covers HTML, CSS, JavaScript, and images, with a single curl request as the basic publishing operation. A user can share a generated report, dashboard, slide deck, landing page, prototype, game, or documentation folder without creating an account or completing an email verification step.

The workflow starts by choosing a slug for the public address. Slugs use lowercase letters, digits, and hyphens, contain 1 to 63 characters, and cannot begin or end with a hyphen. A random suffix reduces name collisions. Several generic names, including hello and my-page, are reserved.

Use this skill when the user explicitly wants static output hosted online, requests deed.page, or needs a shareable link without choosing another hosting provider. It also fits unattended publishing where a person cannot complete an interactive login.

Free sites are public, so the workflow requires checking the intended file or folder before the first upload. Hidden files can contain sensitive material; they do not provide privacy. Publish built output rather than a source folder containing credentials or personal information. Applications that need server-side rendering, API routes, or a database at runtime need a different host because this service serves static files.

The input is either a single HTML file or a directory of static site contents. A single HTML upload becomes index.html. A directory should place index.html at its root; archiving the directory contents rather than the enclosing folder also keeps CSS and other relative paths in the expected locations. A folder upload uses:

tar -C ./site -czf "$UPLOAD_DIR/site.tar.gz" . &&
curl -sS -T "$UPLOAD_DIR/site.tar.gz" "https://deed.page/v1/sites?slug=$SLUG&ref=$REF" \
  -H "X-Client: <agent name>" \
  --config "$UPLOAD_DIR/headers.conf"

A successful first publish returns the public URL, slug, version, and a token. The token is the credential for updates and deletion, so response capture must keep it out of shared logs. The skill uses private response files and a protected curl configuration for optional authorization headers. Retain the token through an approved secret mechanism and return the public URL to the user.

Updating requires the same slug and token; otherwise an upload can create a different site. The Free plan retains the last ten versions. Its documented limits are 25 sites, 25 MB per site, 60 publishes per hour, and 4 MB per single request, with a separate manifest flow for larger sites. Provider limits, privacy, and retention require verification before use.

The procedure uses curl for uploads and tar for folder packaging. It includes handling for invalid or occupied slugs, version conflicts, rejected content, and rate limits. Rejected content should not be retried, while a rate-limit response supplies a retry delay. Deletion is reserved for an explicit request for the exact slug. A lost token cannot be recovered unless an optional recovery email was attached.