matthewp

Migrate an existing project's styling onto Tideway — converting Tailwind, CSS Modules, styled-components, or plain CSS to Tideway's design tokens and strict BEM. Use whenever the user wants to move a codebase, page, or component to Tideway, replace an existing design system or CSS framework with Tideway, or asks to "migrate to Tideway" / "convert this to Tideway".

Find and remove unused CSS in a Tideway project — classes defined in stylesheets but never referenced in markup. Use whenever the user wants to prune dead CSS, find unused styles or classes, clean up or slim a stylesheet, find orphaned BEM classes, or "tree-shake" hand-written CSS.

Review CSS against the Tideway conventions — off-scale values, inlined tokens, direct palette use instead of semantic roles, and BEM or selector violations. Use whenever the user wants to review, lint, audit, or check CSS for Tideway compliance, or asks whether some CSS follows Tideway / the tokens / BEM.

Write CSS using the Tideway design system — fixed design tokens (colors, spacing, typography, breakpoints) and strict BEM class naming, in plain CSS with no framework. Use whenever writing or editing CSS in a project that uses Tideway, styling a new component or page, choosing colors/spacing/font sizes, or when the user mentions Tideway, design tokens, or BEM.

A GitHub client for environments with only an HTTP request capability — no shell, no jq, no code runtime to post-process responses. Manages its own auth via the OAuth device flow (plain HTTP) and reads GitHub data with GraphQL, so the server returns only the fields you ask for — small responses, no client-side filtering needed; writes go through small REST calls. Use when an agent must talk to GitHub (api.github.com) but can only issue HTTP requests and cannot run scripts or pipe output through jq. If you have a shell and jq available, prefer the `github-client` skill.

A full GitHub REST API client that manages its own auth. Gets a token from GITHUB_TOKEN, a cached token (with its expiry), or by logging the user in via the OAuth device flow — then reads or writes issues, pull requests, repos, commits, file contents, Actions runs, and notifications, and searches. Use when an agent needs live GitHub data (api.github.com) AND may need to authenticate the user. If a token is already supplied and you cannot log anyone in (headless/server context), use the `github-api` skill instead.

GitHub REST API calls with a token you are given. Uses a token supplied by the caller (GITHUB_TOKEN, or passed in by an orchestrator/workflow) to read or write issues, pull requests, repos, commits, file contents, Actions runs, and notifications, and to search — picking the right endpoint, paginating, and reading results. It does NOT log anyone in or obtain credentials: if no token is available it stops and says so. Use in headless/server contexts or when a token is provided; for interactive OAuth login use the `github-client` skill instead.

Create vanilla JavaScript view components using the "Views the Hard Way" pattern. Use when asked to create a view, component, or UI element with raw/vanilla JavaScript DOM manipulation, or when the user mentions "hardview" or "views the hard way".

Work with the Zebra framework — a class-based view framework using signals and imperative DOM construction. Use when creating, editing, or refactoring views, components, lists, or UI elements that use Zebra, or when code imports from '@matthewp/zebra'.

Guidelines for working on the Astro framework monorepo - covers build system, testing, coding conventions, and contribution workflow. Use when contributing to withastro/astro.

Use this skill whenever you start working on a coding task in a git repository — bug fixes, new features, refactors, investigations, anything substantive. It changes how you approach the work: orient on the task before touching code, consult git history when you're grounded enough to know what to look for, and distill the reasoning into a structured commit message when you're done. The goal is that the next agent opening this repo cold can recover the *why* behind every change, not just the *what*. Trigger on any non-trivial work in a project that has a git history, especially when the user mentions bug numbers, issue references, or asks you to fix/extend something that already exists. Do not trigger for one-off shell commands, pure Q&A about a codebase with no edits, or work in directories that aren't git repositories.