How the AI landing-page builder works in this LMS — the json-render → Puck pipeline that lets creators generate a full landing page from a sentence and then refine it by hand in the Puck editor. Use this skill whenever the task touches AI page generation, the "Generate with AI" button, the json-render catalog/spec/bridge, the Puck landing-page blocks, or the /api/landing/generate route — including adding a new block type, debugging a generated page that renders blank/crashes, changing what the AI is allowed to emit, fixing OpenAI structured-output schema errors in this area, or regenerating the puck-fields manifest. Reach for it even when the user just says "the landing page generator", "the AI page thing", or names one of the lib/json-render files, since the pipeline has several non-obvious invariants that are easy to break without it.
Operate any GitHub Projects (v2) board by name — add issues/PRs, find existing items, set Status/Priority/Size or any single-select field — without hardcoding field or option IDs. Use whenever the user asks to move an item on a project board ("move
Discover the current repo's GitHub-workflow facts — repo name, authenticated gh user, project board, PR template, Slack channel, branch/commit conventions, build/test commands — and cache the non-discoverable ones in <repo-root>/.claude/gh-workflow.config.json so they're asked at most once per repo. Use at the start of any GitHub workflow (work-issue, ship-pr, gh-board rely on it), or when the user asks "what conventions does this repo use", wants to change a saved board/Slack/reviewer setting, or a workflow skill needs a config value it doesn't have.
Read a GitHub issue and produce a posted plan of attack — gather the issue with its comments and references, survey the code it touches (read-only), author a short plan (root cause, approach, risks, test plan), then assign the issue, move it to In Progress on the board (if configured), and post the plan as the issue comment teammates read. Use when the user asks to "plan this issue", "read
Take an implemented branch to a reviewable pull request — author a template-compliant PR body with a QA script, open it as a draft with labels/milestone/assignee mirrored from the issue, link it to the project board, flip it to ready only when it's genuinely reviewable, announce it on Slack with a reviewer mention (if Slack is connected), and post the final close-out comments on the PR and its issue once it's approved and merged. Use when the user asks to "open a PR for this branch", "ship this", "mark the PR ready", "announce this PR on Slack", or says a PR was merged and wants it closed out ("it's merged", "close out
Produce visual proof of a UI change and post it to the pull request — "before" screenshots captured while the code is still untouched, a recorded GIF of the changed flow, matching "after" screenshots, and the private-repo browser-upload dance to attach them as a PR comment. Use whenever a change touches anything a user can see or click (components, pages, styles, client-side behavior) and a reviewer needs visual evidence, or when the user asks to "record a GIF of this change", "take before/after screenshots", or "post the screenshots to the PR".
End-to-end GitHub issue workflow, repo-agnostic — read an issue, plan it, move it to In Progress on the project board (if one exists), implement it with efficient-fable orchestration, verify UI changes with a recorded GIF, open a template-compliant PR set to In Review with labels and milestone, and announce it on Slack for review (if connected). Supports extra skills as +args (e.g. "/work-issue <url> +shadcn +animate"). Use whenever the user pastes a GitHub issue URL or issue number and wants it worked on — "work on this issue", "pick up
Use when the user wants to design, redesign, shape, critique, audit, polish, clarify, distill, harden, optimize, adapt, animate, colorize, extract, or otherwise improve a frontend interface. Covers websites, landing pages, dashboards, product UI, app shells, components, forms, settings, onboarding, and empty states. Handles UX review, visual hierarchy, information architecture, cognitive load, accessibility, performance, responsive behavior, theming, anti-patterns, typography, fonts, spacing, layout, alignment, color, motion, micro-interactions, UX copy, error states, edge cases, i18n, and reusable design systems or tokens. Also use for bland designs that need to become bolder or more delightful, loud designs that should become quieter, live browser iteration on UI elements, or ambitious visual effects that should feel technically extraordinary. Not for backend-only or non-UI tasks.