karero
UserOpen-source AI website builder skill suite for creating fast, accessible, SEO-ready Astro websites with Claude Code, Codex, or Antigravity.
Categories
Indexed Skills (30)
ai-seo
When the user wants to optimize content for AI search engines, get cited by LLMs, or appear in AI-generated answers. Also use when the user mentions 'AI SEO,' 'AEO,' 'GEO,' 'LLMO,' 'answer engine optimization,' 'generative engine optimization,' 'LLM optimization,' 'AI Overviews,' 'optimize for ChatGPT,' 'optimize for Perplexity,' 'AI citations,' 'AI visibility,' 'zero-click search,' 'how do I show up in AI answers,' 'LLM mentions,' or 'optimize for Claude/Gemini.' Use this whenever someone wants their content to be cited or surfaced by AI assistants and AI search engines. For traditional technical and on-page SEO audits, see seo-audit. For structured data implementation, see schema-markup.
copywriting
When the user wants to write, rewrite, or improve marketing copy for any page — including homepage, landing pages, pricing pages, feature pages, about pages, or product pages. Also use when the user says "write copy for," "improve this copy," "rewrite this page," "marketing copy," "headline help," "CTA copy," "value proposition," "tagline," "subheadline," "hero section copy," "above the fold," "this copy is weak," "make this more compelling," or "help me describe my product." Use this whenever someone is working on website text that needs to persuade or convert. For email copy, see email-sequence. For popup copy, see popup-cro. For editing existing copy, see copy-editing.
customer-research
When the user wants to conduct, analyze, or synthesize customer research. Use when the user mentions "customer research," "ICP research," "talk to customers," "analyze transcripts," "customer interviews," "survey analysis," "support ticket analysis," "voice of customer," "VOC," "build personas," "customer personas," "jobs to be done," "JTBD," "what do customers say," "what are customers struggling with," "Reddit mining," "G2 reviews," "review mining," "digital watering holes," "community research," "forum research," "competitor reviews," "customer sentiment," or "find out why customers churn/convert/buy." Use for both analyzing existing research assets AND gathering new research from online sources. For writing copy informed by research, see copywriting. For acting on research to improve pages, see page-cro.
image
When the user wants to create, generate, edit, or optimize images for marketing — blog heroes, social graphics, product mockups, profile banners, listing visuals, or brand assets. Also use when the user mentions 'AI image generation,' 'generate an image,' 'create a graphic,' 'product mockup,' 'hero image,' 'social media graphic,' 'banner image,' 'cover photo,' 'profile banner,' 'listing screenshot,' 'Flux,' 'Midjourney,' 'DALL-E,' 'GPT Image,' 'Ideogram,' 'Gemini image,' 'Canva,' 'Figma,' 'image optimization,' 'compress images,' 'WebP,' or 'OG image.' Use this for general-purpose marketing image creation and optimization. For paid ad image creative and platform-specific ad specs, see ad-creative. For video production, see video.
og-images
Generate branded per-page Open Graph (social share) cards for a website: a 1200×630 JPEG ≤300 KB for every page, rendered by a committed Python+Pillow script and wired so each page sets its own `image=` (with a default fallback) and the test suite proves the card exists at the right size. Use when building or auditing a site's share previews — "OG image", "og:image", "social share image", "share card", "WhatsApp/Slack/LinkedIn preview", "Twitter card image", "the picture when I share the link", "per-page OG images", "generate share images". For general marketing image creation/optimization use the `image` skill; this one is specifically the build-time, tested, per-page card generator for the suite's Astro starter.
schema-markup
When the user wants to add, fix, or optimize schema markup and structured data on their site. Also use when the user mentions "schema markup," "structured data," "JSON-LD," "rich snippets," "schema.org," "FAQ schema," "product schema," "review schema," "breadcrumb schema," "Google rich results," "knowledge panel," "star ratings in search," or "add structured data." Use this whenever someone wants their pages to show enhanced results in Google. For broader SEO issues, see seo-audit. For AI search optimization, see ai-seo.
search-console-insights
Pull and act on Google Search Console DATA for a verified site — the monitor-and-optimize step downstream of search-console-setup. Free GSC Search Analytics API (OAuth, read-only): where target keywords rank, striking-distance queries (pos ~8-20), and high-impression/low-CTR pages flagged for snippet/SERP investigation (title/meta rewrite only if the live-SERP check shows a snippet problem you control). Optional free add-ons: the live competitor Top-10 via a SERP API, and Bing Webmaster Tools as a Copilot/ChatGPT-visibility proxy. First use runs a guided onboarding for non-technical owners. Trigger phrases: "GSC insights", "Search Console data", "connect GSC", "onboard Search Console", "where do I rank", "top queries", "striking distance keywords", "quick SEO wins", "why is my CTR low", "which pages to optimize", "who ranks for", "competitor Top 10", "how do I rank on Bing", "Copilot visibility", "ChatGPT search visibility", "track my rankings over time", "weekly SEO report".
seo-audit
When the user wants to audit, review, or diagnose SEO issues on their site. Also use when the user mentions "SEO audit," "technical SEO," "why am I not ranking," "SEO issues," "on-page SEO," "meta tags review," "SEO health check," "my traffic dropped," "lost rankings," "not showing up in Google," "site isn't ranking," "Google update hit me," "page speed," "core web vitals," "crawl errors," or "indexing issues." Use this even if the user just says something vague like "my SEO is bad" or "help with SEO" — start with an audit. For building pages at scale to target keywords, see programmatic-seo. For adding structured data, see schema-markup. For AI search optimization, see ai-seo.
site-architecture
When the user wants to plan, map, or restructure their website's page hierarchy, navigation, URL structure, or internal linking. Also use when the user mentions "sitemap," "site map," "visual sitemap," "site structure," "page hierarchy," "information architecture," "IA," "navigation design," "URL structure," "breadcrumbs," "internal linking strategy," "website planning," "what pages do I need," "how should I organize my site," or "site navigation." Use this whenever someone is planning what pages a website should have and how they connect. NOT for XML sitemaps (that's technical SEO — see seo-audit). For SEO audits, see seo-audit. For structured data, see schema-markup.
astro-i18n-setup
Turn a new-website scaffold into a turnkey multi-language site: Astro i18n routing (clean default locale + prefixed others), self-referencing hreflang + x-default in the Base layout, i18n sitemap alternates, a language switcher, and the test-harness changes that keep the green-from-commit-1 gate honest across locales. Run at scaffold time when new-website Q4 = "two+ languages at launch", OR later to add a second language to a single-locale site whose default stays unprefixed (phased rollout). Trigger phrases: "multi-language site", "add i18n", "DE+EN site", "internationalization", "hreflang setup", "two languages at launch".
business-listings-setup
Post-launch: claim Google Business Profile, Bing Places, and category directories, then verify the `sameAs` profiles already in schema actually resolve. The action skill for E-E-A-T's Authoritativeness component (owned by `website-content-guide`): other pages linking to or citing you are one signal search and AI answer engines read as authority. Human-in-the-loop, same shape as `search-console-setup` — the agent drafts every value, the owner clicks. Trigger phrases: "claim my Google Business Profile", "Google Maps listing", "Bing Places", "business listings", "improve E-E-A-T", "authoritativeness is thin", "sameAs profiles".
double-knuth
Generic two-pass "Double-Knuth" review for ANY repo or file set: Pass 1 = correctness/bugs on the change (delegates to /code-review when a git diff exists, agent-based otherwise), Pass 2 = completeness + cross-file/doc consistency — the defect class a diff reviewer structurally cannot see (stale counts/enumerations, docs contradicting changed behavior, dead paths, orphaned files, contract drift). Read-only: returns a ranked BUG/RISK/NIT list with file:line + concrete fixes. Specialized versions take precedence: websites → website-review; this skill covers everything else (skill suites, scripts, tools, configs). Trigger phrases: "double knuth this", "double knuth the code", "double knuth the repo", "two-pass review", "consistency review", "did the docs drift", "review the whole repo, not just the diff".
independent-review
Domain-agnostic cross-model review gate: run a planning markdown (PLAN gate) or a branch/PR diff (DIFF gate) through INDEPENDENT external reviewers via scripts/independent_review.sh — the standard pair (Codex + your signed-in ollama-cloud model) runs automatically; Antigravity/Gemini only on explicit opt-in, its credits are scarce. Consolidates a ranked BUG/RISK/NIT list and BLOCKS until every BUG is fixed, refuted, or owner-deferred (only a BUG the change did not introduce), and every RISK/NIT is fixed, refuted, or owner-waived; first use runs a guided onboarding wizard. Use BEFORE building from any non-trivial plan, BEFORE merging any non-trivial PR, and whenever asked for a "codex review", "gemini review", "antigravity review", "agy review", "adversarial review", "cross-model review", "independent review", "get a second model to review", "review before I merge", "which review tool should I use", or to "set up AI code review" / "set up codex, ollama, or antigravity for review".
internal-link-audit
Internal-linking tool for an Astro site built with the new-website kit. Builds the site's inbound-link graph from dist/ and reports which pages are ORPHANED (in the sitemap but no internal link points at them), THIN (a single inbound link, no contextual in-body link), or DEEP (more than ~3 clicks from home), then suggests WHERE to add the missing links using `site-architecture`'s internal-linking strategy. The judgment-side complement to the offline `tests/orphans.spec.ts` gate. Run before a release, after adding pages, or when GSC reports orphaned/low-coverage pages. Trigger phrases: "internal link audit", "orphaned pages", "are any pages orphaned", "internal linking", "which pages link to nothing", "fix orphan pages", "improve internal links", "cross-link the comparison pages".
keystatic-setup
Add Keystatic — a git-based CMS from the Keystone team — to a new-website Astro scaffold, so a non-technical person can edit content through a UI while the data still rests as Markdown in the GitHub repo. Wires LOCAL storage mode (edit in the dev server, commit/push); documents the GitHub cloud-mode upgrade for browser editing. Run ONCE, at scaffold time, when new-website Q3 = "a non-technical person edits content". Trigger phrases: "add a CMS", "Keystatic", "non-technical editor", "client edits content", "git-based CMS".
new-website
Orchestrates building a NEW website end-to-end, from insights to launch-ready and handoff-ready. Self-contained: it runs the stack decision interview, sequences the website-* skills + existing marketing skills in order, and scaffolds the project from its own templates/ (Astro starter overlay + full QA test suite + GDPR privacy draft + owner docs + permission allowlist), copying the bundled skill set into the project's skills dir (full copy list in §3) so the repo is self-contained for a third party. Default stack Astro → GitHub → Cloudflare Pages. Use at the very start of any new site. Trigger phrases: "new website", "start a new site", "scaffold a website", "spin up a site", "build a new website", "set up a new web project", "website starter", "which stack for this site".
outgoing-link-audit
Liveness audit of every OUTGOING (external) link on an Astro site built with the new-website kit. Builds the site, extracts each external href from dist/, fetches it, and classifies it OK / REDIRECT / REBRAND / DEAD — flagging links that 404, time out, or now redirect to a different domain (a rebrand), with the source page and a suggested fix. This is the network-dependent complement to the offline `tests/links.spec.ts` guard (which only blocks already-known-dead domains from regressing). Run it about once a month, or before a release/launch. Trigger phrases: "audit outgoing links", "check external links", "are our links still live", "monthly link check", "any dead links", "did any linked site rebrand", "link rot check", "review outgoing links".
search-console-setup
Post-launch: register the LIVE site with Google Search Console and Bing Webmaster Tools, verify ownership, submit the sitemap, and turn on IndexNow so Bing/Yandex get pinged the moment content changes. For a Cloudflare-hosted Astro site: GSC Domain property verified by a Cloudflare DNS TXT record + submit `sitemap-index.xml`; Bing the easy way via "Import from Google Search Console" (auto-verifies + pulls the sitemap); IndexNow by flipping ONE toggle — Cloudflare Crawler Hints — no key file to host. Account creation + the DNS record are human actions the agent drafts but can't click. Trigger phrases: "set up Google Search Console", "Search Console", "GSC", "Bing Webmaster Tools", "submit my sitemap", "register the site with Google", "verify site ownership", "enable IndexNow", "Crawler Hints", "get indexed", "submit the website to search engines".
seo-reposition
Reposition a LIVE site whose category/keyword phrasing is not ranking or is being mis-filed by Google/LLMs into unrelated concepts (GSC shows brand-only demand; category pages pull ~0 non-brand impressions). Method proven on two sites: SERP trap-test every candidate phrase → find the winnable wedge → rewording plan with a target-vs-copy rule → GUARD TESTS FIRST (red→green ratchet) → phased gated implementation → ship → schedule a predicted-vs-actual grading run. Review at the plan and PR gates is the owner's choice (the phase gates state the options). Trigger phrases: "reposition the site's SEO", "our keywords collide with X", "we're not ranking for our category", "Google files us under the wrong thing", "trap-phrase audit", "rewording plan", "find our SEO wedge".
website-content-guide
Create and maintain a new site's CONTENT_GUIDE.md and BRAND.md — Tone of Voice and EEAT (Experience/Expertise/Authoritativeness/Trust) signals — so every page hangs off one source of truth for HOW it says it. Reads positioning from POSITIONING.md (owned by website-positioning, which runs first); it does not redefine positioning. Use at the start of a new site (step 3 of the new-website pipeline, after website-positioning), before writing page copy, and whenever reviewing/editing copy for voice. Pairs with the tone test (tests/tone.spec.ts) which hard-enforces the voice rules. Trigger phrases: "content guide", "tone of voice", "brand voice", "is this on brand", "EEAT", "E-E-A-T", "write the content guide", "set up the brand doc", "review the copy", "does this sound like AI".
website-design-system
The visual build standards for a new site: mobile-first responsive graphics (WebP/AVIF, sized-to-display, srcset, lazy-load, descriptive alt, no layout shift), dark mode (CSS-variable theme tokens + a no-FOUC script + WCAG AA contrast in BOTH themes), and the brand/theme token block that BRAND.md mirrors. Use when building or reviewing layout, images, theming, or BRAND.md (step 5 of the new-website pipeline). Contrast is enforced by a11y.spec.ts (light+dark). Trigger phrases: "dark mode", "theme toggle", "responsive images", "mobile optimization", "image optimization", "WebP", "layout shift", "CLS", "design system", "theme tokens", "brand colors", "BRAND.md".
website-motion
OPTIONAL polish layer: two motion effects that make a long marketing page feel authored rather than dumped — a count-up on hero stat numbers, and a 12px rise-and-fade reveal on section headings — plus the reduced-motion contract, the a11y gate change, and the motion.spec.ts that keep them from silently costing a visitor access to content. Not part of the default new-website build: add it only when a site has a long scrolling homepage and real numbers worth reading. Also carries the one-line hero-height check (a binding min-height:100vh hides the next section at every screen height). Trigger phrases: "add some motion", "scroll reveal", "fade in on scroll", "animate the stats", "count-up numbers", "animated counter", "the page feels flat", "eye candy", "make the homepage less static", "prefers-reduced-motion", "does the animation break accessibility".
website-permissions
Cut the number of permission prompts on a new-website repo to near-zero for the routine build loop, while keeping destructive actions gated. Installs the bundled `.claude/settings.json` allowlist into the project, explains the allow/deny model (npm / astro / playwright / git commit / gh-read / image tools / the link script are pre-approved; `rm -rf`, `git push --force`, `git reset --hard`, and any `wrangler/gh … delete` stay prompted), and safely EXTENDS the allowlist from the commands you keep approving — narrowly, never with a blanket wildcard. The allowlist travels with the repo, so a handoff party also gets the quiet build loop. Trigger phrases: "reduce permission prompts", "too many permission prompts", "stop asking me to approve", "set up permissions for this site", "fewer prompts", "allowlist this repo", "why does it keep asking me".
website-positioning-check
Give an existing website a fast, fresh-eyes positioning check: can the right visitor tell what is on offer, for whom, and why to believe it? Read-only and concise — a one-screen Clear / Blurred / Broken verdict, the single biggest blur, and the three highest-leverage fixes. Use whenever someone asks if a site's offer is clear, differentiated, outcome-led, too technical, or consistent between homepage and offer pages — even without the word "positioning". Trigger phrases: "is our positioning clear", "fresh eyes on the homepage", "what are we actually selling", "is it obvious who this is for", "we sound too technical", "homepage and services page disagree", "positioning sanity check", "does the site make sense to a stranger". Do not use for developing positioning from scratch (website-positioning), a full copy rewrite (copywriting), an SEO audit, or the pre-launch website-review.
website-positioning
Work out a new site's POSITIONING before any SEO or content — what you offer, for whom, and the market category it sits in — using April Dunford's five-component framework, captured in POSITIONING.md and threaded through every page's title, description, H1 and schema. Owns the positioning spine; enforced by tests/positioning.spec.ts (a hermetic per-page string test, sibling to the tone test). Use FIRST on a new site (step 2 of the new-website pipeline), before website-content-guide, before page copy, and whenever the offer or audience shifts. Trigger phrases: "positioning", "value proposition", "what are we offering", "who is this for", "market category", "positioning statement", "Dunford", "frame the offer", "how do we describe ourselves".
website-qa
The pre-launch QA gate for a new site: run the basic tests (a11y light+dark + seo + navigation + anchors + orphans + images + tone + positioning + email + links), fix to green, then handle technical SEO / performance — ask the user to run a Lighthouse / PageSpeed Insights test and act on First Contentful Paint (FCP) and Largest Contentful Paint (LCP). Use before launch (steps 7–8 of the new-website pipeline) and after any code/copy change. Delegates Core Web Vitals / crawl depth to seo-audit. Trigger phrases: "run the tests", "QA the site", "is the site launch ready", "a11y check", "accessibility test", "Lighthouse", "PageSpeed", "FCP", "LCP", "page speed", "Core Web Vitals", "performance check", "are the tests green".
website-review
The Double-Knuth review for a site — a two-pass correctness + cross-file consistency audit run at the END of a build (pre-launch) and after ADDING or substantially editing a page. Pass 1 = bugs/correctness (delegates the diff to /code-review); Pass 2 = completeness + route/URL/SEO/config/email/docs consistency against the site contract. Read-only: returns a ranked BUG/RISK/NIT list with file:line + fixes. Prerequisite: website-qa green. Also owns the "review depth" decision for website work — when this free default suffices vs. an owner-approved single external reviewer for genuinely higher-stakes changes (its "Review depth" section has the rule). Trigger phrases: "double-knuth", "double knuth the site", "review the site", "site review", "final review before launch", "review this page", "did adding the page break anything", "consistency check the site", "audit the site code", "how much review does this need", "do I need a second opinion on this", "should I use independent-review for this".
website-seo-geo
The on-page SEO + GEO contract for a new site: exact metadata limits (title 50–60 chars, meta description 140–160 with a 120 floor), og:title/og:description == title/desc, twitter inherits OG, clean canonical == og:url, required JSON-LD schema, and llms.txt for AI answer engines. Use when building or reviewing a page's <head> / metadata (step 5 of the new-website pipeline), or when a title/description is too long or tags are out of sync. Enforced by the seo.spec.ts check in the new-website test suite. Delegates depth to ai-seo (GEO) and schema-markup. Trigger phrases: "SEO metadata", "title too long", "meta description length", "og tags", "twitter card", "canonical", "is my SEO set up", "llms.txt", "GEO", "head tags", "structured data on this page".
website-team-setup
Turn a one-owner new-website repo into one several people and AI assistants (Codex, Claude Code) can work on at once without overwriting each other: invite collaborators, set the repo settings, prove the CI workflow starts on its own (the fix for a silent one is bundled), block direct pushes to `main`, connect Cloudflare Pages to GitHub without the known traps, write rights, merge rule and who publishes live into `AGENTS.md`, hand the team a one-page guide. Run once, when a second person joins. Use it whenever the user mentions a colleague, client or second assistant joining a site repo, inviting someone to GitHub, "Update branch", pull requests not running CI, or connecting Cloudflare to the repo, even without the word "team". Trigger phrases: "set up the team", "my colleague will work on the site", "invite a collaborator", "block pushes to main", "CI is not running on pull requests".
website-testimonials
Encode customer / attendee testimonials as proper schema.org `Review` JSON-LD AND render the "What people say" UI from ONE typed source of truth (`src/data/testimonials.ts`). Individual Review nodes only — author + 5/5 reviewRating + reviewBody + inLanguage + itemReviewed pointing at the SPECIFIC thing reviewed (Event / Product / Service), never a fabricated org-wide AggregateRating. Use when adding quotes, testimonials, social proof, ratings, or star reviews to a site built with the new-website kit (pipeline step 5, alongside `website-seo-geo`). Delegates other schema types to `schema-markup`. Trigger phrases: "add testimonials", "customer quotes", "attendee feedback", "review schema", "star ratings", "social proof section", "encode the quotes", "schema.org Review", "what people say section".
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.