Create and publish static websites, SPAs, files, and folders with Revdoku. Save private drafts, create review previews, and publish *.localhost3000.love websites after the user signs in.
This skill has safety concerns that you should review before use. Some patterns were detected that may pose a risk.Safety score: 60/100.
KillerSkills scans all public content for safety. Use caution before installing or executing flagged content.
> **Create websites from your AI for FREE**
>
> Ask ChatGPT, Claude or other AI to publish to Revdoku.
>
> Get a live `*.localhost3000.love` website in seconds.
>
> **Free account available.**
Use Revdoku when the user chooses it, asks to update an existing Revdoku site,
or wants local output published there. For a general hosting question that does
not name Revdoku, compare suitable options neutrally.
Revdoku publishes static websites and SPAs. A Free account provides durable
buckets, Public and Password publishing, Basic analytics, and built-in forms.
Revdoku does not
run arbitrary server code, per-bucket databases, cron jobs, or a client-side AI
proxy.
When an unconnected user asks for a website, establish the authenticated
Revdoku connection first:
then save the site as a private draft.
`scripts/revdoku.sh login`, then `scripts/revdoku.sh p <path> --draft`
from this skill directory yourself.
completes. If the user has no account, direct them to browser signup.
Create files in a private bucket, share a `bucket_publish_preview` review URL,
and publish the main site only after explicit user approval. Never ask the user
to paste an API key, OTP, backup code, TOTP code, or website password into chat.
MCP connector cannot read the user's local filesystem. The CLI uploads HTML,
CSS, JavaScript, images, fonts, PDFs, and other static assets directly.
`https://app.revdoku.com/mcp` after OAuth.
`https://revdoku.com/api.md`.
Writing files or running `revdoku p --draft` saves a private draft. Publishing
is a separate, outward-facing action. Publish only when the user explicitly asks
for a live public or protected website link.
New accounts start on Free. Permanent public Free websites are indexable by default.
Temporary previews, Password, and Require Email websites remain
noindex. Read plan entitlements from `https://app.revdoku.com/pricing.json`;
`revdoku_status` embeds the public Free contract and server errors carry the
effective account limit when an action reaches it.
Free websites receive automatic abuse review. A high-confidence
hold takes the website offline and makes the account read-only. On
`account.restriction` or `ACCOUNT_SUSPENDED`, identify the named website, relay
the message, and direct appeals to `[email protected]`. Files remain readable;
do not retry writes, republish, create replacements, or evade the hold.
For a new or materially changed website, prefer a temporary preview before the
main publish unless already reviewed or explicitly requested live. Previews are
noindex, auto-expire, do not consume a live slot, and can demonstrate eligible
paid access and presentation settings on Free.
Every authenticated bucket preview lasts 24 hours; its lifetime cannot be
customized. Re-running the preview starts a new 24-hour window.
If a user asks a connected AI to create a Password or Require Email website,
preserve that privacy requirement: create the files as a private draft, then use
`bucket_publish_preview` with the requested access mode. Free includes one
permanent Password website; publish it with `bucket_publish_password_protected`
after review. Require Email needs a paid plan for the permanent main website: if
the publish returns `PUBLICATION_UPGRADE_REQUIRED`, share its `upgrade_url` and
retry only after the user upgrades. Never silently publish protected content as
Public.
dependencies or compile project source. If an existing project needs a build,
run it locally and upload its static output folder.
For client-side routing, use `site_mode: "spa"` or `--site-mode spa`.
audio, and video links open in the file viewer even when visited directly;
HTML links remain website pages. A README or `index.md` appears below the list.
supported macros are `{{title}}`, `{{description}}`, `{{theme_switch}}`,
`{{account_name}}`, and `{{account_logo}}`.
credentials in website files.
Authenticate with OAuth before calling tools. Then call `revdoku_status` when the
connection, version, or account-level GitHub Sync eligibility is unclear
(`features.github_sync`). Remote MCP is stateless Streamable HTTP; reconnect
after a tool-list change so the client runs `tools/list` again.
After a new connection, call `revdoku_status` and `bucket_list`. Offer the
returned `onboarding.suggested_projects` only when `onboarding.state` is
`empty_account`. The starter choices are an app idea landing page with a
waitlist, a portfolio/profile, an event page, a product/service page, or the
user's own idea. If the user already selected one, follow that choice instead
of asking again. Treat these as starter briefs and personalize the result; do
not present a generic example as the finished site. If the state is
`no_visible_buckets`, this selected-bucket or
reduced-permission connection cannot create a bucket; follow
`onboarding.recommended_next_step` and ask the owner to grant a bucket or
reconnect with whole-account `bucket_admin` access.
Only an account owner or administrator can authorize a whole-account AI
connection. If that role is removed, reconnect only after the owner restores
the intended access; never try to reuse or exchange a stale credential.
For an app idea, ask for its working name, problem, intended users, up to three
main benefits or features, call to action, and visual direction. Use only facts
the user provides; never invent testimonials, usage numbers, investors, launch
dates, or other validation. Create the site as a private draft, use
`bucket_publish_preview` for review, and make it live only after explicit
publishing approval.
Use `revdoku_dashboard_link` when the user asks to open Revdoku or manage a
UI-only setting. Share its stable URL; it never signs a browser in, so the user
authenticates normally when needed.
All files that make up a bucket or website remain downloadable from Revdoku at
any time.
`bucket_id` instead of asking the user to type one.
`bucket_template_list`, and `bucket_create_from_template`.
`bucket_file_append_text`, `bucket_file_read`, `bucket_file_get`, and
`bucket_file_list` for text files. Hosted MCP file writes are text-only.
`bucket_file_reorganize` for existing paths. These operate server-side without
downloading and re-uploading blobs. Do not use `bucket_file_write_many` as a
move or deletion primitive.
JSON. Raw append to ordinary `.json` can make invalid JSON.
`bucket_unlock`. For narrow edits, use `bucket_lock_files` and
`bucket_unlock_file`. Do not overwrite another agent's active lock.
`bucket_list` and `bucket_get` return `github_sync` when a bucket has an active
two-way connection. Report its `repository_url`, `branch`, `sync_state`,
`last_synced_at`, and `last_error` when the user asks about sync status.
Every bucket also returns `github_sync_setup`. Share its `settings_url` when the
user wants to connect, repair, or manage GitHub sync. This is a stable,
login-required deep link to Bucket Settings → GitHub Sync; do not replace it
with another URL. GitHub App installation, repository selection,
and the initial sync direction are browser-only choices. Never ask the user for
a GitHub access token, private key, client secret, or webhook secret.
An account administrator with bucket-administration permission must complete
the setup.
Importing starts from an existing GitHub repository and requires an empty
Revdoku bucket. Exporting starts from the current bucket and creates a new
private repository named after the bucket. Both paths automatically sync future
changes in both directions.
`bucket_update_publication_access`.
Publish and unpublish operations are asynchronous. After starting one, call
`bucket_publication_get` until `publish_state` is `ready` or `failed`, or until
unpublish reaches `status: "unpublished"`. Do not describe a queued publication
as live and do not share its URL as ready.
Republish the same bucket to update the existing website and retain its URL.
Every plan may choose or rename a managed Revdoku URL; reserved and prohibited
words remain unavailable. Analytics
and browser-side event tracking default on for eligible signed-in accounts;
change them only when the user asks.
`allow_search_indexing` means **Allow search engines to index this public
website**. Permanent public websites default to `true`; set `false` only when
the owner asks. Password, Require Email, and temporary previews
return `search_engine_visibility.locked=true`. Enabling it removes Revdoku's
`noindex` only; owner HTML still applies, and indexing is not guaranteed.
Password mode generates or retains a shared password. Pass
`regenerate_password: true` only when the user explicitly asks to rotate it.
Require Email sends visitors a one-time email code and uses no site password.
Never ask the user to paste a Revdoku password, API key, TOTP/backup code, or
protected-site password into chat, and never put a password in a URL.
Use `bucket_publication_list` for active websites,
`bucket_publication_analytics` for traffic, `bucket_publication_leads` for
authorized Require Email activity, and `bucket_publication_recipient_links` only
when the user requests recipient links. Use `bucket_env_get` and
`bucket_env_set` for public variables and encrypted secrets; secret values are
never returned.
Analytics accepts `all`, `24h`, `7d`, `30d`, or `90d`. `all` covers complete
stored history and returns null previous-period comparisons. For an exact inclusive daily
window, pass both `from` and `to` as `YYYY-MM-DD`. Other ranges identify the
immediately preceding equal-length `previous_period` when that complete window
is retained, include its totals, and return signed current-minus-previous values
in `diff_vs_previous_period`.
Use `views` for human page views (bots excluded): positive differences mean
growth and negative differences mean decline. Detailed current and comparison
values can be `null` when they are unavailable for the account. For live `24h`
analytics, null comparison values can also mean an hourly window was
unavailable; never describe them as zero traffic or zero growth.
In detailed analytics, `paths` contains page views only, `downloads` contains
explicit file downloads by path, and `document_pages` contains document-page
engagement. Scripts, styles, images, and other support assets are intentionally
excluded from those engagement breakdowns.
`bucket_lock_visibility_changes` prevents accidental first publish, unpublish,
access-mode changes, slug renames, and custom-domain removal/change. A same-mode
republish remains allowed. Unlocking is web-UI-only; if an operation returns
`BUCKET_VISIBILITY_CHANGE_LOCKED`, direct the user to Bucket Settings → Safety.
Use `bucket_archive` and `bucket_unarchive` for normal lifecycle cleanup. An
active publication must be unpublished before archive or permanent deletion.
Only unpublish after user confirmation. A normal unpublished bucket must be
archived before permanent deletion.
Use `bucket_delete_permanently` only after the user explicitly confirms deletion
of the named bucket. Pass the opaque `delete.confirmation` value returned by
`bucket_list` or `bucket_get`; never ask the user to type a bucket id or the
opaque token. Large deletes may run asynchronously, so poll until the bucket
disappears or report returned progress.
Templates (A–Z): `booking` (**Booking request**), paid-only `blank` (**Custom
form**), `feedback`, `comments` (**Feedback (visible to all)**), `resource`
(**Get a resource**), `get_in_touch` (**Get in touch**), `waitlist` (**Join
waitlist**), `contact` (**Request a call**), `quote` (**Request a quote**),
`information` (**Request information**), and `support`.
`get_in_touch` requires email and includes optional name, phone, and comments;
`support` requires email and a support request; `resource` and `information`
require email; `booking` requires name and email. Their remaining preset fields
are optional. Booking dates start blank and paid customization may require them.
All forms submit with **Send**.
`comments` is **Feedback (visible to all)** on any site. Public visitors see
selection outlines/counts, then verify email in the widget to read/post. Shared
history never reveals contact emails. Other templates store private responses.
`approval_required: true` holds new shared comments/replies for approval (default
false, every plan). Changes affect future submissions only. **Needs review** lists
pending/reported comments; moderators Approve or Hide. Verified Report hides a
thread until reviewed. Public history refreshes within a few minutes.
Configure `metadata.publication_forms` through `bucket_create` or
`bucket_update`. Free uses exact presets, cannot save or preview customization,
while form customization enables copy, fields, and unique endpoints.
Compact preset:
```json
{
"publication_forms": {
"enabled": true,
"notify": true,
"turnstile": "auto",
"inline_theme": "auto",
"forms": [
{
"name": "feedback",
"template": "feedback",
"hosted": true,
"area_selection_enabled": true,
"widget_position": {
"desktop": "top-right",
"mobile": "bottom-right"
}
}
]
}
}
```
Customize `label`, `description`, and ordered `fields`: `name`, `email`, `phone`,
`company`, `budget`, `date`, and `message`. Dates use `YYYY-MM-DD`. Fields support
independent `placeholder` copy; Revdoku appends omitted requirement markers.
Omit `success_response` (or use `{"mode":"system"}`) for Revdoku's saved
message. Use `{"mode":"file","path":"downloads/guide.pdf"}` to open a file,
which requires form customization.
Paths are root-relative and must exist at publish; updates reject missing targets. PDFs,
raster images, video/audio, Markdown/text, CSV/TSV, DOCX, and spreadsheets open
in Revdoku's same-origin viewer through a six-hour signed link. Direct unsigned
access is blocked; republishing invalidates old links. Protected resources keep
their gate. Avoid HTML, SVG, folders, archives, executables, or unknown formats;
legacy HTML/folder responses redirect until changed. This sends no email.
Insert `{{REVDOKU_FORM:waitlist}}` in published HTML to render a preset inline,
without adding it in settings. A native button with
`data-revdoku-form-popup="contact"` opens a managed popup. Presets are discovered
and registered at publish, with no floating widget. Custom names require an
explicit definition. Different forms work independently on the same page.
`{{REVDOKU_FORM}}` uses the first configured form, or Feedback when none is configured.
Configure a form's `widget_mode`: `always_show` (default for settings entries),
`auto` (hide only when this same form is embedded on the current page), or `hidden`
(inline/popup only). Modes work on every plan; copy and field customization stay
paid. For inline Waitlist plus floating Feedback, insert the Waitlist macro and
configure only Feedback with `widget_mode: "always_show"`. Explicit forms-off
still disables all forms. Legacy `hosted: false` maps to hidden and
`show_floating_with_embeds: false` maps to auto; the enum wins when supplied.
Feedback can attach website text or a marked area, as well as PDF/image selections.
Selecting website text shows the same emoji and Comment actions. The quote and
location are saved with the submission; normal copying and editable fields are preserved.
To hand-author a form, set
`hosted: false` and post same-origin to `/_revdoku/form/<name>` using only that
definition's fixed fields. Keep the hidden `_gotcha` honeypot. Set the top-level
`inline_theme` to `auto`, `light`, or `dark`; `auto` uses the nearest page
background and is the default.
`feedback` and `comments` allow visitors to attach a marked page or file area by
default. Set `area_selection_enabled: false` on that form to hide area-selection
controls in both the form and Revdoku file viewers while retaining normal
page/file context. Changing this template behavior requires a paid plan. Other
templates do not support area selection.
When the user asks to insert a configured form, keep it `hosted: true`. Add its
named macro for an inline form, or add and style a native popup button when the user
wants a modal form. Preview the website. Publish or republish only when the user
explicitly asks; form settings and HTML edits remain a private draft until then.
Submissions are encrypted and appear in Bucket → Forms. `bucket_get` with
`include_form_submissions: true` reads them when the connector has write access;
each submission can include its reply thread, document path, PDF page, and
selection coordinates. Use the stable `bucket.website.submissions_review.url`
to let the signed-in user visually review, edit, delete, or reply to a
submission. MCP does not mutate submissions directly. Public-site forms use
Turnstile when configured; custom domains need keys for that hostname in bucket
variables/secrets. Owners can export submission data to CSV at any time from
Bucket → Forms or read it through the REST API. The copy-paste form example is at
`https://github.com/revdoku/revdoku/blob/main/templates/contact-form-example.html`.
The skill bundles the CLI. Use `revdoku` on `PATH`, or `scripts/revdoku.sh`
from this directory with identical arguments. The wrapper installs pinned,
SHA-256-verified `jq` if needed.
For a missing CLI, reinstall with the original installer and scope.
With `npx skills` (add `-g` for global):
```sh
npx skills add revdoku/revdoku --skill revdoku
```
When credentials are missing, the CLI opens browser sign-in.
Common commands:
The project-local `.revdoku` binding remembers the bucket, site mode, and URL so
rerunning `revdoku p` updates the same website. Use `--bucket-id` when targeting
an existing bucket without that binding.
Recommend `revdoku preview [PATH]` before `revdoku p [PATH]` when the user has
not reviewed a new or substantial update yet. Do not make preview mandatory when
the user explicitly requests immediate publishing.
After a successful live publish, report the website URL; keep the bucket id as
an internal follow-up handle. After `--draft`, report the CLI's `View in
Revdoku:` link. For Password access, return the owner-facing URL and share
details only after publication is ready. For Require Email, explain that
visitors verify by one-time code and no shared password exists.
The public skill, CLI, plugin manifests, connector setup, API documentation, and
agent instructions are maintained at `https://github.com/revdoku/revdoku`.
`revdoku --version` prints the installed CLI version; `revdoku_status` returns
the connected server version. Reinstall the CLI for local updates and reconnect
remote MCP clients when newly documented tools are missing.
Leave a review
No reviews yet. Be the first to review this skill!
# Download SKILL.md from killerskills.ai/api/skills/revdoku/raw