OpenClaw Skill: Obsidian Markdown to Cloudflare Pages

Publish selected Obsidian markdown from a vault to a static site and deploy to Cloudflare Pages.

Security Scan

The skill's behavior generally matches its stated purpose (publishing Obsidian/Markdown to Cloudflare Pages), but there are a few coherence and safety concerns you should review before installing and running it.

Purpose & Capability

Name and description align with the included CLI and code: it syncs markdown, builds with Quartz, and deploys with Wrangler. However the registry metadata does not declare the Cloudflare API credentials the code actually expects (CLOUDFLARE_API_TOKEN, CLOUDFLARE_ACCOUNT_ID), which is an omission in the manifest.

Instruction Scope

SKILL.md and the CLI instruct only the expected publish flow (init, wizard, sync, build, deploy). The CLI also reads files in the user home (detectOpenVaults checks ~/Library/Application Support/obsidian/obsidian.json) to auto-detect vaults, and the wizard can write secrets into config.json (basicAuth.password) if provided — the README warns about this but the functionality exists. The skill runs shell commands (rsync, npx quartz, wrangler) via execSync; these are expected for the task but will execute arbitrary local commands.

Install Mechanism

No install spec or remote downloads; the skill is instruction-only with a bundled Node CLI. Nothing is pulled from arbitrary URLs during install. Users must have Node, npm, rsync, npx, and wrangler installed separately.

Credentials

The skill requires Cloudflare credentials (CLOUDFLARE_API_TOKEN and CLOUDFLARE_ACCOUNT_ID) and optionally basic auth credentials, but the registry metadata lists no required env vars or primary credential. This mismatch is a manifest omission that makes it harder to audit what secrets the skill needs. The wizard can also persist basic auth passwords into config.json (plaintext) unless the user explicitly uses env-backed credentials, which increases risk of accidental secret leakage.

Persistence & Privilege

always is false and the skill does not request persistent platform-wide privileges. It can clear a workspace directory as part of a fallback setup, but that destructive behavior is gated by the ALLOW_DESTRUCTIVE=1 environment variable and there are explicit guards (assertSafePath) and warnings in the docs. Still, this capability is powerful and must be used only on a dedicated workspace path.

What to consider before installing

This skill appears to implement the advertised Obsidian→Cloudflare Pages workflow, but review these items before using it: - Provide Cloudflare credentials only via a local .env or shell environment; the skill expects CLOUDFLARE_API_TOKEN and CLOUDFLARE_ACCOUNT_ID but the registry metadata did not declare them — that is a manifest omission. Treat this as intentional: the tool needs a Cloudflare token to deploy. - The wizard can store a basic-auth password directly into config.json (plaintext) unless you explicitly use env-backed credentials; prefer BASIC_AUTH_USERNAME/PASSWORD in your environment and do not commit config.json. - The CLI will attempt to read files in your home directory (it tries to detect Obsidian vaults at a macOS path). If you don't want that, run on a controlled machine or edit the script. - The script can run arbitrary shell commands (rsync, npx quartz, wrangler) and has a fallback that may clear the configured workspace when ALLOW_DESTRUCTIVE=1 is set — only point the workspace to a dedicated path you can safely wipe. - Use --dry-run / DRY_RUN=1 first to preview actions, inspect bin/publishmd-cf.js for any code you are uncomfortable with, and consider running the workflow on a test subdomain before production. If these caveats are acceptable and you verify the code, the skill itself is coherent with its purpose; the main issues are the missing manifest declaration for required envs and the potential for accidental plaintext secret storage and destructive workspace operations.

OpenClaw Skill: Obsidian/Markdown → Cloudflare Pages

This is an OpenClaw Skill for publishing Markdown to Cloudflare Pages.

• Works with Obsidian vault folders or any Markdown folder
• Originally built for reading Obsidian Web Clipper output:
  • https://obsidian.md/clipper

Automates a safe publishing flow:

1. Select notes from your source folder
2. Sync to a publish workspace
3. Build static HTML with Quartz
4. Deploy to Cloudflare Pages

Commands

• node skills/obsidian-cloudflare-pages/bin/publishmd-cf.js init
  • Creates config/config.json from example
