Convert an extract-design-system output bundle (a .design_systems/<domain>-YYYYMMDD/ folder with DESIGN.md, AGENTS.md, COMPONENTS.md and DTCG tokens) into a self-contained, auto-triggering per-brand Claude Code agent skill that later agents use to build pages native to that brand. Use whenever the user has run extract-design-system or points at a .design_systems/ bundle and wants to reuse it — "turn this design system into a skill", "make a skill from the extracted design system", "convert .design_systems/<x> into an agent skill", "package this bundle as a skill", "generate a <brand> design-system skill", "I extracted a design system, now make it easy to reuse". Runs a bundled Node worker that validates and stages the skill; Claude authors only the generated trigger description. Emits a validated .claude/skills/<brand-slug>-design-system/ folder via Write/Edit.
Extract a website's FULL design system — tokens AND a curated component catalog (anatomy, variants, hover/focus states, section patterns) — into a bundle a coding agent consumes to build new pages that are native to the source brand. Superset of extract-design-md: use THIS skill when the goal is to build/generate pages that match the source site's components ("clone the design system", "extract components from <url>", "make new pages that look like <site>", "same buttons/cards/sections as <site>"); use extract-design-md when only a DESIGN.md token spec is wanted. Outputs .design_systems/<domain>-YYYYMMDD/ with DESIGN.md + component catalog + reference snippets + section patterns + DTCG tokens + an emitted eval harness. Fixes the "same skin, different skeletons" failure of token-only extraction.
Extract a website's design system into a DESIGN.md file (the google-labs-code/design.md format). Use this whenever the user gives a site URL and wants to capture, reverse-engineer, clone, or document its visual identity — colors, typography, radius/spacing scales, components, and brand feel. Triggers on phrasings like "extract the design system from <url>", "make a DESIGN.md from <site>", "get the design tokens off <site>", "what's the color palette / fonts on <site>", or "I want my UI to look like <site>". It samples a few real pages with playwright-cli, reads CSS custom properties + computed styles (precise, cheap), takes light screenshots for prose, and validates with the official linter. Prefer this over eyeballing a screenshot whenever the goal is a reusable design spec.
Write or update a session handoff doc that lets a future session (Claude or human) resume work without re-reading the whole transcript. Use this skill whenever the user asks to "write a handoff", "create a handoff doc", "update the handoff", "write a doc so the next session can continue", "session handoff note", "hand this off", or points at a path and says to capture where things stand. The user only needs to give the destination file path — the content is distilled from the current session. Do NOT use for general project documentation, READMEs, API docs, code comments, or changelogs.
Generate images (featured images, illustrations, diagrams, test images, blog visuals) using Codex CLI's built-in $imagegen skill, triggered through the codex plugin or codex CLI. Use this skill whenever the user asks to generate, create, or make an image, picture, illustration, featured image, thumbnail, or visual asset — including "generate an image of...", "create a featured image for this post", "make me an illustration", "$imagegen", "use codex to generate an image", or "image for this blog post". Also use when the user wants image variants or wants AI-generated artwork saved into the project. Do NOT use for screenshots, charts rendered from data, ASCII diagrams, or editing existing images.
Convert a full WordPress plugin requirements.md (multiple user stories, edge cases, settings, cross-cutting features) into a complete Codex /goal-ready project — goals-plan.md, root scaffold (.wp-env.json, package.json, AGENTS.md, plugin bootstrap, run-goals.sh, protocols), and a layered goals/ tree (foundation, per-US, non-US, integration). The full-workflow counterpart to wp-spec-to-goal — that handles single-goal vague specs; this handles multi-goal full requirements. Probes the repo first to skip clarifications the filesystem already answers (slug, namespace, WP/PHP versions). Asks remaining clarifications in ≤3 rounds. Supports phased (checkpoint after plan) or one-shot mode. Detects an existing goals-plan.md and offers to resume from Phase 2. Supports extend mode — on a completed project, appends new goals and writes only new goal folders without disturbing what shipped. Codex-only outputs — never references Claude Code or .claude/.
Convert a WordPress plugin or feature idea (even a vague one) into a Codex /goal-ready bundle — GOAL.md, VERIFY.md, PROGRESS.md inside goals/<slug>/ — with wp-env + playwright-cli + wp-eval verification baked in. Asks clarifying questions in focused batches (each with options + recommendation + reasoning), reaches 95% confidence, optionally scaffolds a missing plugin folder + .wp-env.json + package.json + AGENTS.md, and emits a tailored /goal command. For new WP plugin or feature work, not bug fixes or non-WordPress projects.
Ask clarifying questions before executing tasks. Use this skill whenever the user says "ask me questions first", "clarify before doing", "ask before you start", invokes /ask, or wants Claude to gather requirements through Q&A before taking action. Also trigger when the user provides a task prefixed with "ask:" or says things like "I need help figuring out how to..." or "help me think through...". This skill ensures nothing is assumed — Claude asks until 95% confident, then executes.