Art & Design

tasteskill v2, the anti-slop frontend skill. Art direction for websites, distilled from a study of 247 curated gallery sites (One Page Love, Awwwards Sites of the Day). Deals researched directions (idea, composition, type, palette, photographs, section blueprints) from a library, enforces a strict no-slop house style with a real-browser inspector, and runs a look-and-fix loop on screenshots. Use this whenever you build, design, redesign, restyle, polish or review a landing page, marketing site, portfolio, product page, one-pager, hero or any public-facing web page, in any stack (HTML/CSS, React, Next.js, Vue, Svelte, Astro, Tailwind) — also when the user says a page looks generic, templated, "AI-made", sloppy, or asks to make it look designed, premium, award-level or less like every other site. Not for dashboards or app screens.

Use when writing or changing a model-facing tool definition (name, description, parameter schema, or its system-prompt section), and when designing skills, context loading, or multi-step agent workflows, to make information discoverable and use context efficiently.

Use when deciding whether to write an Agent Note (a durable design decision or proposal record), when adding, moving, consolidating, auditing, pruning, archiving, or reviewing Agent Notes under .agents/notes/, and for the supersession check every new note requires.

Apply error-handling principles when designing or reviewing failures, recovery, retries, background tasks, and user-visible error reports.

UI and visual skill for antislop. Use when building or editing any interface: color, layout, components, motion. Load with the core.

Create pixel art (game sprites, characters, items, tiles, tilesets, icons, scenes, sprite sheets) with pxl, a compact JavaScript DSL that renders PNGs and lets the user watch the painting live in a browser. Use when asked to draw, design or iterate on pixel art or game assets.

Production Go playbook. Use when writing or reviewing Go: errors, goroutines, byte payloads, parsers, and switches on external input. Worked cases are in references/bad-vs-good.md. Do not use for JavaScript, TypeScript, or API-contract design.

Design or review REST/RPC API contracts that are consistent, evolvable, and hard to misuse. Use when defining new endpoints, reviewing an API surface, or resolving naming/versioning/error-shape questions.

Rigorous, severity-ranked review of a diff, PR, or file. Use when you want a thorough check of correctness, security, performance, design, readability, and test coverage with actionable feedback.

Production data-access playbook for the N+1 query problem. Use when code queries a database inside a loop, an ORM lazy-loads a relation per row, or a list endpoint is fast at 5 rows and slow at 50. Worked cases are in references/bad-vs-good.md. Do not use for HTTP contract design or for Go/JavaScript language style.

Guide, evaluate, and architect fullstack applications covering modern Frontend UI component design, state management, and robust Backend architecture. Use when designing end-to-end features, refactoring component hierarchies, decoupling API/data access layers, reviewing PRs for architectural debt, or solving frontend-backend integration friction.

Use after system-architect to generate specs/DESIGN_SYSTEM.md, specs/CODE_STYLE.md, and specs/TESTING.md from specs/PRD.md, specs/ARCHITECTURE.md, specs/DATABASE.md, and specs/SECURITY.md. Supports both TypeScript and Python stacks, headless/CLI products, and LLM evaluation harnesses.

>- Comprehensive guide and workflow for modern full-stack web application development using TypeScript and JavaScript. Covers frontend UI (React, Vite, Next.js, component architecture, modern CSS, accessibility, state management) and backend services (Node.js, Express, Fastify, REST/GraphQL APIs, database modeling, authentication, security, and end-to-end type safety). Use this skill whenever scaffolding, developing, refactoring, or reviewing full-stack web applications.

Turn a committed intent.md into spec.md (requirements and design in one artifact), with policy concerns and open decisions flagged inline. Use after capture-intent and before plan mode.

Generate high-utility, tool-agnostic ASCII diagrams and flowcharts within code comments or documentation, following the formal "Design Space of ASCII Drawings" (Hayatpur et al., 2024). Use when the user asks to "visualize," "diagram," "flowchart," or "map out" a process, data structure, or system architecture using plain text.

Best practices for linking tools to interactive frontend widgets using @Widget and @nitrostack/widgets SDK (including state sync, tool calling, display modes, media queries, and chat actions).

