skills

Find and remove AI slop — the generic, machine-default visual and copy tics of vibe-coded products — from a web project. Use when the user asks to "kill AI slop", "de-slop", "remove the AI look", "make this not look AI-generated", or clean up a landing page / UI / docs that feels templated. Detects and fixes the catalogue of tells: indigo→violet gradients, gradient-clip headlines, the default semantic palette, one-hue status boxes, atmospheric gradients, serif-italic emphasis, highlighted keywords, AI copywriting voice ("not just X — it's Y"), emoji everywhere, glowing status dots, colored-left-border callouts, pastel icon tiles, glassmorphism, over-rounding, oversized shadows, borders that die at corners, badge & pill spam, AI-drawn SVG icons, kickers over every heading, flat type hierarchies, invented stat rows (10k+ / 99.9% / 24/7), 01/02/03 section markers, cards nested in cards, the default Inter/Space Grotesk look, and more. Works on HTML/CSS, React/Vue/Svelte/Astro, Tailwind, PHP, and Markdown copy.

High-fidelity HTML design and prototype creation. Use this skill whenever the user asks to design, prototype, mock up, or build visual artifacts in HTML — including slide decks, interactive prototypes, landing pages, UI mockups, animations, or any visual design work. Also use when the user mentions Figma, design systems, UI kits, wireframes, presentations, or wants to explore visual design directions. Even if they just say "make it look good" or "design a screen for X", this skill applies.

You are required to load this before writing code. Load this skill for code-related task. Do not use this skill for simple reading code or analyze tasks unless it's related to personal codestyle.

Finds root cause before applying fixes for errors, crashes, regressions, failing tests, broken behavior, and screenshot-reported defects. Use when users report in any language errors, crashes, broken behavior, regressions, failing tests, screenshot evidence, or something that used to work and now fails. Not for code review or new features.

Turns rough ideas into approved, decision-complete plans with validated structure before coding. Use when users ask in any language for planning, architecture, design direction, feasibility, value judgment, or whether a feature is worth doing before implementation. Not for bug fixes or small edits.

Void skill for app development and CLI operations. Use this skill to route user requests to the appropriate bundled Void docs.

Migrate an existing Vite app using @cloudflare/vite-plugin to Vite + void. Use when a project already runs on Cloudflare Workers but needs Void file-based routes, inferred bindings, and void deploy workflow.

Load this skill when you are modifying existing code, or doing small patch and adjustment. Load this skill when you are reviewing an implementation or a diff, to judege whether this change is clear and consistent with other parts in codebase.

Routes to the right tool/library choices based on project type (web, JS CLI, JS library, Rust). Load when starting a new project or selecting dependencies.

Load this skill before creating, drafting, modifying, or submitting PR on GitHub

If you are now working with with a opensource project while I'm not a maintainer or author (can easily know it by resolving the path) Load this skill when I ask things like `is there a bug?` and when you sense I am willing to contribute to it, or when I am confirming whether there is a problem. Load this skill when you are modifying an existing feature without a certain reason

Load this skill when a project includes tests, and you are finishing things like bug fix or feature addition and you plan to do tests related work.

Practical guidance for working on napi-rs bindings across Rust and TypeScript/JavaScript projects. Use this skill when creating, changing, or reviewing a project that exposes Rust functionality to Node.js, TypeScript, or JavaScript through `napi-rs`.

As long as you are doing UI / style-related work, you should load this skill

Guidelines for writing documentation and prose: prefer paragraphs over heavy formatting, avoid emojis and decorative elements, use simple and direct language. You should load it when you are writing documentation.