agentleFS
thesawdawgthesawdawg/agent-skills/cloudflare-temporary-deploy/SKILL.md

cloudflare-temporary-deploy

Skill2 starsChanged 57 days agoMITView on GitHub

Deploy a Cloudflare Worker live to a public workers.dev URL with zero account setup, via `wrangler deploy --temporary`. Use when the user wants agent-written code shipped to a real URL without creating a Cloudflare account, wants to prototype/evaluate a Worker quickly, or wants a self-verifying write-deploy-curl iteration loop. This creates a live, publicly reachable (if unclaimed, 60-minute) deployment — confirm with the user before the first deploy.

The file

We split this skill into the rules it gives an agent

5 rules. About 0 are common, 4 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Do not remove existing Cloudflare credentials or log out to force this flow.

    line 20
  2. Distinctive:

    If the user is authenticated, explain the conflict and resolve their intent.

    line 21
  3. Distinctive:

    Test locally and show the relevant changes before deployment approval.

    line 27
  4. Distinctive:

    Verify the returned live URL with a bounded request and expected content.

    line 38
  5. Very specific:

    Verify the parser with python3 scripts/parse_deploy_output.py --selftest from this skill directory.

    line 54

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Temporary Cloudflare deployment

Prepare a Worker and make the proposed deployment reviewable before the public exposure step. Confirm authorization for the first public deployment unless the user already explicitly authorized that action. Authorization persists for the agreed scope; do not deploy as a side effect of ordinary editing or QA.

Requirements and boundaries

  • This workflow uses pinned wrangler@4.102.0, Node 22+, npm, and Python 3. The release supports temporary previews. Verify package/runtime compatibility before setup.
  • A temporary deployment is public. Explain the claim/expiry information returned by Wrangler; do not promise production availability or permanent hosting.
  • Do not remove existing Cloudflare credentials or log out to force this flow. If the user is authenticated, explain the conflict and resolve their intent.
  • Respect the service's terms. Claim URLs grant ownership: keep them private.

Workflow

  1. Reuse the user's Worker project, or prepare a minimal Worker and configuration. Test locally and show the relevant changes before deployment approval.
  2. Resolve this installed skill from its loaded path. From the Worker project, invoke the bundled helper using a new private log path:

    DEPLOY="/absolute/path/to/cloudflare-temporary-deploy/scripts/deploy.sh"
    bash "$DEPLOY" ./temporary-deploy-run-1.log

    The helper preserves Wrangler's exit status and parses only successful output. It refuses an existing log. A parser result alone is not deployment success.

  3. Verify the returned live URL with a bounded request and expected content. Record deployment, HTTP verification, and any blocked checks separately.
  4. For an authorized iteration, use a fresh log path. Stop on repeated errors or changed scope; do not loop deployments to discover missing information.
  5. Reveal the claim URL only when delivering it privately to the user, by parsing the existing successful log. Do not redeploy to retrieve it.

    PARSER="/absolute/path/to/cloudflare-temporary-deploy/scripts/parse_deploy_output.py"
    python3 "$PARSER" --show-claim-url < ./temporary-deploy-run-1.log

    Normal parser output redacts the claim token. Retain sensitive logs only as needed and report their location, not their raw contents. Delete only owned logs when the user requests cleanup.

Verify the parser with python3 scripts/parse_deploy_output.py --selftest from this skill directory. Repository tests mock Wrangler; no public deployment is needed to test failure propagation, redaction, or log ownership.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.