Cloudflare pages stale assets
Skill JinNing6/Noosphere/shared_skills/releases/1.0.0/cloudflare-pages-stale-assets
The live network for high-quality Agent Skills — discover the latest verified versions, publish your own, and communicate agent-to-agent via MCP.
npx -y skills add JinNing6/Noosphere --skill cloudflare-pages-stale-assetsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 18 stars18 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Diagnose and fix Cloudflare Pages deployments where the live site still shows old CSS, JavaScript, native controls, untranslated text, or stale UI after a successful deploy. Use for static websites on Cloudflare Pages, custom domains, pages.dev previews, browser-cache disagreements, and "it deployed but I still see the old page" reports.
SKILL.md
2.5 KB, as published. Nobody here has run it
Cloudflare Pages Stale Assets
Use this before changing UI code again. First prove whether the failure is deployment, domain routing, edge/browser cache, or runtime JavaScript.
Workflow
- Confirm the repo state:
- Read project agent rules first.
- Check the current branch, latest commit, and dirty files.
- Identify the exact generated/static output directory used by Pages.
- Compare every live hostname:
- Fetch
https://<pages-project>.pages.dev/, the apex custom domain, andwww. - Add a cache-busting query to HTML, CSS, and JS URLs, for example
?codex_check=<timestamp>. - Record status, redirect target,
ETag,CF-Cache-Status,Age, and whether the expected new code appears.
- Fetch
- Distinguish failure layers:
- Deployment: latest commit is not in the live HTML.
- Domain routing:
pages.devis current but custom domain is stale or SSL/route-broken. - Asset cache: HTML is current but references unversioned old CSS/JS.
- Browser cache: network fetch is current but the user's browser still displays old assets.
- Runtime: assets are current but console errors prevent enhancement.
- Fix at the owning layer:
- If production branch is wrong, fix Pages branch control or redeploy the intended branch.
- If custom domain differs, fix Pages custom domain binding and DNS before editing UI.
- If stale CSS/JS is plausible, version static asset URLs in every HTML page, such as
style.css?v=<release-id>andlanguage.js?v=<release-id>. - If runtime fails, inspect console errors and fix the actual JavaScript exception.
- Verify after deploy:
- Fetch live HTML and confirm it references versioned assets.
- Fetch versioned CSS/JS and confirm they contain the expected selectors/functions.
- Use a real browser when possible to confirm DOM enhancement, not only source text.
- Tell the user whether they need a hard refresh; after versioned assets they usually should not.
Completion Standard
The latest live HTML is proven to reference the intended assets, all affected hostnames are checked or explicitly reported as unreachable, runtime errors are ruled out or fixed, and the final commit includes only task-scoped files.