A skill is a folder holding a SKILL.md file: YAML front matter with a name and a description, then plain Markdown instructions. The open spec caps the name at 64 lowercase letters, digits or hyphens and the description at 1024 characters. Use the form to write one, or paste a file to lint it.
SKILL.md front matter rules (as of October 2026)
Field
Open spec
Claude Code
name
Required, 1 to 64 chars, a-z 0-9 and single hyphens
Optional, defaults to the folder name
description
Required, 1 to 1024 chars
Recommended; listing capped at 1,536 chars with when_to_use
compatibility
Optional, up to 500 chars
Accepted, not acted on
allowed-tools
Optional, experimental
Pre-approves tools for the invoking turn
Updated
Skills give a coding agent a reusable playbook it loads only when a task calls for it. The hard part is not the Markdown, it is the header: a name with an uppercase letter or a double hyphen fails validation, and a vague description means the agent never picks the skill up. This page writes the header for you, checks pasted files against the published rules, and runs entirely in your browser.
Write a SKILL.md
Everything runs in this tab. Nothing you type is uploaded.
Save as .claude/skills/seo-meta-check/SKILL.md
---
name: seo-meta-check
description: "Checks a page's title, meta description and canonical tag. Use when the user asks for an SEO review or edits a page head."
---
# Page head check
1. Open the page component.
2. Check the title, description and canonical.
3. Report problems with exact fixes.
Or create it from a terminal
mkdir -p .claude/skills/seo-meta-check
# then save the file below as .claude/skills/seo-meta-check/SKILL.md
Check of the file above
OK:No problems found against the spec and the Claude Code rules.
Lint a SKILL.md
Paste a SKILL.md. Add the folder name if you want the name check against it.
Ten ready skills for web projects
Our own examples, free to copy and adapt. Each one is a complete SKILL.md.
Accessibility review
Walks a component or page through labels, focus order, contrast and alt text, then lists fixes by severity.
accessibility-review/SKILL.md
---
name: accessibility-review
description: Reviews React, Vue or HTML UI for keyboard access, labels, focus, contrast and alt text. Use when the user asks for an accessibility or a11y check, or edits forms, dialogs or buttons.
---
# Accessibility review
1. List every interactive element in the files you were given.
2. For each one check: it is reachable with Tab, it has a visible focus style, and it has an accessible name (label, aria-label or text).
3. Check images: decorative ones get alt="", meaningful ones get a short description.
4. Check that text contrast meets WCAG AA (4.5:1 for body text, 3:1 for large text).
5. Check dialogs trap focus and return it to the trigger when closed.
Report findings as a table: element, problem, fix, severity (blocker, serious, minor). Fix blockers directly if the user agrees.
SEO meta check
Checks title, meta description, canonical, Open Graph and heading order in a page's head and body.
seo-meta-check/SKILL.md
---
name: seo-meta-check
description: Checks a page's title, meta description, canonical URL, Open Graph tags and heading order. Use when the user asks for an SEO review or changes a layout, head component or page template.
---
# SEO meta check
For each page file:
- Title: present, unique, roughly 50 to 60 characters.
- Meta description: present, roughly 140 to 160 characters, matches the page.
- Canonical: absolute URL, points at the page itself unless it is a duplicate.
- Open Graph: og:title, og:description, og:image (absolute URL) and og:url.
- Exactly one h1, and no heading levels skipped.
Print a short pass/fail list per page and propose exact replacement tags for anything that fails. Do not invent claims for the description.
Changelog writer
Turns the commits since the last tag into a grouped, human-readable changelog entry.
changelog-writer/SKILL.md
---
name: changelog-writer
description: Writes a CHANGELOG.md entry from git history since the last tag, grouped into Added, Changed, Fixed and Removed. Use when the user asks for release notes, a changelog or a version bump.
---
# Changelog writer
1. Run `git describe --tags --abbrev=0` to find the last tag, then `git log <tag>..HEAD --oneline`.
2. Group commits into Added, Changed, Fixed, Removed. Drop merge commits and pure chores.
3. Rewrite each line for a user, not a developer: say what changed for them.
4. Add the entry at the top of CHANGELOG.md under a heading with the new version and today's date.
Ask before choosing the version number if it is not obvious.
React component scaffold
Creates a typed React component, a story or test file and an index export that follow the repo's existing patterns.
react-component-scaffold/SKILL.md
---
name: react-component-scaffold
description: Creates a new React component with TypeScript props, a test and an export, matching the repo's existing folder and styling conventions. Use when the user asks for a new component.
---
# React component scaffold
1. Look at two existing components in the same folder and copy their structure, naming and styling approach.
2. Create the component with a typed Props interface and no default export unless the repo uses them.
3. Add a test next to it that renders the component and checks one visible behaviour.
4. Export it from the nearest index file if the folder has one.
Do not add new dependencies. Run the type check and the new test before you finish.
Alt text audit
Finds images with missing, empty or filename-style alt text and drafts better descriptions.
alt-text-audit/SKILL.md
---
name: alt-text-audit
description: Finds img and Image elements with missing, generic or filename-like alt text and drafts replacements. Use when the user asks about alt text, image accessibility or image SEO.
---
# Alt text audit
1. Search the source for <img and <Image elements.
2. Flag alt text that is missing, says "image" or "photo", or looks like a file name.
3. Decide if each image is decorative (alt="") or informative.
4. For informative images, draft alt text under 125 characters that says what the image shows in context.
Show a table of file, line, current alt, suggested alt. Apply changes only after the user confirms.
Responsive layout check
Reads layout code for fixed widths, overflow risks and missing breakpoints before they show up on a phone.
responsive-check/SKILL.md
---
name: responsive-check
description: Reviews CSS, Tailwind or styled components for fixed widths, horizontal overflow and missing mobile breakpoints. Use when the user reports layout problems on phones or asks for a responsive review.
---
# Responsive layout check
Look for:
- Fixed pixel widths on containers wider than 360px without a max-width.
- Long words, URLs or code blocks that can push the page sideways (add overflow-wrap or overflow-x: auto).
- Grids and flex rows with no small-screen fallback.
- Images and videos without max-width: 100%.
- Tap targets smaller than about 44 by 44 CSS pixels.
List each issue with the file and line, then the smallest change that fixes it.
Env var audit
Cross-checks environment variables used in code against .env.example and flags secrets exposed to the browser.
env-var-audit/SKILL.md
---
name: env-var-audit
description: Compares environment variables used in code with .env.example and flags secrets exposed to client bundles. Use when the user adds config, sets up deployment or asks about env files.
---
# Env var audit
1. Find every process.env.X, import.meta.env.X and os.environ reference.
2. Compare with .env.example: list variables used but undocumented, and documented but unused.
3. Flag any secret-looking name (KEY, SECRET, TOKEN, PASSWORD) that carries a public prefix such as NEXT_PUBLIC_ or VITE_, since those reach the browser.
4. Never print real values from .env files.
Offer an updated .env.example with placeholder values.
Commit message writer
Reads the staged diff and writes a conventional commit subject and body.
commit-message/SKILL.md
---
name: commit-message
description: Writes a conventional commit message from the staged diff. Use when the user asks for a commit message or says to commit their changes.
---
# Commit message writer
1. Run `git diff --staged`. If nothing is staged, say so and stop.
2. Pick a type: feat, fix, refactor, docs, test, chore, perf or ci.
3. Write a subject under 72 characters in the imperative mood.
4. Add a short body only when the reason for the change is not obvious from the subject.
Show the message and wait for approval before running git commit.
Dependency update review
Reads a lockfile diff, names the major bumps and points at the changelog entries worth reading.
dependency-update-review/SKILL.md
---
name: dependency-update-review
description: Reviews package.json and lockfile changes for major version bumps, new packages and licence changes. Use when the user updates dependencies or reviews a dependency pull request.
---
# Dependency update review
1. Diff package.json and the lockfile against the main branch.
2. List new packages, removed packages and every version change, marking major bumps.
3. For each major bump, open the package's changelog and summarise breaking changes in one line.
4. Note any new package whose licence is not MIT, Apache-2.0, BSD or ISC.
End with a short go / check first / hold verdict per package.
Landing page copy review
Checks a landing page's headline, proof and call to action for clarity, with rewrites that keep claims honest.
landing-copy-review/SKILL.md
---
name: landing-copy-review
description: Reviews landing page copy for a clear headline, specific benefits, honest proof and one call to action. Use when the user asks for copy feedback on a homepage, landing page or pricing page.
---
# Landing page copy review
Read the page top to bottom and answer:
- Does the headline say what the product does and for whom, in under 12 words?
- Are benefits specific, or generic words like "powerful" and "seamless"?
- Is every number, review or logo real? Flag anything that cannot be verified.
- Is there one main call to action, repeated, with the same wording?
Give up to five rewrites, each with the original line and the suggested line. Never add claims the user has not confirmed.
Folder layout and a minimal file
Only SKILL.md is required. The scripts, references and assets folders are conventions from the spec; the agent reads them only when the instructions point at them.
A skill folder
Text
The folder name and the name field must match. Keep links from SKILL.md one level deep.
Two fields and a body. This passes the spec and loads in Claude Code.
---
name: seo-meta-check
description: Checks title, meta description and canonical tags. Use when the user asks for an SEO review.
---
1. Open the page head.
2. Report missing or duplicate tags with fixes.
How an agent decides to load your skill
At startup only the name and description of every installed skill are read, roughly a hundred tokens each. The full body is pulled in when a request matches. That is why the description carries so much weight: it is the only thing the agent sees before choosing.
Write it as two parts. First what the skill does, in concrete verbs. Then when to use it, naming the inputs or phrases that should trigger it. 'Helps with SEO' is too thin; 'Checks title, meta description and canonical tags in HTML or JSX files. Use when the user asks for an SEO review or edits a page head' gives the agent something to match.
Portable fields versus Claude Code extras
Six keys are portable: name, description, license, compatibility, metadata and allowed-tools. Claude Code also reads extras such as when_to_use, argument-hint, disable-model-invocation, user-invocable, model, effort, context and paths, and ignores keys it does not know.
The catch is uploading. On claude.ai, through the Skills API or with the packaging script, any key outside the portable six is a hard error. The linter on this page flags those keys so you know which file will travel and which is Claude Code only.
How it works
Type a short name. The form lowercases it and swaps spaces for hyphens as you go.
Describe what the skill does and, in the second box, when it should be used. Both end up in the description line.
Add the step-by-step instructions as Markdown, plus any optional fields you need.
Copy the file or download SKILL.md, then save it in a folder that has the same name as the skill.
Tips
Put trigger words in the description, such as file types or phrases people actually type. That text decides when the skill loads.
Keep SKILL.md under 500 lines and move long reference material into separate files the skill links to.
Use disable-model-invocation for skills with side effects, such as a deploy, so they only run when you type the slash command.
If you plan to upload the skill to claude.ai or the API, stick to the six portable fields; other keys are rejected there.
Frequently asked questions
Where do I save a Claude Code skill?
Project skills go in .claude/skills/<skill-name>/SKILL.md inside the repository, so the whole team gets them. Personal skills go in ~/.claude/skills/<skill-name>/SKILL.md and work in every project on your machine.
Is the name field required?
The open Agent Skills spec requires it and says it must match the parent folder name. Claude Code is more lenient: if name is missing it uses the folder name for the slash command.
How long can a skill description be?
The spec allows 1 to 1024 characters. Claude Code appends any when_to_use text to the description in its skill listing, and that combined text is capped at 1,536 characters.
What is the difference between a skill and a slash command?
Claude Code merged them. A file at .claude/commands/deploy.md and a skill at .claude/skills/deploy/SKILL.md both create /deploy. Skills add a folder for supporting files and can be loaded automatically when relevant.
Does this tool send my skill anywhere?
No. Writing, linting and downloading all happen in this browser tab. Nothing you type is uploaded.
Need the website too?
Describe your business and the We.Inc AI builder drafts a site you can edit in plain English.
Start for free
Claude Skills Builder and SKILL.md Linter
A skill is a folder holding a SKILL.md file: YAML front matter with a name and a description, then plain Markdown instructions. The open spec caps the name at 64 lowercase letters, digits or hyphens and the description at 1024 characters. Use the form to write one, or paste a file to lint it.
SKILL.md front matter rules (as of October 2026)
Field
Open spec
Claude Code
name
Required, 1 to 64 chars, a-z 0-9 and single hyphens
Optional, defaults to the folder name
description
Required, 1 to 1024 chars
Recommended; listing capped at 1,536 chars with when_to_use
compatibility
Optional, up to 500 chars
Accepted, not acted on
allowed-tools
Optional, experimental
Pre-approves tools for the invoking turn
Updated
Skills give a coding agent a reusable playbook it loads only when a task calls for it. The hard part is not the Markdown, it is the header: a name with an uppercase letter or a double hyphen fails validation, and a vague description means the agent never picks the skill up. This page writes the header for you, checks pasted files against the published rules, and runs entirely in your browser.
Write a SKILL.md
Everything runs in this tab. Nothing you type is uploaded.
Lint a SKILL.md
Paste a SKILL.md. Add the folder name if you want the name check against it.
Ten ready skills for web projects
Our own examples, free to copy and adapt. Each one is a complete SKILL.md.
Accessibility review
Walks a component or page through labels, focus order, contrast and alt text, then lists fixes by severity.
---
name: accessibility-review
description: Reviews React, Vue or HTML UI for keyboard access, labels, focus, contrast and alt text. Use when the user asks for an accessibility or a11y check, or edits forms, dialogs or buttons.
---
# Accessibility review
1. List every interactive element in the files you were given.
2. For each one check: it is reachable with Tab, it has a visible focus style, and it has an accessible name (label, aria-label or text).
3. Check images: decorative ones get alt="", meaningful ones get a short description.
4. Check that text contrast meets WCAG AA (4.5:1 for body text, 3:1 for large text).
5. Check dialogs trap focus and return it to the trigger when closed.
Report findings as a table: element, problem, fix, severity (blocker, serious, minor). Fix blockers directly if the user agrees.
SEO meta check
Checks title, meta description, canonical, Open Graph and heading order in a page's head and body.
---
name: seo-meta-check
description: Checks a page's title, meta description, canonical URL, Open Graph tags and heading order. Use when the user asks for an SEO review or changes a layout, head component or page template.
---
# SEO meta check
For each page file:
- Title: present, unique, roughly 50 to 60 characters.
- Meta description: present, roughly 140 to 160 characters, matches the page.
- Canonical: absolute URL, points at the page itself unless it is a duplicate.
- Open Graph: og:title, og:description, og:image (absolute URL) and og:url.
- Exactly one h1, and no heading levels skipped.
Print a short pass/fail list per page and propose exact replacement tags for anything that fails. Do not invent claims for the description.
Changelog writer
Turns the commits since the last tag into a grouped, human-readable changelog entry.
---
name: changelog-writer
description: Writes a CHANGELOG.md entry from git history since the last tag, grouped into Added, Changed, Fixed and Removed. Use when the user asks for release notes, a changelog or a version bump.
---
# Changelog writer
1. Run `git describe --tags --abbrev=0` to find the last tag, then `git log <tag>..HEAD --oneline`.
2. Group commits into Added, Changed, Fixed, Removed. Drop merge commits and pure chores.
3. Rewrite each line for a user, not a developer: say what changed for them.
4. Add the entry at the top of CHANGELOG.md under a heading with the new version and today's date.
Ask before choosing the version number if it is not obvious.
React component scaffold
Creates a typed React component, a story or test file and an index export that follow the repo's existing patterns.
---
name: react-component-scaffold
description: Creates a new React component with TypeScript props, a test and an export, matching the repo's existing folder and styling conventions. Use when the user asks for a new component.
---
# React component scaffold
1. Look at two existing components in the same folder and copy their structure, naming and styling approach.
2. Create the component with a typed Props interface and no default export unless the repo uses them.
3. Add a test next to it that renders the component and checks one visible behaviour.
4. Export it from the nearest index file if the folder has one.
Do not add new dependencies. Run the type check and the new test before you finish.
Alt text audit
Finds images with missing, empty or filename-style alt text and drafts better descriptions.
---
name: alt-text-audit
description: Finds img and Image elements with missing, generic or filename-like alt text and drafts replacements. Use when the user asks about alt text, image accessibility or image SEO.
---
# Alt text audit
1. Search the source for <img and <Image elements.
2. Flag alt text that is missing, says "image" or "photo", or looks like a file name.
3. Decide if each image is decorative (alt="") or informative.
4. For informative images, draft alt text under 125 characters that says what the image shows in context.
Show a table of file, line, current alt, suggested alt. Apply changes only after the user confirms.
Responsive layout check
Reads layout code for fixed widths, overflow risks and missing breakpoints before they show up on a phone.
---
name: responsive-check
description: Reviews CSS, Tailwind or styled components for fixed widths, horizontal overflow and missing mobile breakpoints. Use when the user reports layout problems on phones or asks for a responsive review.
---
# Responsive layout check
Look for:
- Fixed pixel widths on containers wider than 360px without a max-width.
- Long words, URLs or code blocks that can push the page sideways (add overflow-wrap or overflow-x: auto).
- Grids and flex rows with no small-screen fallback.
- Images and videos without max-width: 100%.
- Tap targets smaller than about 44 by 44 CSS pixels.
List each issue with the file and line, then the smallest change that fixes it.
Env var audit
Cross-checks environment variables used in code against .env.example and flags secrets exposed to the browser.
---
name: env-var-audit
description: Compares environment variables used in code with .env.example and flags secrets exposed to client bundles. Use when the user adds config, sets up deployment or asks about env files.
---
# Env var audit
1. Find every process.env.X, import.meta.env.X and os.environ reference.
2. Compare with .env.example: list variables used but undocumented, and documented but unused.
3. Flag any secret-looking name (KEY, SECRET, TOKEN, PASSWORD) that carries a public prefix such as NEXT_PUBLIC_ or VITE_, since those reach the browser.
4. Never print real values from .env files.
Offer an updated .env.example with placeholder values.
Commit message writer
Reads the staged diff and writes a conventional commit subject and body.
---
name: commit-message
description: Writes a conventional commit message from the staged diff. Use when the user asks for a commit message or says to commit their changes.
---
# Commit message writer
1. Run `git diff --staged`. If nothing is staged, say so and stop.
2. Pick a type: feat, fix, refactor, docs, test, chore, perf or ci.
3. Write a subject under 72 characters in the imperative mood.
4. Add a short body only when the reason for the change is not obvious from the subject.
Show the message and wait for approval before running git commit.
Dependency update review
Reads a lockfile diff, names the major bumps and points at the changelog entries worth reading.
---
name: dependency-update-review
description: Reviews package.json and lockfile changes for major version bumps, new packages and licence changes. Use when the user updates dependencies or reviews a dependency pull request.
---
# Dependency update review
1. Diff package.json and the lockfile against the main branch.
2. List new packages, removed packages and every version change, marking major bumps.
3. For each major bump, open the package's changelog and summarise breaking changes in one line.
4. Note any new package whose licence is not MIT, Apache-2.0, BSD or ISC.
End with a short go / check first / hold verdict per package.
Landing page copy review
Checks a landing page's headline, proof and call to action for clarity, with rewrites that keep claims honest.
---
name: landing-copy-review
description: Reviews landing page copy for a clear headline, specific benefits, honest proof and one call to action. Use when the user asks for copy feedback on a homepage, landing page or pricing page.
---
# Landing page copy review
Read the page top to bottom and answer:
- Does the headline say what the product does and for whom, in under 12 words?
- Are benefits specific, or generic words like "powerful" and "seamless"?
- Is every number, review or logo real? Flag anything that cannot be verified.
- Is there one main call to action, repeated, with the same wording?
Give up to five rewrites, each with the original line and the suggested line. Never add claims the user has not confirmed.
Folder layout and a minimal file
Only SKILL.md is required. The scripts, references and assets folders are conventions from the spec; the agent reads them only when the instructions point at them.
A skill folder
The folder name and the name field must match. Keep links from SKILL.md one level deep.
Two fields and a body. This passes the spec and loads in Claude Code.
---
name: seo-meta-check
description: Checks title, meta description and canonical tags. Use when the user asks for an SEO review.
---
1. Open the page head.
2. Report missing or duplicate tags with fixes.
How an agent decides to load your skill
At startup only the name and description of every installed skill are read, roughly a hundred tokens each. The full body is pulled in when a request matches. That is why the description carries so much weight: it is the only thing the agent sees before choosing.
Write it as two parts. First what the skill does, in concrete verbs. Then when to use it, naming the inputs or phrases that should trigger it. 'Helps with SEO' is too thin; 'Checks title, meta description and canonical tags in HTML or JSX files. Use when the user asks for an SEO review or edits a page head' gives the agent something to match.
Portable fields versus Claude Code extras
Six keys are portable: name, description, license, compatibility, metadata and allowed-tools. Claude Code also reads extras such as when_to_use, argument-hint, disable-model-invocation, user-invocable, model, effort, context and paths, and ignores keys it does not know.
The catch is uploading. On claude.ai, through the Skills API or with the packaging script, any key outside the portable six is a hard error. The linter on this page flags those keys so you know which file will travel and which is Claude Code only.
How it works
Type a short name. The form lowercases it and swaps spaces for hyphens as you go.
Describe what the skill does and, in the second box, when it should be used. Both end up in the description line.
Add the step-by-step instructions as Markdown, plus any optional fields you need.
Copy the file or download SKILL.md, then save it in a folder that has the same name as the skill.
Tips
Put trigger words in the description, such as file types or phrases people actually type. That text decides when the skill loads.
Keep SKILL.md under 500 lines and move long reference material into separate files the skill links to.
Use disable-model-invocation for skills with side effects, such as a deploy, so they only run when you type the slash command.
If you plan to upload the skill to claude.ai or the API, stick to the six portable fields; other keys are rejected there.
Frequently asked questions
Where do I save a Claude Code skill?
Project skills go in .claude/skills/<skill-name>/SKILL.md inside the repository, so the whole team gets them. Personal skills go in ~/.claude/skills/<skill-name>/SKILL.md and work in every project on your machine.
Is the name field required?
The open Agent Skills spec requires it and says it must match the parent folder name. Claude Code is more lenient: if name is missing it uses the folder name for the slash command.
How long can a skill description be?
The spec allows 1 to 1024 characters. Claude Code appends any when_to_use text to the description in its skill listing, and that combined text is capped at 1,536 characters.
What is the difference between a skill and a slash command?
Claude Code merged them. A file at .claude/commands/deploy.md and a skill at .claude/skills/deploy/SKILL.md both create /deploy. Skills add a folder for supporting files and can be loaded automatically when relevant.
Does this tool send my skill anywhere?
No. Writing, linting and downloading all happen in this browser tab. Nothing you type is uploaded.