Run any Skill in Manus with one click

deploy

Stars28

Forks2

UpdatedJune 4, 2026 at 02:08

Deploy / publish a single HTML file (deck, page, doc) to FluidDocs hosting using the self-contained scripts/deploy.sh. Handles browser sign-in / re-auth automatically, then opens the live URL in the browser. Trigger on "deploy", "publish", "ship it", "push it live", "put it online", "host this", or any request to make an HTML file publicly viewable.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

FluidForm-ai

FluidForm-ai/fluiddocs-deck-builder

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Web DevelopersComputer and Mathematical Occupations·SOC 15-1254

SKILL.md

readonly

name	deploy
description	Deploy / publish a single HTML file (deck, page, doc) to FluidDocs hosting using the self-contained scripts/deploy.sh. Handles browser sign-in / re-auth automatically, then opens the live URL in the browser. Trigger on "deploy", "publish", "ship it", "push it live", "put it online", "host this", or any request to make an HTML file publicly viewable.

Deploy

Publish a single HTML file to FluidDocs hosting. scripts/deploy.sh is self-contained. It handles auth, upload, and project-mapping on its own. Your job is to run it correctly and open the result. Do not re-implement, inspect, or second-guess the script. Just run it.

What the script does (so you don't have to analyze it)

Finds HTML files in the current directory only (find . -maxdepth 1). So you must run it from the folder that contains the target file.
If exactly one HTML file is present, it auto-selects it. If several, it prompts for a number.
Caches an auth token at ~/.config/fluiddocs/auth.json. If the token is missing or expired, it prints a sign-in URL, opens the browser, and polls for up to 5 minutes while the user authorizes.
Uploads the file and prints ✓ Deployed → <URL> on success.
Records the file→project mapping in ./.fluid-docs.json, so re-deploying the same file updates the existing project instead of creating a duplicate. Keep this file; don't delete it.
Flags you use: --name "Friendly Title" (project name), --host URL (alternate server), --logout (clear cached creds for a fresh sign-in). The script also has --public and --slug, but do not use them: visibility and publishing are the user's choice, made in the FluidDocs app, never set from the CLI by you.

Procedure

Pick the target file. If the user names one, use it. Otherwise use the obvious HTML file in context (e.g. the deck you just built). If genuinely ambiguous, ask which file, one short question, then proceed.
Always pass --name "Friendly Title". Without it the project name defaults to the raw filename slug, which is hard to scan in the dashboard. Derive a clean human title (e.g. "Mushee · Seed Pitch").
Run the script from the file's directory. The script lives at ${CLAUDE_PLUGIN_ROOT}/scripts/deploy.sh (plugin install), ~/.claude/skills/deploy/scripts/deploy.sh (manual install), or scripts/deploy.sh at the repo root. From the directory containing the HTML:
```
bash "${CLAUDE_PLUGIN_ROOT}/scripts/deploy.sh" --name "Friendly Title"
```
Run it with network access enabled and a generous timeout (up to 600000 ms). The auth poll can take a few minutes while the user signs in. The script opens the user's browser itself when auth is needed; tell the user to complete the sign-in there.
If the run can't do interactive sign-in (sandboxed shell with no network, or the browser can't be driven), hand the command to the user to run in-session with the ! prefix instead, so auth happens in their own browser:
```
! cd <deck-dir> && bash "<path>/scripts/deploy.sh" --name "Friendly Title"
```
On success, open the live URL in the browser. The script prints but does not open the deployed URL. You do. Capture the URL after ✓ Deployed → and open it:
```
open "<deployed-url>"        # macOS
# xdg-open "<deployed-url>"  # Linux
```
Hand the link back as a private preview only (a plain deploy is private; see Hard rules). Tell the user that to share it, they open it in the FluidDocs app and use Publish / Share or Document Properties to set it to private, unlisted, or public. Do not run --public or --slug yourself; visibility is set by the user in the app.

Re-auth

If the user wants to switch accounts or the token is broken, run bash "${CLAUDE_PLUGIN_ROOT}/scripts/deploy.sh" --logout first, then deploy again to trigger a fresh sign-in.

Hard rules

Never deploy without --name.
Run from the file's own directory (the script is directory-scoped).
Preserve ./.fluid-docs.json. It's what keeps re-deploys updating the same project.
A plain deploy is private: the returned link is an owner-only preview that only the signed-in owner can open. Do not call it shareable, and do not offer to make it public. Visibility (private, unlisted, public) and publishing are ALWAYS the user's choice, set by them in the FluidDocs app via Publish / Share or Document Properties. Never run --public or --slug, and never offer to, you do not change visibility. For visibility wording and what FluidDocs offers, see deck-builder/references/about-fluiddocs.md.
The user asking to "deploy/publish" is the authorization; don't deploy a file they didn't ask for.

