Build

Before you start: read this whole install prompt, tell me in a few lines what this skill does and what installing it involves, and wait for my go-ahead before you do anything else. Prerequisites: none for the install itself: no account, no API key, no paid service, and nothing else to install first. For using the skill afterwards, read this first: its three bundled tools need only Python 3 (standard library only, nothing to pip-install). The work around them can involve, only when a step actually needs it and only as disclosed in point 2: a real browser for screenshots, or Playwright via npx (a first Playwright run may download Chromium, about 150 MB); Node for optional logic tests (node --test); and, if I choose to deploy, my own hosting account on Netlify, Vercel, Cloudflare Pages or GitHub Pages — I create it and log in myself, you never ask for or type my password, free tiers are the default in the skill, and any domain, paid tier, form service, Stripe or Supabase cost is a separate choice I make from the spec, never a requirement of this skill. I provide the real content myself: my words, photos, prices and proof — the skill forbids inventing testimonials, counts or claims, and anything missing is marked, not made up. Install "build" for me. It takes a non-technical owner from "I want a website or app that does X" to a live, working product in six stages: (1) clarify and write a one-page plain-English spec and get a yes; (2) pick the simplest stack that works (plain HTML/CSS first, hosted form or payment services instead of a server, a static generator only past about 10 content pages, Next.js/Vite + Supabase on Vercel only when accounts and shared data are truly needed); (3) commit to a design direction before any code — a direction worksheet, named type/color/space/shape/motion tokens as CSS custom properties, and an anti-pattern check, proven with contrast numbers; (4) build in 3 to 8 small verified slices, scaffolding a site/ project, running a local preview, checking after each slice, saving git save points, and writing a failing test before any logic that calculates, validates, filters or transforms; (5) QA in a real browser at 375, 768 and 1440, fix in severity order, re-verify, two full rounds maximum; (6) ship only after asking me, verify the live site, and hand off a plain-English README note. Three checklists (design, qa, ship) and three Python tools come with it: serve.py (local preview server), sitecheck.py (site crawler/checker) and contrast.py (WCAG contrast). Repository: https://github.com/Jakeschincariol/master-skills (the skill is the whole skills/build/ folder at the pinned commit: SKILL.md plus its checklists/ and tools/ folders, 8 files) Pinned version: install the code at commit b5b43e44f0a976ad25bda5095a94c161aab2f086 exactly. Do not substitute a newer version. If this commit is unreachable, stop and tell me. 1. Clone https://github.com/Jakeschincariol/master-skills into a temporary folder, check out commit b5b43e44f0a976ad25bda5095a94c161aab2f086, and copy the skills/build/ folder from that checkout. Then compare every file in the folder with the fingerprints recorded for this listing on 2026-10-19: [FINGERPRINTS] - SKILL.md: SHA-256 e738a0f7fc1ee270e0a96756c5c6bdf8e3610e365f3ecb58a01788f861459340 - checklists/design.md: SHA-256 9e10e7ea57ee639c93786198584b023fea1c92ca86e8dc4c9647858f32b45f5b - checklists/qa.md: SHA-256 96dec757992214448445e2a3ab0de91a6e7ce0fd3a0b491e58fa6f4fb8e4d4c9 - checklists/ship.md: SHA-256 ee77c6cb0a9ee772d605874c79320191b59c0ac093f2a8a54f12d65c804be6f6 - tools/contrast.py: SHA-256 bddb2ef833623adc1cb716ea10868b338108324aa898176156dc3e56c74ea93c - tools/serve.py: SHA-256 88a0f6ce916d41ea855c232644e53515b80136143b0684b93009fe767a48c091 - tools/sitecheck.py: SHA-256 8f30c94fb77defa7cb09990c4fb4ec578507d5d95594ec18a5bc0c7c5ac5fe6f - tools/test_build.py: SHA-256 bb0847daa5e00d2f529a98f9490dd1085e1f58033586031ff877b146279fcb5a If a file does not match, it changed since the listing was prepared: do not install it yet, tell me what you found and let me decide. 2. Read SKILL.md in full, read all three checklists in checklists/ (design.md, qa.md, ship.md) and read all four Python files in tools/ (contrast.py, serve.py, sitecheck.py, test_build.py), and tell me in plain words: what the skill does when used, which services it connects to, whether it reads or sends any personal information or keys, and anything that seems unusual. Stop on any red flag and tell me before going further. Confirm these points from the files: - The skill folder holds 8 files only: SKILL.md (17,528 bytes), three checklists in checklists/ (design.md 6,458 bytes, qa.md 4,825 bytes, ship.md 3,693 bytes) and four Python files in tools/ (contrast.py 15,906 bytes, serve.py 13,864 bytes, sitecheck.py 63,123 bytes, test_build.py 15,520 bytes). The skill is self-contained in its own folder: SKILL.md only ever calls the tools and checklists sitting next to it, sitecheck.py imports serve.py from its own tools/ folder when it serves a folder itself, and test_build.py imports contrast, serve and sitecheck from that same folder. It needs no file from elsewhere in the repository — not the other two skills (edit, virality), not the README, not the plugin files. All four Python files use the Python 3 standard library only. - Nothing is sent anywhere during installation itself; the only download at install time is the skill folder from GitHub at the pinned commit. No script is run during installation, no key is asked for, and there is no telemetry in the folder. The tools never read environment variables, API keys, passwords or credential files: SKILL.md and checklists/ship.md say the opposite — never ask for or type my password, secrets never go in front-end code, and any API key a project needs lives in the host's environment settings, set by me, never in HTML/JS or the git repo. - What leaves this machine at use time, disclosed here before it ever happens — using the skill is a separate step that only starts when I ask you to build or check a site: (a) contrast.py never touches the network: it computes WCAG ratios locally from colors or from a CSS file I point it at, and only reads that file. (b) serve.py is a local preview server: by default it binds 127.0.0.1 only (port 8000 first) and serves the site/ folder to browsers on this machine, with no-cache headers, byte ranges and my 404.html; with --lan it binds 0.0.0.0 instead, so anyone on the same Wi-Fi can open the site at the printed LAN address while it runs — that is a local-network exposure, not an internet send, and it only happens if that flag is used; --open additionally opens the local URL in my default browser. (c) sitecheck.py crawls with plain GET/HEAD requests (Python urllib, User-Agent "sitecheck/1.0.0 (+https://github.com/Jakeschincariol/master-skills)", no body, no keys): on a local folder it starts serve.py on 127.0.0.1 itself and every request stays on this machine; on a URL I give it, it fetches that site's same-origin pages and assets (default depth 3, limit 100 pages) plus a /favicon.ico check, so that site's server sees ordinary page requests from my address; only with --external does it also send GET/HEAD requests to every external link and asset URL found in the site — without --external, external URLs are counted and skipped, never contacted. It does not run JavaScript and it never submits forms. --report FILE or --json writes its report locally. (d) test_build.py is the tools' own test suite, not part of the normal workflow: if it is ever run, it works only against temporary folders and servers it starts on 127.0.0.1, and runs the sitecheck.py CLI as a local subprocess. (e) Building a site writes files locally — the project layout (site/: index.html, styles.css, app.js and logic.js, img/, fonts/, 404.html, favicon.svg; tests/; README.md) — and uses local shell commands: python3 tools/serve.py, python3 tools/sitecheck.py and python3 tools/contrast.py above, git init once plus git add -A / git commit after each slice (save points, local only, no remote unless a deploy route below adds one), and node --test tests/ for logic tests when Node is present (or a local tests.html page when it is not). (f) Browser QA: with a browser tool, screenshots at 375x812, 768x1024 and 1440x900 of the local preview or, after deploy, of the live URL; without one, npx playwright screenshot fetches those same URLs, npx downloads the Playwright package if it is missing, and checklists/qa.md warns that a first run may need npx playwright install chromium, a download of about 150 MB — tell me before running that. (g) Ship, only after you ask me and I say yes, because it publishes to the public internet: I create and log into my own hosting account myself, then exactly one deploy route runs and uploads the whole site/ folder — with my real content, photos and prices in it — to the host I chose: npx netlify-cli deploy --dir=site --prod (Netlify), npx vercel --prod (Vercel), npx wrangler pages deploy site (Cloudflare Pages), gh repo create --public --source=. --push plus enabling Pages (GitHub Pages: the project code is pushed to a public GitHub repo), or no upload from you at all: a local zip of site/ that I drag-and-drop into the host myself. Each npx route also downloads that host's CLI package if it is missing. A custom domain, if I add one, means DNS records I set at my registrar. After deploy, verification sends what point (c) and (f) describe against the live URL, plus one real test form submission: that submission sends the test entry to wherever my form is wired to go. (h) Stack choices the spec can add, each my decision and each receiving data only because the finished site uses it, never because the bundled tools do: a form service (Netlify Forms via data-netlify="true", or Formspree) receives my visitors' form submissions; Stripe Payment Links or Checkout (hosted by Stripe, never card fields built by the skill) receives a visitor's payment when they pay; Supabase (auth and Postgres) and Vercel hosting only for a real app with accounts and shared data; a static generator (Astro or Eleventy) only for a blog or content site past about 10 pages. Fonts: Google Fonts with display=swap and a preconnect, or self-hosted woff2 — if Google Fonts is chosen, a visitor's browser fetches the fonts from Google when it opens the finished site. (i) The "Credits and going deeper" table at the end of SKILL.md names four OPTIONAL third-party skills that are not part of this install and not needed to use build (impeccable via npx impeccable install or a plugin marketplace add, Anthropic's frontend-design via a plugin install, gstack via git clone https://github.com/garrytan/gstack.git into ~/.claude/skills/gstack followed by running its ./setup script, and superpowers via a plugin install): do not run any of those during this install or as part of using build; if I ever ask for one separately, it would download — and for gstack, execute — third-party code, and we would vet it first. - Do not run any of the four Python files during this install, do not start the preview server, do not crawl any site, do not scaffold a project, do not install Playwright, Node packages or any deploy CLI, and do not deploy or publish anything: all of that is use, later, only when I ask for a site. 3. When I say "yes, install", install it as a skill: copy the whole build folder into the agent's skills directory, in a folder named "build", keeping all 8 files (SKILL.md at its root, the three checklists in its checklists/ subfolder and the four Python files in its tools/ subfolder). A manual clone followed by copying the skills/build folder into ~/.claude/skills/ is the route described here; any other route is fine only as long as every installed file matches its fingerprint. 4. Verify with no network calls: frontmatter valid (name: build), all 8 files in place with matching fingerprints. Do not run contrast.py, serve.py, sitecheck.py or test_build.py to verify. 5. Report what was installed, where, and what I still need to do myself (for example: bring the idea and the real content — words, photos, prices, proof — and answer the 3 to 5 spec questions and approve the spec and the design direction; create and log into my own hosting account myself if I deploy, and decide the host, any custom domain and any paid tier myself; set any API key a project needs in the host's environment settings myself, never in front-end code; choose any form service, Stripe or Supabase route from the spec myself, knowing its data goes there as disclosed above; using the skill is a separate step that only starts when I ask for a site, and the use-time sends disclosed above happen only then, on the route that runs). GitHub is optional: if I have a GitHub account or the gh CLI, you may use it; otherwise public access is fine. Never require it unless it's in the prerequisites above. Rules: don't touch anything outside the temp folder and the install target. If anything looks off, stop and ask me.