Run any Skill in Manus with one click

github-page-preview

Stars0

Forks0

UpdatedJuly 8, 2026 at 05:55

When deploying a static site to GitHub Pages — especially when you want a per-PR preview URL — call the reusable workflow `kuboon/workflows/.github/workflows/github-page-with-preview.yaml` instead of hand-writing configure-pages/upload-pages-artifact/deploy-pages jobs. Use this skill whenever you set up or edit a workflow that publishes to GitHub Pages, add PR/deploy previews, or the user mentions "GitHub Pages", "preview deployment", "deploy preview", "PR preview", or a static-site deploy. The reusable workflow builds `main` at the site root and each PR branch under a subpath, deploys both, and comments the preview URL on the PR.

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

kuboon

kuboon/agent-plugins

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

github-page-preview

description

GitHub Pages with per-PR previews

When you set up GitHub Pages deployment, do not hand-roll the configure-pages → build → upload-pages-artifact → deploy-pages job chain, and do not re-invent PR previews. Call the maintained reusable workflow:

kuboon/workflows/.github/workflows/github-page-with-preview.yaml

It builds main at the Pages root, builds the PR branch under a subpath, deploys both to GitHub Pages, and posts (and updates) a preview-URL comment on the PR.

Caller workflow (drop this in `.github/workflows/pages.yml`)

name: pages
on:
  push:
    branches: [main]
  pull_request:

jobs:
  pages:
    uses: kuboon/workflows/.github/workflows/github-page-with-preview.yaml@main
    # Override only if your defaults differ:
    # with:
    #   build-command: mise run build
    #   dist-dir: dist