Maintained by FluidDocs. Source: https://github.com/FluidForm-ai/fluiddocs-deck-builder. MIT licensed.

More from this repository

same repository

deck-builder

FluidForm-ai/fluiddocs-deck-builder

Build chrome-free, single-file HTML decks on a fixed 1440x810 canvas (scale-to-fit, PDF-like, non-responsive) for any deck type. Pitch, sales, launch, keynote, all-hands. Core infrastructure (shell, canvas scaling, reviewer specs, brief template, brand-tokens methodology, icon library, learnings log) is type-agnostic. Each deck type is delivered through a thin type pack (deck-pitch, deck-sales, deck-launch, deck-keynote, deck-all-hands) that declares only what's type-specific (content spine, visual components, demo patterns if relevant). Trigger on "deck builder", "build a deck", "deck template", or when a specific type pack isn't installed but the request clearly calls for a deck. Process: five-phase Plan, Build, Review, Release, Learn with gates. Three category-owning reviewers (Brand, Copy, Layout) sign off before release. Source of truth for the pipeline every type pack inherits.

2026-06-0428

deck-import

FluidForm-ai/fluiddocs-deck-builder

Convert any PDF or PPTX deck into a self-contained interactive HTML deck, one file, one link, shareable. Auto-detects input file extension (.pdf or .pptx) and routes to the matching extraction path. Detects which of the 5 deck types the source is (pitch, sales, launch, keynote, all-hands) and hands off to the matching deck-* skill. Trigger when the user uploads a .pdf or .pptx of any deck type, or says any variation of "convert this PDF to HTML", "turn this PPTX deck into HTML", "import this deck", "upgrade my deck", "make my deck interactive", "migrate my deck from PDF/PPTX". Mirrors source palette, typography, and slide structure 1-to-1 (no redesign), preserves slide count, uses extracted screenshots on demo slides where applicable, auto-extracts key fields, then confirms with the user before building. Reuses deck-builder core pipeline and per-type spines as role-labeling taxonomy. Fastest path from cold PDF or PPTX to warm shareable link.

2026-06-0328

deck-all-hands

FluidForm-ai/fluiddocs-deck-builder

Builds 15-slide all-hands decks for company-wide team meetings with balance of wins and candor. Trigger phrases: all-hands deck, town hall deck, monthly all-hands, company-wide meeting, team meeting deck, all-hands presentation. Type-specific: celebration and candor balance (only-wins hides problems), company-appropriate financials (not board-level detail), Q&A placeholder (live meeting owns Q&A not slides). Inherits 5-phase pipeline from deck-builder core.

2026-06-0328

deck-keynote

FluidForm-ai/fluiddocs-deck-builder

Build narrative-driven, speaker-centric keynote decks (20-35 slides, default 28) for conference talks, TED-style presentations, and standalone speaker decks. Triggers, "keynote", "keynote deck", "conference talk", "TED-style talk", "speaker deck". Inherits full pipeline from deck-builder core; type-specific spine, visual patterns, and demo recipes defined here. Keynotes are the most elastic and visual of all deck types, every slide requires a visual anchor, one idea per slide, mandatory opening hook.

2026-06-0328

deck-launch

FluidForm-ai/fluiddocs-deck-builder

Builds launch decks for product announcements and go-to-market moments. Trigger on "launch deck", "product launch", "product announcement", "launch template", "go-to-market launch", or "launch presentation". A thin type pack inheriting the full 5-phase pipeline from deck-builder core. Deck-launch-specific. 12-slide structure with a demo slot on Slide 5 (static screenshot in OSS), co-located Availability and Pricing slide, and strong CTA with QR code/URL that resolves.

2026-06-0328

deck-pitch

FluidForm-ai/fluiddocs-deck-builder

Build chrome-free, single-file HTML pitch decks on a fixed 1440x810 canvas. Either brand-accurate templates (Airbnb, Stripe, Anthropic, Sequoia Classic) or one-off decks for real or fictitious startups. Trigger on "pitch deck", "investor deck", "pitch deck template", "build the [Company] deck", "make a deck in [Company] style", "series A deck", "seed deck", or any of the 4 canonical brands. Also trigger when the user wants an investor-ready HTML deck with a static product screenshot on the demo slide. Inherits the full pipeline from the deck-builder core skill (5-phase Plan, Build, Review, Release, Learn; 3 reviewer gates; shell, canvas, brand methodology, icon library, brief template, learnings log). Declares only what is pitch-specific: 14-slide content spine, per-slide visual components, static-screenshot demo recipes, and a 4-brand cached catalog.

