spencerpauly/awesome-cursor-skills

# Accessibility Auditing

Audit a web page for accessibility issues using Cursor's built-in browser without external tools.

## Workflow

### 1. Open the Page

Use `browser_navigate` to open the target URL.

### 2. Capture the Accessibility Tree

Use `browser_snapshot` — this returns the aria/accessibility tree of the page. This is the same tree that screen readers use.

# Add Analytics (PostHog)

Use this skill when the user asks to add analytics, event tracking, page views, feature flags, or session replay to a web application.

## Steps

1. **Detect the framework** — check for `next.config.*`, `vite.config.*`, `package.json` scripts, or `index.html` to determine if this is Next.js, React (Vite/CRA), Vue, Svelte, or plain HTML.

2. **Install the SDK**

   - Next.js / React: `npm install posthog-js`
   - Next.js (server-side): `npm install posthog-js posthog-node`
   - Python: `pip install posthog`
   - Node.js backend: `npm install posthog-node`

# Add API Documentation (OpenAPI)

Use this skill when the user asks to add API docs, Swagger, OpenAPI spec, or generate endpoint documentation.

## Steps

1. **Detect the API framework** — check for Express, Fastify, Next.js API routes, Hono, Django REST Framework, FastAPI, etc.

2. **For Node.js/Express** — install `swagger-jsdoc` and `swagger-ui-express`:

   ```bash
   npm install swagger-jsdoc swagger-ui-express
   npm install -D @types/swagger-jsdoc @types/swagger-ui-express
   ```

# Add Authentication (Auth.js)

Use this skill when the user asks to add authentication, login, sign-up, OAuth, or session management.

## Steps

1. **Install dependencies**

   ```bash
   npm install next-auth@beta
   ```

2. **Generate an auth secret**

# Add Docker

Use this skill when the user asks to dockerize, containerize, or add Docker support to an application.

## Steps

1. **Detect the runtime** — inspect `package.json`, `requirements.txt`, `go.mod`, `Cargo.toml`, etc. to determine the language and runtime.

