How to use the Script Loading Checker (defer/async) agent skill

What the defer-async skill makes the agent do

When the skill is active, the agent reviews HTML, templates, server-rendered output and shared components for script tags that load in a blocking way. A plain script in the document head without defer or async is the main example. The agent flags the exact elements, explains the difference between defer, async and type=module, and suggests the markup change.

The skill is guidance only. It teaches the agent what to look for and how to fix it, and the files contain no executable code.

• defer: downloads in parallel and runs after HTML parsing, in order. The source recommends it for most scripts.
• async: downloads in parallel and runs as soon as it is ready. The source recommends it for independent scripts.
• type=module: always defers and enables ES module syntax.
• Rule of thumb from the source: never place scripts in head without defer or async.

Install the defer-async skill

Download the ZIP from the skill's page on our directory and unzip it. Then place the folder in one of these locations, depending on how you want to use it:

For all your projects, put it in ~/.claude/skills/. For a single project, put it in that project's .claude/skills/ folder. Alternatively, in the Claude apps, open Settings, go to Capabilities and upload the skill under Skills.

The package contains two files: SKILL.md, which holds the main instructions, and references/rule.md, which has fuller implementation details, code examples and framework-specific guidance.

Trigger the skill with natural requests

You do not need a special command. The skill's description tells the agent when to use it: reviewing templates, rendered HTML or shared components related to loading scripts with defer, async or type=module. Ask for that work in ordinary language and mention the file or component you want checked.

Point the agent at the final browser-facing markup where you can. The source advises validating the output the browser receives, not only the source framework code.

• Review this page template for script tags that block rendering.
• Check the shared header component for scripts in head without defer or async.
• Explain whether app.js should use defer, async or type=module.
• Look at the server-rendered HTML for this route and flag render-blocking scripts.

Example: reviewing a plain script in the head

Suppose a template contains a plain script tag in the head. The skill's check asks the agent to find all script tags in the HTML file, flag any in the head without defer or async, and flag scripts at the bottom of body that could move to head with defer.

The source explains why this matters: a plain script blocks HTML parsing until it downloads, parses and executes. The agent's suggested fix is to add defer or async to the tag, or to convert it to type=module where ES modules are used.

What the skill needs and what it does not do

The skill lists no requirements. It does not run scripts and does not use the network. Its files are instructions the agent reads, so you review the agent's suggested changes yourself before applying them.

The skill is not a good fit for projects whose framework or bundler already manages script loading, because the advice may not apply to generated output unless you check the final HTML. It also assumes familiarity with HTML markup, so it is less useful to people who only want to build a site without reading code.

• No runtime requirements are listed.
• No script execution and no network access.
• License: MIT.

Tips for better results

Give the agent the rendered HTML or the template together with the shared components it includes. Flagged elements are more useful when the agent can see where the markup is produced.

Ask for an explanation as well as a fix if you are learning. The skill is designed to explain the difference between defer, async and type=module so you can decide case by case.

• Include the rendered output, not only the source template, when frameworks generate script tags.
• Ask why a script was flagged before accepting the change.
• Re-run the review after a change to confirm the flagged element is fixed.