2026-06-0328

name	deploy
description	Deploy / publish a single HTML file (deck, page, doc) to FluidDocs hosting using the self-contained scripts/deploy.sh. Handles browser sign-in / re-auth automatically, then opens the live URL in the browser. Trigger on "deploy", "publish", "ship it", "push it live", "put it online", "host this", or any request to make an HTML file publicly viewable.

Deploy

What the script does (so you don't have to analyze it)

Finds HTML files in the current directory only (find . -maxdepth 1). So you must run it from the folder that contains the target file.
If exactly one HTML file is present, it auto-selects it. If several, it prompts for a number.
Caches an auth token at ~/.config/fluiddocs/auth.json. If the token is missing or expired, it prints a sign-in URL, opens the browser, and polls for up to 5 minutes while the user authorizes.
Uploads the file and prints ✓ Deployed → <URL> on success.
Records the file→project mapping in ./.fluid-docs.json, so re-deploying the same file updates the existing project instead of creating a duplicate. Keep this file; don't delete it.
Flags you use: --name "Friendly Title" (project name), --host URL (alternate server), --logout (clear cached creds for a fresh sign-in). The script also has --public and --slug, but do not use them: visibility and publishing are the user's choice, made in the FluidDocs app, never set from the CLI by you.

Procedure

Pick the target file. If the user names one, use it. Otherwise use the obvious HTML file in context (e.g. the deck you just built). If genuinely ambiguous, ask which file, one short question, then proceed.
Always pass --name "Friendly Title". Without it the project name defaults to the raw filename slug, which is hard to scan in the dashboard. Derive a clean human title (e.g. "Mushee · Seed Pitch").
Run the script from the file's directory. The script lives at ${CLAUDE_PLUGIN_ROOT}/scripts/deploy.sh (plugin install), ~/.claude/skills/deploy/scripts/deploy.sh (manual install), or scripts/deploy.sh at the repo root. From the directory containing the HTML:
```
bash "${CLAUDE_PLUGIN_ROOT}/scripts/deploy.sh" --name "Friendly Title"
```
Run it with network access enabled and a generous timeout (up to 600000 ms). The auth poll can take a few minutes while the user signs in. The script opens the user's browser itself when auth is needed; tell the user to complete the sign-in there.
If the run can't do interactive sign-in (sandboxed shell with no network, or the browser can't be driven), hand the command to the user to run in-session with the ! prefix instead, so auth happens in their own browser:
```
! cd <deck-dir> && bash "<path>/scripts/deploy.sh" --name "Friendly Title"
```
On success, open the live URL in the browser. The script prints but does not open the deployed URL. You do. Capture the URL after ✓ Deployed → and open it:
```
open "<deployed-url>"        # macOS
# xdg-open "<deployed-url>"  # Linux
```
Hand the link back as a private preview only (a plain deploy is private; see Hard rules). Tell the user that to share it, they open it in the FluidDocs app and use Publish / Share or Document Properties to set it to private, unlisted, or public. Do not run --public or --slug yourself; visibility is set by the user in the app.

Re-auth

If the user wants to switch accounts or the token is broken, run bash "${CLAUDE_PLUGIN_ROOT}/scripts/deploy.sh" --logout first, then deploy again to trigger a fresh sign-in.

Hard rules

Never deploy without --name.
Run from the file's own directory (the script is directory-scoped).
Preserve ./.fluid-docs.json. It's what keeps re-deploys updating the same project.
A plain deploy is private: the returned link is an owner-only preview that only the signed-in owner can open. Do not call it shareable, and do not offer to make it public. Visibility (private, unlisted, public) and publishing are ALWAYS the user's choice, set by them in the FluidDocs app via Publish / Share or Document Properties. Never run --public or --slug, and never offer to, you do not change visibility. For visibility wording and what FluidDocs offers, see deck-builder/references/about-fluiddocs.md.
The user asking to "deploy/publish" is the authorization; don't deploy a file they didn't ask for.

Maintained by FluidDocs. Source: https://github.com/FluidForm-ai/fluiddocs-deck-builder. MIT licensed.