2. **Create a multi-stage `Dockerfile`**

   For Node.js (example):

   ```dockerfile
   FROM node:20-alpine AS base

# Add E2E Tests (Playwright)

Use this skill when the user asks to add end-to-end tests, browser tests, integration tests, or set up Playwright.

## Steps

1. **Install Playwright**

   ```bash
   npm init playwright@latest
   ```

   This creates `playwright.config.ts`, a `tests/` directory, and installs browsers. If the project already has a test runner, install manually:

# Add Error Tracking (Sentry)

Use this skill when the user asks to add error tracking, crash reporting, exception monitoring, or performance tracing.

## Steps

1. **Detect the framework** — check `package.json`, config files, and directory structure to determine the stack (Next.js, React, Node.js, Python/Django/Flask, etc.).

2. **Install the SDK**

   - Next.js: `npx @sentry/wizard@latest -i nextjs`
   - React (Vite): `npm install @sentry/react`
   - Node.js: `npm install @sentry/node`
   - Python: `pip install sentry-sdk`

# Add Feature Flags

Use this skill when the user asks to add feature flags, feature toggles, gradual rollouts, or A/B testing.

## Option A: PostHog Feature Flags (Recommended)

1. **Install PostHog** if not already present:

   ```bash
   npm install posthog-js
   ```

2. **Use feature flags in code**:

# Add Stripe Payments

Use this skill when the user asks to add payments, billing, subscriptions, or Stripe integration.

## Steps

1. **Install the SDK**

   ```bash
   npm install stripe @stripe/stripe-js
   ```

2. **Add environment variables**

# API Smoke Testing

Verify all API endpoints return healthy responses by combining codebase analysis with HTTP requests.

## Workflow

### 1. Discover Routes

Search the codebase for API route definitions:

**Next.js (App Router):** `app/api/**/route.ts`
**Next.js (Pages Router):** `pages/api/**/*.ts`
**Express:** Look for `app.get(`, `app.post(`, `router.get(`, etc.
**Django:** Look for `urlpatterns` in `urls.py`

# Architecture Decision Records

Document significant technical decisions so future you (and your team) understands why choices were made.

## When to Write an ADR

Write one when you're making a decision that:
- Is hard to reverse later
- Affects multiple parts of the system
- Involves tradeoffs between valid options
- Will be questioned by someone in 6 months

Examples: choosing a database, adopting a framework, changing auth strategy, restructuring the API, adding a build tool.

# Performance Audit

Use this skill when the user asks to optimize performance, reduce load times, fix slow pages, or audit Core Web Vitals.

## Steps

1. **Analyze bundle size**
   - Run `npx @next/bundle-analyzer` (Next.js) or `npx vite-bundle-visualizer` (Vite) to identify large dependencies.
   - Look for large libraries that could be replaced with lighter alternatives (e.g. `moment` → `date-fns`, `lodash` → individual imports or native methods).
   - Check for duplicated dependencies in the bundle.
   - Verify tree-shaking is working (no barrel file re-exports pulling in unused code).

2. **Audit rendering performance**
   - Identify components that re-render unnecessarily — look for inline object/array/function creation in JSX props.

# Security Audit

Use this skill when the user asks to audit security, check for vulnerabilities, review code for security issues, or harden an application.

## Steps

1. **Scan for hardcoded secrets** — search for API keys, tokens, passwords, and connection strings in source files. Check for patterns like:
[Credential-related source omitted]
   - Base64-encoded credentials
   - AWS keys (`AKIA...`), Stripe keys (`sk_live_...`), GitHub tokens (`ghp_...`)
   - Files: `.env` committed to git, `config.json` with credentials

2. **Check authentication & authorization**
   - Verify all API routes check authentication before processing.

# Auto Type Checking

Catch type errors immediately after every edit instead of discovering them at build time.

## Manual Workflow

After editing a TypeScript file, run:

```bash
npx tsc --noEmit 2>&1 | head -30
```

If errors appear, fix them before moving on.

# Babysitting a PR

Use this skill when the user has an open pull request and wants the agent to monitor it, fix CI failures, resolve review comments, and keep it merge-ready.

## Steps

1. **Get the PR status** — fetch the current state of the PR:

   ```bash
   gh pr view --json number,title,state,mergeable,reviewDecision,statusCheckRollup,comments,reviews
   ```

   Also check for merge conflicts:

# Best-of-N Problem Solving

Use this skill when facing a hard problem with multiple possible approaches — complex refactors, tricky bugs, performance optimization, or architectural decisions where you're not sure which strategy will work best.

## How It Works

Cursor's `best-of-n-runner` subagent type creates isolated git worktrees — each attempt gets its own branch and working directory. Multiple approaches run in parallel without interfering with each other. You compare the results and pick the winner.

## Steps

1. **Identify the approaches** — before launching, define 2-3 distinct strategies. For example, if optimizing a slow database query:
   - Approach A: Add a composite index and rewrite the query
   - Approach B: Denormalize the schema with a materialized view
   - Approach C: Add application-level caching with Redis

# Building Skills From Patterns

**Skills** are reusable `SKILL.md` files. This meta-skill tells the agent to **promote repeated muscle memory** into a named skill: research once, encode the workflow, reuse forever.

## When to trigger

- The user has asked for the **same sequence** three or more times (e.g. “always run lint then tsc then test before commit”).
- The agent notices it is **re-deriving** the same steps on every task in this repo (e.g. “how we deploy preview branches”).
- A correction sounds like a **policy** (“never use raw SQL here — always the repository layer”) — pair with `suggesting-cursor-rules` if it should be always-on; use a **skill** if it is a procedure with steps.

## Workflow

### 1. Name the pattern

# Codebase Onboarding

Generate a comprehensive onboarding document for a codebase by exploring it in parallel.

## Workflow

### 1. Launch Parallel Explorers

Spawn 5 `explore` subagents, each investigating a different area:

**Agent 1 — Architecture & Structure**
> "Map the top-level directory structure. Identify the framework (Next.js, Express, Django, etc.), monorepo tools (turbo, nx), and key config files. List every app/package and what it does."

**Agent 2 — Data Models & Database**

# Comparing Branches Visually

Create a visual before/after comparison of UI changes between two branches.

## Workflow

### 1. Set Up Two Worktrees

Use `best-of-n-runner` subagents or git worktrees to run both branches simultaneously:

```bash
# Create a worktree for the base branch
git worktree add /tmp/branch-compare-base main

# Converting CSS Modules to Tailwind

Migrate a component from CSS Modules (`.module.css` / `.module.scss`) to Tailwind utility classes.

## Workflow

### 1. Inventory the Module

Read the `.module.css` file and the component that imports it. Map every `styles.xxx` reference to the CSS rule it resolves to.

```tsx
// Before
import styles from './Card.module.css';
<div className={styles.card}>

# Converting CSS to Tailwind

Migrate plain CSS files to Tailwind utility classes applied directly in markup.

## Workflow

1. **Read the CSS file** and inventory every rule
2. **Find the corresponding markup** (HTML, JSX, TSX, Vue, Svelte) that references each selector
3. **Convert each rule** using the mapping below
4. **Delete the CSS rule** once all its properties are expressed as utilities
5. **Remove the CSS file** (or import) once it's empty
6. **Verify** the page looks identical — check for visual regressions

## Conversion Reference

# Creating a PR

Package work into a pull request that's easy to review and merge.

## Workflow

### 1. Prepare the Branch

Before creating the PR:

```bash
# Ensure branch is up to date with base
git fetch origin
git rebase origin/main  # or merge, depending on project convention

# Dark Mode Testing

Verify that dark mode works correctly by toggling themes and comparing.

## Workflow

### 1. Open the App

Navigate to the target page using `browser_navigate`.

### 2. Screenshot Light Mode

Take a screenshot of the page in its default (light) state using `browser_take_screenshot`.

# Database Design

Design a database schema from requirements.

## Workflow

### 1. Identify Entities

From the requirements, extract the core entities (nouns):
- Users, Teams, Projects, Tasks, Comments, etc.
- Each entity becomes a table

### 2. Define Relationships

# Detecting Port Conflicts

When a dev server fails to start because a port is already in use, diagnose and resolve it.

## Detection

Scan terminal output for these patterns:
- `EADDRINUSE`
- `address already in use`
- `Port XXXX is already in use`
- `bind: address already in use`
- `OSError: [Errno 98] Address already in use`

Extract the port number from the error message.

# Exporting to PNG

Convert code snippets, Markdown content, terminal output, diagrams, or rendered UI components into PNG image files.

## Methods

### 1. HTML → PNG via Headless Browser

The most flexible approach. Render any content as HTML and screenshot it.

```bash
# Using Playwright (if available)
npx playwright screenshot --full-page "file:///path/to/content.html" output.png

# Finding Dev Server URL

Detect which dev servers are running, what ports they're on, and open them.

## How It Works

Cursor stores live terminal output in text files. Each terminal has a file at:

```
<terminals_folder>/<id>.txt
```

The terminals folder path is provided in your system context. Each file contains metadata (pid, cwd, last command) followed by the full terminal output.

# Fixing Broken Links

Scan a file (or set of files) for URLs, test every link, and fix any that are broken.

## Workflow

### 1. Extract All Links

Read the target file(s) and collect every URL:
- Markdown links: `[text](url)`
- Bare URLs: `https://...`
- HTML `href` and `src` attributes
- Reference-style link definitions: `[id]: url`
- Local relative paths: `./path/to/file`, `resources/foo/SKILL.md`

# Form Testing

Systematically test every form in the app using Cursor's built-in browser.

## Workflow

### 1. Find All Forms

Use `browser_snapshot` to get the accessibility tree. Look for `form` elements, or groups of `input`, `select`, `textarea` elements.

Navigate through the app's main pages to discover all forms:
- Login / signup pages
- Settings / profile pages
- Search bars

# Generating Images (OpenAI gpt-image-2)

Use this skill any time the user asks to generate or edit an image. It wraps
OpenAI's `gpt-image-2` model via a Python script, supports both text-only
prompts and one-or-more reference images, and writes the resulting PNG/JPEG/WebP
to disk.

## Hard rules (do not violate)

1. **Always use `gpt-image-2`.** Never fall back to `gpt-image-1`, `dall-e-3`,
   or any other model. The script has no `--model` flag for this reason.
2. **Fail fast on any error.** Do not retry, do not swap models, do not patch
   around missing credentials, do not silently degrade quality. If the script
   exits non-zero, surface the error to the user verbatim and stop.

# Grind Until Pass

Use this skill when you want the agent to keep working autonomously until a specific goal is met — all tests pass, the build succeeds, or linting is clean. Instead of stopping after one attempt, the agent loops until done.

## Steps

1. **Define the goal command** — the command whose exit code determines success:

   - Tests: `npm test` or `npx vitest run`
   - Build: `npm run build`
   - Lint: `npm run lint`
   - Type-check: `npx tsc --noEmit`
   - All of the above: `npm run lint && npx tsc --noEmit && npm test && npm run build`

# Incident Response

Handle production incidents systematically.

## Severity Levels

| Level | Definition | Response Time | Examples |
|-------|-----------|---------------|----------|
| SEV1 | Service down, all users affected | Immediate | Database crash, DNS failure, auth broken |
| SEV2 | Major feature broken, many users affected | < 30 min | Payments failing, search not working |
| SEV3 | Minor feature broken, workaround exists | < 4 hours | Export button broken, slow dashboard |
| SEV4 | Cosmetic or low-impact issue | Next business day | Typo in UI, minor styling bug |

## Incident Workflow

# Kubernetes Deploying

Deploy and manage applications on Kubernetes.

## Core Resources

### Deployment

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  labels:

# Monitoring Terminal Errors

Continuously watch a running process (dev server, test runner, build) for errors and fix them as they appear.

## Workflow

### 1. Identify the Terminal

List terminal files and find the one running the target process:

```bash
head -n 10 <terminals_folder>/*.txt
```

# Network Request Auditing

Deep-dive **network** health using the `cursor-ide-browser` MCP. This skill focuses on `browser_network_requests` — not just “any 500s” but patterns that indicate bugs, waste, or security issues.

## How it works

1. Drive the app in the browser (navigate, click, submit forms) so real requests fire.
2. Call **`browser_network_requests`** after meaningful interactions (and after navigation settles).
3. Classify and report findings using the criteria below.

Follow `cursor-ide-browser` workflow rules: use `browser_snapshot` before structural interactions; after actions that change the page, take a fresh snapshot before the next interaction.

## Audit checklist

# Parallel CI Triage

Speed up fixing broken CI by splitting failing **jobs** (or independent failure clusters) across parallel subagents. Each subagent owns one vertical slice: logs, root cause, code fix, and local verification for that slice.

## Prerequisites

- **GitHub CLI** (`gh`) installed and authenticated (`gh auth login`), or use the GitHub web UI / API to copy logs manually.
- Push access to the repo so fixes can be pushed and CI re-run.

## Workflow

### 1. Identify the failing run

From the repo root:

# Parallel Code Review

Use Cursor’s **Task** tool to run **four** `explore` (read-only) subagents at once. Each subagent only reads code and produces findings for one dimension. The main agent merges results into a single prioritized review — something only a multi-agent setup does efficiently.

## When to use

- Large diffs or refactors where a single pass misses categories.
- Security-sensitive changes (auth, payments, parsing untrusted input).
- Performance-sensitive paths (hot loops, N+1 queries, bundle entry points).

## Workflow

### 1. Scope the change set

# Parallel Explore

Use this skill when you need to understand a large or unfamiliar codebase quickly — onboarding onto a new project, investigating how a feature works across layers, or mapping the architecture.

## How It Works

Cursor's `explore` subagent is a fast, read-only agent optimized for searching and reading code. You can launch multiple explore agents in a single message and they run concurrently, each investigating a different area.

## Steps

1. **Identify the areas to explore** — break the codebase into logical zones. For a typical full-stack app:
   - Frontend: components, pages, routing, state management
   - Backend: API routes, database models, middleware, auth
   - Infrastructure: CI/CD, Docker, deployment config

# Parallel Test Fixing

Speed up fixing a broken test suite by distributing failing tests across parallel subagents.

## Workflow

### 1. Run the Full Test Suite

```bash
npm test -- --no-coverage 2>&1 || true
```

Capture the output and extract all failing test files.

# Performance Profile

Use this skill when a web application feels slow, janky, or unresponsive. Cursor's built-in browser has CPU profiling tools that capture real call stacks and timing data.

## How It Works

The `cursor-ide-browser` MCP provides `browser_profile_start` and `browser_profile_stop` tools that capture Chrome DevTools-format CPU profiles. Profile data is written to `~/.cursor/browser-logs/` as both raw JSON and a human-readable summary.

## Steps

1. **Ensure the app is running** — start the dev server if it isn't already running.

2. **Navigate to the slow page**:

# Prompt Engineering

Write prompts that get reliable, high-quality output from LLMs.

## Core Principles

1. **Be specific** — vague prompts get vague results
2. **Show, don't tell** — examples beat instructions
3. **Structure the output** — tell the model exactly what format you want
4. **Iterate** — prompts are code; test and refine them

## Techniques

### System Prompts

# Python TDD with uv

Write Python code test-first using `uv` for fast dependency and environment management.

## Setting Up the Project

1. Check if `uv` is installed: `uv --version`
2. If the project doesn't have a `pyproject.toml`, initialize:
   ```bash
   uv init
   ```
3. Add pytest as a dev dependency:
   ```bash
   uv add --dev pytest pytest-cov

# React Native Patterns

Build production-quality mobile apps with React Native and Expo.

## Project Setup

**Expo (recommended for most projects):**
```bash
npx create-expo-app@latest my-app
cd my-app
npx expo start
```

**Bare React Native (when you need full native control):**

# Recording Browser Flow as Playwright Test

Use the **browser** MCP as a **recorder**: every navigation, click, fill, and keypress becomes a row in a script. The agent then translates that trace into a **Playwright** test file in the repo (or a snippet to paste into an existing spec).

This is Cursor-native because it combines `browser_snapshot` (refs + roles + names) with structured actions — not a separate recorder extension.

## Prerequisites

- Target app reachable (e.g. dev server running); use `finding-dev-server-url` if needed.
- Repo has or will have Playwright installed (`@playwright/test`). If not, add it with `adding-e2e-tests` or the project’s standard setup.

## Recording workflow

### 1. Define the flow

# Responsive Testing

After a UI change, verify the app looks correct at all standard breakpoints.

## Viewports to Test

| Name | Width | Tailwind |
|------|-------|----------|
| Mobile (small) | 375px | default |
| Mobile (large) | 428px | default |
| Tablet | 768px | `md:` |
| Desktop | 1280px | `xl:` |
| Ultrawide | 1536px | `2xl:` |

# Code Review

Use this skill when the user asks for a code review, feedback on their code, or to check code quality.

## Steps

1. **Understand the change** — read the files or diff to understand what the code is supposed to do. Identify the scope (new feature, bug fix, refactor).

2. **Check correctness**
   - Does the code handle edge cases (empty input, null, zero, negative numbers)?
   - Are error states handled (try/catch, error boundaries, fallback UI)?
   - Does async code handle race conditions, cancellation, and timeouts?
   - Are there off-by-one errors in loops or array access?

# Saving Workspace Context

You are an agent that builds institutional memory. As you work, watch for information that should outlast this conversation and save it to the workspace so future sessions start smarter.

## At the Start of Every Conversation

Load existing context before doing anything else:

1. Check for a `context/` directory — read any files relevant to the current task
2. Check for a product/project context file (e.g. `.agents/product-marketing-context.md`, `PROJECT.md`, or similar) for positioning, goals, and constraints
3. Check for any domain-specific directories the project uses (e.g. `companies/`, `docs/`, `research/`)
4. Check for templates or reusable assets that might apply

If the project doesn't have a `context/` directory yet, that's fine — create one when you first have something worth saving.

# Screenshot Changelog

Use this skill when preparing a pull request that includes visual/UI changes. Capture before and after screenshots to create a visual changelog that reviewers can quickly scan.

## Steps

1. **Capture the "before" state** — before making changes (or on the base branch), start the dev server and screenshot the affected pages:

   ```bash
   git stash  # or checkout the base branch
   ```

   Start the dev server, then:

# SEO Auditing

Check and fix technical SEO issues in a web project.

## Audit Checklist

### 1. Meta Tags

Every page must have:

```html
<head>
  <title>Page Title — Site Name</title>
  <meta name="description" content="155 chars max, compelling summary" />

# Setup CI (GitHub Actions)

Use this skill when the user asks to set up CI, continuous integration, a build pipeline, or GitHub Actions.

## Steps

1. **Detect the project structure** — check for `package.json` (Node.js), `requirements.txt` / `pyproject.toml` (Python), `go.mod` (Go), or monorepo tools like Turborepo.

2. **Create `.github/workflows/ci.yml`**

   For a Node.js project:

   ```yaml
   name: CI

# Setup Terraform

Use this skill when the user asks to set up Terraform, infrastructure as code, cloud provisioning, or IaC.

## Steps

1. **Initialize the project structure**

   ```
   infra/
   ├── main.tf
   ├── variables.tf
   ├── outputs.tf
   ├── terraform.tfvars      # (gitignored)

# Suggesting Cursor Hooks

Watch for repeated manual requests. When the user keeps asking you to run the same command after changes, suggest a hook to automate it.

## Triggers

Suggest a hook when you notice:
- The user asks you to **run the same check 2+ times** (e.g. "run lint", "run tests", "check types")
- The user says "always run X after editing" or "make sure to test after changes"
- You keep forgetting to run a validation step and the user catches it
- A CI failure could have been caught locally with a post-edit check

## How to Suggest

# Suggesting Cursor Rules

Watch for repeated corrections and frustration. When the user keeps telling you the same thing, suggest a `.cursor/rules/` file so they never have to say it again.

## Triggers

Suggest a rule when you notice:
- The user corrects the same pattern **2+ times** (e.g. "use named exports", "don't use default exports")
- The user expresses frustration about code style or conventions
- The user says things like "I always want...", "never do...", "every time you..."
- You keep making the same mistake in this project

## How to Suggest

# Suggesting Skills

Watch for moments where the user is working on something that an existing skill would make easier. Suggest it when the timing is natural.

## Triggers

Suggest a skill when:
- The user asks how to do something a skill covers (e.g. "how do I add Sentry?" → `adding-error-tracking`)
- The user is struggling with a task and a skill has a proven workflow for it
- You notice the project is missing something a skill could set up (e.g. no tests, no CI)
- The user is manually doing something a Cursor-native skill automates

## How to Suggest

# Switch Project

Use this skill when the user wants to switch to a different project, open another codebase, or move the current conversation to a different workspace root.

## How It Works

Cursor has a built-in MCP server called `cursor-app-control` with a tool called `move_agent_to_root` that changes the agent's active workspace directory. This lets you switch projects mid-conversation without opening a new window.

## Steps

1. **Ask or infer the target project** — if the user says "switch to my-app", search for it. Common project locations:
   - `~/Documents/development/`
   - `~/projects/`
   - `~/code/`

# Systematic Debugging

Debug methodically instead of randomly changing code.

## The Process

### 1. Reproduce

Before anything else, reproduce the bug reliably:
- Get the exact steps to trigger the issue
- Note the expected vs actual behavior
- Confirm it happens consistently (not intermittent)
- Record the environment (OS, Node version, browser, etc.)

# Tailing Build Output

Watch a build process in real time via terminal files and fix issues as they appear.

## Workflow

### 1. Start or Find the Build

Either start the build yourself or find the terminal running it:

```bash
head -n 10 <terminals_folder>/*.txt
```

# Updating an npm Package

Use this skill when the user asks to update, upgrade, or bump a specific npm dependency.

## Steps

1. **Check the current version** — read `package.json` to find the installed version:

   ```bash
   npm ls <package-name>
   ```

2. **Find the latest version on npm** — fetch the package info:

# Using UI Stack

Apply a structured design system to every UI component you generate. This prevents inconsistent padding, mismatched colors, and forgotten hover states.

## Design System Principles

Follow these rules for **every** component you build:

### Spacing — 8px Grid

Use multiples of 8 for all spacing (padding, margin, gap):
- `4px` — tight internal padding only
- `8px` — inline gaps, icon spacing
- `16px` — standard padding, card gaps

# Verify in Browser

Use this skill proactively after making code changes to verify the app actually works. Don't just trust that the code is correct — launch it and check.

## Steps

1. **Start the dev server in the background** — check if one is already running by listing terminals. If not:

   ```bash
   npm run dev
   ```

   Set `block_until_ms: 0` to run it in the background. Then poll until you see the "ready" message with the localhost URL.

# Verifying Markdown Formatting

Check a Markdown file for formatting issues and fix them.

## What to Check

### Structure

- [ ] Exactly one `# H1` heading at the top of the file
- [ ] Headings increment by one level (no jumping from `##` to `####`)
- [ ] Blank line before and after every heading
- [ ] Blank line before and after every code block, list, and blockquote
- [ ] File ends with a single trailing newline

# Visual QA

Use this skill after making UI changes to visually verify the result, catch console errors, and audit network requests — all without leaving Cursor.

## How It Works

Cursor has a built-in browser (`cursor-ide-browser` MCP) that can navigate to URLs, take screenshots, read console messages, inspect network requests, and interact with page elements. This skill uses those tools to do a quick visual QA pass.

## Steps

1. **Ensure the dev server is running** — check if there's already a terminal running the dev server. If not, start one in the background:

   ```bash
   npm run dev

# Writing Commit Messages

Write commit messages that are useful for humans and machines.

## Format

```
<type>(<optional scope>): <subject>

<optional body>

<optional footer>
```

# Writing Copy

Write clear, compelling copy for products and marketing.

## Principles

1. **Clarity over cleverness** — users should instantly understand what you're saying
2. **Benefits over features** — "Save 2 hours a day" beats "AI-powered automation"
3. **One idea per section** — don't overload the reader
4. **Active voice** — "We send your report" not "Your report will be sent"
5. **Short sentences** — aim for 15-20 words per sentence

## Landing Page Structure

# Writing Tests

Use this skill when the user asks to add tests to existing code, improve test coverage, or write tests for a specific file or module.

## Steps

1. **Detect the test setup** — check what's already configured:

   ```bash
   # Check package.json for test runner
   cat package.json | grep -E "jest|vitest|mocha|playwright|cypress"
   ```

   Look for config files: `vitest.config.ts`, `jest.config.ts`, `playwright.config.ts`, `.mocharc.*`. Check for existing test files to understand the project's test patterns and conventions.