agentsclimarketplace
Sign in

Landing page

Skill ariaxhan/kernel-claude/skills/landing-page

Explicit landing-page build and deployment operator. Loads marketing strategy and frontend judgment, scaffolds the smallest suitable site, verifies rendered behavior, and deploys to the user's or project's configured target.From its SKILL.md

Install
npx -y skills add ariaxhan/kernel-claude --skill landing-page

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 12 stars12 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.5 KB, as published. Nobody here has run it

<skill id="landing-page"> <purpose> Build, verify, and optionally deploy a focused landing page. This is the explicit operator; strategy and aesthetics come from the methodology skills it composes. </purpose>

<skill_load> Load skills/marketing-site/SKILL.md and skills/frontend/SKILL.md before writing. </skill_load>

<inputs> Use answers already present in the request/repository. Resolve only what materially changes the build: audience, desired action, offer/proof, brand/assets, required content/legal pages, real CTA destination, domain, and deploy target. Never invent brand facts or proof.

For the unresolved inputs, run a structured interview with the AskUserQuestion tool (batched, up to 4 questions per round, recommended option first where evidence supports one) instead of guessing or asking loose prose questions. Bounded choices only; positioning and voice discussions stay prose. The interview method: skills/build/SKILL.md "The interview". </inputs>

<scaffold> - Follow the existing repository and stack first. For a new simple page, prefer static HTML/CSS with JavaScript only for real behavior; add a framework only when requirements earn it. - Build the content argument with `marketing-site`; build the visual system with `frontend`. - Add only the pages and integrations the brief needs. If forms, analytics, cookies, payments, embeds, or accounts touch data, create/update a privacy page that matches the real behavior. - Keep secrets and deploy credentials out of source. </scaffold> <verify-local> - Render and do visual QA at 375 / 768 / 1440 widths unless the product defines better targets. - Check hierarchy, realistic content, overflow, keyboard/focus, reduced motion, contrast, images, console errors, links, metadata, and CTA/form success plus error paths. - Confirm the privacy policy matches actual collection and third parties. - Run the repository's tests/build/lint and fix failures before deployment. </verify-local> <deploy> - Use the project's configured deploy command and provider. If none exists, choose the smallest provider-appropriate static deployment; Cloudflare Workers Static Assets is one option, not a universal default. - If the user already named the deploy target and asked to deploy, that counts as confirmation. Otherwise surface the resolved account/project/domain before the side effect. - After deploy, verify the live URL: status 200, headline/content marker, nested assets, legal page, and conversion path. Static assets can propagate briefly, so retry a short bounded check before diagnosing a successful deploy as broken. </deploy> <hard-stops> - No fabricated proof, shippable placeholders, fake form success, or dead CTA. - No secrets in committed source. - No “done” claim based only on source, build, commit, or deploy output; inspect the rendered page locally and the served page after deployment. </hard-stops>

<on_end> Report the live URL if deployed, target widths and paths checked, claims/proof source, privacy behavior, and any verification bar not observed. </on_end>

</skill>

Keep looking

Skills are one crate of 627,801. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.