Pin the ref for stability: @main (as the repo's README shows), or a released tag / major branch such as @v0.15.0 or @v0 (the repo maintains major-version branches). Prefer a pinned tag over @main when you want reproducible CI — consistent with the github-actions-versions skill's pinning policy.

Inputs

input	default	meaning
`build-command`	`mise run build`	Command that builds the static site. Run once for `main`, once for the PR branch.
`dist-dir`	`dist`	Directory the build writes the site into, relative to the checkout.

The workflow declares its own permissions (pages: write, id-token: write, pull-requests: write) and a pages concurrency group, so the caller only needs the triggers above.

What the consuming repo must provide

Pages source = GitHub Actions. Repo → Settings → Pages → Build and deployment → Source: GitHub Actions. The workflow uses the github-pages environment.
A build the workflow can invoke. With the default, that means a mise config (mise.toml) exposing a build task (the workflow installs mise itself). If you don't use mise, pass build-command: with your own (e.g. deno task build, npm run build).
A BASE_URL-aware build. This is the part people miss. The workflow runs the build with a BASE_URL env var:
- for main: the Pages base URL (e.g. https://user.github.io/repo);
- for a PR: that base URL plus /<fragment>, where <fragment> is the last path segment of the branch name.
Your build must emit asset/link paths under BASE_URL, or the preview loads broken CSS/JS. Wire BASE_URL into your framework's base-path setting (Vite base, Astro base, <base href>, etc.).

What it does, step by step

Always checks out main, builds it with BASE_URL = Pages root, moves the output to dist/.
On a pull_request, also checks out the PR branch, builds it with BASE_URL = root + /<fragment>, and places it at dist/<fragment>/.
Uploads dist/ and deploys it with deploy-pages.
On a PR, comments プレビューをデプロイしました: <url> on the PR, updating the existing comment (matched by a hidden  marker) instead of posting duplicates.

Gotchas

BASE_URL is mandatory for correct previews. A build that ignores it produces a preview with root-absolute asset paths that 404 under the subpath.
Only one PR preview persists at a time. Each run deploys a dist/ that contains just main plus the current PR's fragment. Because a Pages deploy replaces the whole site, a new deploy removes other PRs' preview subpaths. It's "latest run wins," not a durable per-PR gallery.
The fragment is only the last path segment of the branch. feature/login and hotfix/login both become login and collide. Keep the final segment unique across open PRs.
main is rebuilt on every run, including PR runs — the build must succeed on main too, not just the PR branch.
Requires GitHub Pages enabled with the Actions source; without it, deploy-pages fails with a Pages-not-enabled error.

More from this repository

same repository

uint8array-base64

kuboon/agent-plugins

When encoding or decoding base64 (or hex) in JavaScript/TypeScript, use the native Uint8Array base64 methods — `Uint8Array.fromBase64()`, `Uint8Array.prototype.toBase64()`, and `Uint8Array.prototype.setFromBase64()` — instead of `btoa`/`atob` string juggling, `Buffer.from(...).toString("base64")`, or hand-rolled `String.fromCharCode(...)` loops. Use this skill whenever code converts bytes ↔ base64, handles base64url tokens (JWT, WebAuthn, VAPID, data URLs), or you see `btoa`/`atob`/`Buffer` used for binary base64. These methods are binary-safe and run in both Deno and the browser. Model habit reaches for `btoa`/`atob` or `Buffer`; this skill overrides that.

2026-07-090

browser-how-to

kuboon/agent-plugins

When integrating "Add to Home Screen" (a2hs / PWA install), passkeys (WebAuthn), or web push notifications into a web frontend, use the @kuboon/browser-how-to library. Use this skill whenever you add or review code that: prompts a PWA install / "add to home screen", detects passkey/WebAuthn capability, requests or explains notification permission / Web Push, or handles in-app browsers (Facebook/Messenger/Instagram/LINE/etc.) that block these features. The library handles the "can this device do it? → if not, send to a standard browser → if yes, show how" flow so you don't hand-roll device/UA detection. Framework- agnostic (Vanilla JS/TS). Full reference: https://kuboon.github.io/browser-how-to/llms.txt

2026-07-080

deno-remix-init

kuboon/agent-plugins

When initializing or scaffolding a NEW project — a web app, service, or boilerplate — use Deno as the runtime (NOT Node.js/npm/pnpm) and Remix v3 (`@remix-run/fetch-router`) as the web framework. Use this skill whenever you are choosing a runtime or web framework, creating package/runtime config (package.json vs deno.json), setting up a dev server, CI, or a devcontainer for a fresh project, or the user says "new project", "init", "scaffold", "setup", "boilerplate", or "start a web app". Model defaults to Node.js + Express/Next; this skill overrides that. Follow the deno-remix-reference implementation: https://github.com/kuboon/deno-remix-reference/tree/main/reference

2026-07-050

run-agent-plugins

kuboon/agent-plugins

Build, validate, run, and smoke-test the agent-plugins Claude Code plugin marketplace. Use when asked to run, launch, test, validate, verify, or screenshot this repo, to check that the marketplace and its plugins load in Claude Code, or after editing any marketplace.json, plugin.json, or SKILL.md.

2026-07-010

github-actions-versions

kuboon/agent-plugins

Pin GitHub Actions to current, non-deprecated major versions when writing or editing GitHub Actions workflows. Use this skill whenever creating or modifying a file under .github/workflows/, writing or reviewing CI/CD YAML, or adding/ changing any `uses:` step — even when the user does not mention versions at all. Model training data lags behind real releases and tends to emit stale versions such as `actions/checkout@v4` or `actions/setup-node@v4`. Always consult the pinned version table in this skill instead of relying on remembered versions.

2026-07-010

name

github-page-preview

description

GitHub Pages with per-PR previews

kuboon/workflows/.github/workflows/github-page-with-preview.yaml

It builds main at the Pages root, builds the PR branch under a subpath, deploys both to GitHub Pages, and posts (and updates) a preview-URL comment on the PR.

Caller workflow (drop this in `.github/workflows/pages.yml`)

name: pages
on:
  push:
    branches: [main]
  pull_request:

jobs:
  pages:
    uses: kuboon/workflows/.github/workflows/github-page-with-preview.yaml@main
    # Override only if your defaults differ:
    # with:
    #   build-command: mise run build
    #   dist-dir: dist

Inputs

input	default	meaning
`build-command`	`mise run build`	Command that builds the static site. Run once for `main`, once for the PR branch.
`dist-dir`	`dist`	Directory the build writes the site into, relative to the checkout.

The workflow declares its own permissions (pages: write, id-token: write, pull-requests: write) and a pages concurrency group, so the caller only needs the triggers above.

What the consuming repo must provide

Pages source = GitHub Actions. Repo → Settings → Pages → Build and deployment → Source: GitHub Actions. The workflow uses the github-pages environment.
A build the workflow can invoke. With the default, that means a mise config (mise.toml) exposing a build task (the workflow installs mise itself). If you don't use mise, pass build-command: with your own (e.g. deno task build, npm run build).
A BASE_URL-aware build. This is the part people miss. The workflow runs the build with a BASE_URL env var:
- for main: the Pages base URL (e.g. https://user.github.io/repo);
- for a PR: that base URL plus /<fragment>, where <fragment> is the last path segment of the branch name.
Your build must emit asset/link paths under BASE_URL, or the preview loads broken CSS/JS. Wire BASE_URL into your framework's base-path setting (Vite base, Astro base, <base href>, etc.).

What it does, step by step

Always checks out main, builds it with BASE_URL = Pages root, moves the output to dist/.
On a pull_request, also checks out the PR branch, builds it with BASE_URL = root + /<fragment>, and places it at dist/<fragment>/.
Uploads dist/ and deploys it with deploy-pages.
On a PR, comments プレビューをデプロイしました: <url> on the PR, updating the existing comment (matched by a hidden  marker) instead of posting duplicates.

Gotchas

BASE_URL is mandatory for correct previews. A build that ignores it produces a preview with root-absolute asset paths that 404 under the subpath.
Only one PR preview persists at a time. Each run deploys a dist/ that contains just main plus the current PR's fragment. Because a Pages deploy replaces the whole site, a new deploy removes other PRs' preview subpaths. It's "latest run wins," not a durable per-PR gallery.
The fragment is only the last path segment of the branch. feature/login and hotfix/login both become login and collide. Keep the final segment unique across open PRs.
main is rebuilt on every run, including PR runs — the build must succeed on main too, not just the PR branch.
Requires GitHub Pages enabled with the Actions source; without it, deploy-pages fails with a Pages-not-enabled error.

github-page-preview

GitHub Pages with per-PR previews

Caller workflow (drop this in .github/workflows/pages.yml)

Inputs

What the consuming repo must provide

What it does, step by step

Gotchas

More from this repository

More from this repository

GitHub Pages with per-PR previews

Caller workflow (drop this in .github/workflows/pages.yml)

Inputs

What the consuming repo must provide

What it does, step by step

Gotchas

Caller workflow (drop this in `.github/workflows/pages.yml`)

Caller workflow (drop this in `.github/workflows/pages.yml`)