• node skills/obsidian-cloudflare-pages/bin/publishmd-cf.js wizard
  • Interactive setup wizard for config (vault, folders, site/domain, Cloudflare project)
• node skills/obsidian-cloudflare-pages/bin/publishmd-cf.js setup-project
  • Initializes Quartz project in configured workspace if missing
• node skills/obsidian-cloudflare-pages/bin/publishmd-cf.js doctor
  • Validates paths + required binaries
• node skills/obsidian-cloudflare-pages/bin/publishmd-cf.js sync
  • Syncs selected notes/assets into publish content folder
• node skills/obsidian-cloudflare-pages/bin/publishmd-cf.js build
  • Runs Quartz build in project dir
• node skills/obsidian-cloudflare-pages/bin/publishmd-cf.js deploy
  • Deploys to Cloudflare Pages with wrangler
• node skills/obsidian-cloudflare-pages/bin/publishmd-cf.js run
  • sync → build → deploy
• node skills/obsidian-cloudflare-pages/bin/publishmd-cf.js run --dry-run
  • previews actions without mutating files or deploying

Config

Copy and edit:

skills/obsidian-cloudflare-pages/config/config.example.json → skills/obsidian-cloudflare-pages/config/config.json

Safety defaults

• Publish allowlist by folder
• Optional publish: true frontmatter gate
• Exclude private folders by default

Requirements

• node 20+
• rsync
• npm
• npx quartz
• wrangler

Cloudflare API token setup (recommended)

Create a Cloudflare API token with at least:

• Account → Cloudflare Pages:Edit
• (Optional) Zone → DNS:Edit if you want DNS automation elsewhere

You can either export env vars in your shell profile (~/.zshrc) or use the skill-local .env file.

Option A: shell profile (~/.zshrc)

export CLOUDFLARE_API_TOKEN="<your-token>"
export CLOUDFLARE_ACCOUNT_ID="<your-account-id>"

Reload shell:

source ~/.zshrc

Option B: skill-local env file (recommended for this skill)

cp skills/obsidian-cloudflare-pages/.env.example skills/obsidian-cloudflare-pages/.env
# then edit .env
# optional auth envs: BASIC_AUTH_USERNAME / BASIC_AUTH_PASSWORD

The CLI auto-loads skills/obsidian-cloudflare-pages/.env (without overriding existing shell env vars).

Wizard now asks for:

• Full production domain (e.g. YOURDOMAIN.COM)
• Branding settings (root source folder, source index label, root index label, sidebar title HTML)
• Token/account env var names (defaults above)
• Optional basic-auth protection (username/password)

Notes

• ⚠️ setup-project fallback behavior: if the direct Quartz bootstrap command fails, the fallback path may clear files in the configured workspace directory before cloning Quartz. Use a dedicated workspace path for this skill.
• Fallback cleanup is guarded and requires ALLOW_DESTRUCTIVE=1 when workspace is non-empty.
• Dry-run output redacts sensitive values such as API tokens.

OpenClaw usage tips

Example prompts:

• “Set up obsidian-cloudflare-pages wizard for my markdown folder.”
• “Run doctor and tell me what dependency is missing.”
• “Sync, build, and deploy to Cloudflare Pages.”
• “Enable basic auth and redeploy.”

Best practices:

• Keep secrets in .env (never in chat logs)
• Prefer env-backed basic auth (BASIC_AUTH_USERNAME / BASIC_AUTH_PASSWORD)
• Commit config.example.json, not personal config.json
• Use a scoped Cloudflare token (Pages edit, DNS edit only if needed)
• Start on a test subdomain before production

Standalone usage (outside OpenClaw)

This works as a plain Node CLI too:

node bin/publishmd-cf.js init
node bin/publishmd-cf.js wizard
cp .env.example .env
# fill .env values
node bin/publishmd-cf.js run

Security note

Basic auth in this skill is intentionally simple and optional. Do not publish highly sensitive content unless you fully understand your security model and hardening choices.

Safety switches:

• --dry-run (or DRY_RUN=1) to preview actions without mutating/deploying
• ALLOW_DESTRUCTIVE=1 only when you intentionally allow fallback setup to clear a non-empty workspace directory