Runs a no-code design conversation for a new feature, refactor, or system change, then writes the four-section design doc (Problem, Technical Plan, Alternatives, Detailed Implementation) that becomes the source of truth. Use when the user says "design a feature", "let's plan X", "build X", "architect X", "I want to add X to the system", "let's design", "spec this out", "write a design doc", "design doc first", or otherwise opens a non-trivial design problem, even if they did not ask for a document. Implements Phases 1 and 2 of the Elephant-Goldfish Model (EGM). Hand the finished doc to /egm-review. Not for one-line fixes or questions about how existing code works.

Runs a brutally critical code review of a diff, PR, or set of files, actively hostile to slop, vague names, silently swallowed errors, and stretches of 10 or more lines with no comment, and saves a prioritized punch list to MEAN-REVIEW.md so the next pass can check what was fixed. Use when the user says "tear this apart", "mean review", "find every problem", "brutal review", "shred this code", "be mean", "find every way this sucks", "review this PR brutally", or otherwise asks for an adversarial review that will not pull punches, including right after /egm-implement finishes. Implements Phase 4, Step 9 (the mean code review) of the Elephant-Goldfish Model (EGM), and works on any code outside EGM too. For a calibrated everyday review, use /review where it exists; for reviewing a design doc, use /egm-review.

Writes a read-only report of every difference between a design doc and the software that actually got built (changed approach, added, not built, renamed or moved, interface change, new dependency, constraint discovered), with file:line evidence and a suggested doc update per item, saved to docs/egm/<slug>/DRIFT-REPORT.md. Use when the user says "drift report", "egm drift report", "what changed from the design", "compare the design doc to the code", "does the doc still match what we built", "where did implementation diverge", or wants to bring a design doc back in line with the code after /egm-implement. Never edits the doc or the code. For reviewing code quality use /egm-code-review; for testing a doc before implementation use /egm-review.

Legal compliance setup for any website, app, SaaS, or startup, in any tech stack. Covers Terms and Conditions, Privacy Policy, Cookies Policy and cookie consent, register-form consent checkboxes, traceable consent records (proof of when and how each user accepted), Refund policy, data minimization, image and media rights, and local law checks (Latin America, United States, and others). Interviews the user about the business, market, and tech, then writes a reviewable draft of legal documents and code changes before anything is applied. Use this skill whenever the user mentions terms of service, privacy policy, cookies, cookie banner, GDPR, LGPD, CCPA, Habeas Data, consent, refund or return policy, "derecho de retracto", legal pages, launching or going live, preparing a startup or MVP for production, or asks if a project is "legal" or "compliant", even if they do not say "compliance".

Commit current changes, push the branch, and open a PR against main or a stacked base branch. Emits a local HTML review walkthrough with diagrams when the change is broad (multiple non-UI modules, schema changes, or a large end-to-end feature). Use when the user wants to commit their changes, push a branch, or create/open a pull request.

Optimize, review, compare, or iteratively revise AI user prompts and system prompts using workflows adapted from linshenkx/prompt-optimizer. Use for requests such as tối ưu prompt, sửa prompt, đánh giá prompt, improve this prompt, and reusable prompt templates for writing, coding, websites, research, or images. Do not trigger on ordinary task execution or translation unless prompt optimization is requested.

Research any open-source GitHub repository using DeepWiki AI-powered documentation. Use when the user asks about an external project, framework, or library hosted on GitHub, or when you need to understand how an open-source project works internally — its architecture, APIs, patterns, or design decisions. Do not use for private repos not accessible through DeepWiki.

Concentric corners in SwiftUI (iOS 26+): ConcentricRectangle, containerShape, Edge.Corner.Style.concentric(minimum:), and a reusable corner scale so nested shapes — a photo in a card, a card floating on a map, a thumbnail in that card, a hero image near the screen edge — share their corner centers instead of looking pinched or flared. Use when choosing corner radii, nesting rounded views, adopting Liquid Glass shapes, fixing corners that look "off" inside containers, or building a design system's radius tokens. Based on WWDC25 "Get to know the new design system" and the iOS 26 SDK.