Preflight

Documentation

Claude Code skills

A skill is a folder with a SKILL.md in it — frontmatter tells Claude what the skill is for, the body is the instructions it follows. They turn "how we do this here" into something that survives the person who knew it. Three of ours are below, ready to download.

The skills

.claude/skills/
├── site-proof/SKILL.md
├── add-template/SKILL.md
└── deploy/SKILL.md

site-proof

Proofs a site before you do the work. Finds missing pages, broken and wrongly-sized images, stub pages, absent robots.txt / 404 / sitemap, the noindex state, and heading and metadata problems — then reports and stops, so a human decides what is in scope. Ships a stdlib-only Python checker inside the skill; no dependencies to install.

Download SKILL.md

add-template

Adds a preset checklist to the app. Knows the data shape, that items must be imperative and checkable, that the n field is the reason rather than the instructions, and to syntax-check before trusting the result.

Download SKILL.md

deploy

Ships and then proves it shipped. Knows the project is direct-upload, that a 200 is not evidence, and that a parse error in the templates file blanks the app silently rather than erroring.

Download SKILL.md

Install them

A skill is just a file on disk. Claude Code looks in two places: .claude/skills/ inside a project, and ~/.claude/skills/ for every project. Put the file in either and it works — no install step, no restart, nothing to register.

For every project

mkdir -p ~/.claude/skills/site-proof
curl -fsSL https://preflight.getonnet.cloud/skills/files/site-proof.md \
  -o ~/.claude/skills/site-proof/SKILL.md

For one project only

Same thing, relative to the repo — commit it and your whole team gets it:

mkdir -p .claude/skills/add-template
curl -fsSL https://preflight.getonnet.cloud/skills/files/add-template.md \
  -o .claude/skills/add-template/SKILL.md

Both at once

for s in site-proof add-template deploy; do
  mkdir -p ~/.claude/skills/$s
  curl -fsSL https://preflight.getonnet.cloud/skills/files/$s.md \
    -o ~/.claude/skills/$s/SKILL.md
done

Project skills win over personal ones when both define the same name. The deploy skill is specific to this project — read it before pointing it at something else; the published copy has our account ID stripped out.

Using them

Start Claude Code in the project and describe the task — "is this site ready to launch?". The matching skill loads on its own, which is why the description line matters so much. You can also call one by name: 

/site-proof
/add-template
/deploy

To check what got picked up, ask Claude which skills it can see.

Writing your own

Create .claude/skills/<name>/SKILL.md:

---
name: my-skill
description: One line on what this does and when to use it.
---

# What to do

Steps, rules, gotchas. Concrete beats abstract.

Two things matter more than the rest

  1. The description is the trigger. Claude reads descriptions to decide which skill applies, so describe when to reach for it, not just what it does. ✗ "Template utilities" ✓ "Add a checklist template. Use when the user wants a new preset list."
  2. Write down what went wrong before. The useful half of both skills here is the gotchas — that .assetsignore does nothing on Cloudflare Pages, that a syntax error in the templates file blanks the app without an error. Those are the things a fresh reader cannot infer from the code, and they are what stops the same afternoon being lost twice.

Skills can ship helper scripts alongside SKILL.md and reference them by relative path, so anything you'd otherwise paste into a chat can live in the repo instead.

← Back to the checklists