keelson-sample

Deploy a validated build per SECTION C of a planning document. Reasoning-light most of the time but needs judgment when the dry-run output looks off - a strong reasoning model is the safe choice (switch with /model). Skill is generic - it does whatever SECTION C says (Vercel, Fly, Railway, clerk deploy, local-only). Refuses to deploy unless validation is confirmed clean.

Design and scaffold a beautiful frontend from SECTION A of a planning document. Best handled by a model strong at UI generation (switch with /model; Gemini-class models excel here). The skill only builds the UI surface - auth, API calls, and SDK integrations belong to the next step. Use when the user has a plan.md from the frontend-mix-plan skill and is ready to build the UI.

Gather context for a mixed-provider full-stack build before planning. This is cheap context gathering, not reasoning-heavy work, so a fast/low-cost model is plenty (switch with /model). It inspects the repo, reads the spec if you point it at one, and writes a context.md handoff the plan step feeds off. Use this FIRST, before frontend-mix-plan. Triggers on "explore a frontend", "gather context for a mixed-provider build", "frontend-mix explore", or when given a spec markdown to scope before planning.

Address validation failures recorded by the frontend-mix-validate step. Failures that survived two repair attempts need real judgment - switch to a strong reasoning model with /model. Reads validation-issues.md, fixes each failure at the source, re-runs the validation suite, writes resolution-summary.md. Use when frontend-mix-validate wrote validation-issues.md instead of validation-summary.md.

Wire up auth, backend API, and third-party SDK integrations into a UI scaffold by executing SECTION B of a planning document. Integration is reasoning-heavy - switch to a strong reasoning model with /model. The skill is plan-driven, not vendor-specific - it uses whatever auth/SDKs/APIs SECTION B says. Use when the design step has finished and ui-summary.md plus plan.md are ready.

Plan a full-stack web application by producing a three-section spec (UI / Integration / Deployment) that downstream provider-specific steps can execute. Reasoning-heavy - switch to a strong reasoning model with /model. Run AFTER frontend-mix-explore has produced a context.md. Pure planning - it reads the context handoff (and the spec it points to) and turns it into an actionable plan. Triggers on "plan a frontend", "plan the app for mixed-provider build", "frontend-mix plan", or when given a context.md to turn into a plan.

Runtime smoke-test a freshly validated mixed-provider build by driving the RUNNING app - load every route, exercise the primary interaction, check status codes and console errors. Grind work, so a fast/low-cost model is fine (switch with /model). Catches the class of bug static checks (typecheck/lint/build) miss - broken routes, dead buttons, soft-404s, runtime errors, and the page that loads 200 but renders unstyled. Use after frontend-mix-validate (or fix-validation) confirms the build is clean, and before frontend-mix-deploy.

Run the full validation suite (install, type-check, lint, build, tests) on a freshly integrated app and fix anything broken. Validation is grind work - a fast/low-cost model is the right tool (switch with /model). Two-attempt cap per step; failures are recorded for the fix-validation escalation step, not papered over. Use after the frontend-mix-integrate step finishes.