svyatov

architecture-review

Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.

ask-supermatt

Ask which skill or flow fits your situation. A router over the skills in this repo.

Review the changes since a fixed point (commit, branch, tag, or merge-base) along three axes: Standards (does the code follow this repo's documented coding standards?), Spec (does the code match what the originating issue/spec asked for?), and Adversarial (how does the change fail in production?). Runs the reviews in parallel sub-agents and reports them side by side with a verdict. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X".

ideate

Generate grounded ideas for what to build next, critique every one, and rank the survivors in a Markdown file.

implement

Implement a piece of work based on a spec, tickets, or triaged issues.

teach

Teach the user a new skill or concept, within this workspace.

to-questionnaire

Turn a decision you can't fully answer into a questionnaire for someone else to fill in.

Testing & QA Listed

to-spec

Turn the current conversation into a spec and publish it to the project issue tracker: no interview, just synthesis of what you've already discussed.

to-tickets

Break a plan, spec, or the current conversation into a set of tracer-bullet tickets, each declaring its blocking edges, published to the configured tracker (edges as text in one file per ticket locally, or native blocking links on a real tracker).

triage

Move issues and external PRs through a state machine of triage roles, categorise, verify, grill if needed, and write agent-ready briefs.

wayfinder

Plan a huge chunk of work (more than one agent session can hold) as a shared map of decision tickets on your issue tracker, and resolve them one at a time until the way to the destination is clear.

adopt-release

Adopt a new release of a library, runtime, or tool: read every change since the version this project is on, match each one against what the project uses, and list what must change, what to adopt, and what to watch

browser-qa

Check a web page or the pages this branch changed in a real browser at mobile, tablet, and desktop widths, and report what is off

cut-release

Cut a release from the Unreleased changelog section: version bump, release branch, PR, squash merge, tag, GitHub release

debrief-skill

Debrief a skill's recent runs from the session transcripts, find the errors, retries, corrections, and dead ends the skill caused, and propose the edits that make the next run smooth

dependabot-review

Review Dependabot PRs for breaking changes, codebase impact, and merge readiness: one PR by URL, or an audit of every open one with a triage table

Testing & QA Listed

improve-tests

Cut a test suite to the tests that catch real bugs and its run time to the minimum: measure first, delete or demote low-value tests, fix slow setup, and prove every cut keeps the checks that matter

jury

Put a question or decision to a jury of 3 or 5 subagents: blind independent votes, one anonymized review round, and one committed verdict with the vote, the dissent, and the first action

prior-art

Check arXiv prior art before designing non-trivial architecture, algorithms, or protocols

report-upstream

Take a bug or gap found in a third-party dependency upstream: locate the repository, check for an existing report, reproduce, follow its contributing rules, and draft the issue or pull request for confirmation before anything is submitted

cprw

Commit, push, open a pull request, wait for green CI, then squash merge

verify-marketplace

Verify a plugin marketplace repo against the current Claude Code and Codex docs fetched live: catalog, manifests, layout, README, versions

verify-skill

Verify a skill against the current Agent Skills spec, Claude Code features, and upstream docs fetched live, and its own upstream repository for changes worth borrowing

generate-dockerfile

Generate optimized, secure, multi-stage Dockerfiles and .dockerignore files for any project. Analyzes the project, generates or improves the Dockerfile, then builds and runs it to validate.

generate-favicon

Generate a minimal favicon set from SVG: ICO, SVG with dark mode, Apple Touch Icon, PWA icons, manifest

import-skill

Import skills from GitHub repositories into the local toolkit. Supports copying a single skill from a GitHub directory URL or merging multiple skills into one. Also accepts pasted skill content.

improve-architecture

Find architectural improvements with assessment gate, cohesion checks, and test writing

retro

Conduct a retrospective on a coding session.

handoff

Write the current conversation into a portable handoff document for another agent to pick up.

c

Commit all changes on the current branch, main included

cb

Commit all changes, branching off first when on the default branch

cbp

Commit and push, branching off first when on the default branch

cl

Close the issues this branch's pull request resolved, checking off their items first

deps

Update every outdated dependency, run the repository's checks, and commit

fa

Apply every finding from the most recent review, audit, verification, or check in this session

fci

Diagnose the failing CI run on this branch, fix the cause, push, and watch the rerun

m

Squash merge this branch's pull request now, without waiting for CI

prd

Rewrite the pull request title and description from the full diff against the base branch

rule

Add a standing rule to CLAUDE.md, CLAUDE.local.md, AGENTS.md, or the global CLAUDE.md

wm

Wait for CI to pass on this branch's pull request, then squash merge it

ww

Explain the question you just asked and recommend an answer, with the case for and against each option

codebase-design

Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, deepen a chosen module, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.

diagnosing-bugs

Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.

domain-modeling

Build and sharpen a project's domain model. Use when pinning down domain terms or a ubiquitous language, resolving a vague or overloaded word, stress-testing how domain concepts relate, writing or editing a GLOSSARY.md, or recording a hard-to-reverse architectural decision as an ADR.

grilling

Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, says "grill me", or asks to poke holes in, challenge, or be interviewed about a plan or design, even without the word "grill".

pr

The shape of a pull request body: a summary diagram, before/after evidence, and merge danger. Use when opening a PR, writing or rewriting a PR description, or when another flow needs a PR body.

prototype

Build a throwaway prototype to answer a design question. Use when the user wants to sanity-check whether a state model or logic feels right, or explore what a UI should look like.

setup-supermatt-skills

Configure this repo for the engineering skills: set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.

tdd

Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.

wizard

Generate an interactive bash wizard that walks a human through steps only they can perform. Use when provisioning infrastructure, setting up credentials or CI secrets, walking an unfamiliar third-party dashboard, or running a one-off migration or cutover. Don't invoke this for steps the agent can perform itself.

writing-for-agents

Writing documents for agents. Use when creating or editing skills, modifying AGENTS.md or CLAUDE.md, or writing any doc an agent reaches by a pointer.

browser-compat

Audit frontend code for 50 cross-browser bugs and mobile compatibility pitfalls

dependency-vetting

Verify a package or tool is authentic before installing, adding, upgrading, or recommending it. Use whenever a task would add a dependency to a project, suggest a CLI tool, or pull a package from npm, PyPI, crates.io, Go modules, RubyGems, Homebrew, or any other registry. Also use when a registry page, install command, or installed artifact looks inconsistent with the project that supposedly publishes it.

llms-visibility

Make websites, docs, and blogs readable to LLMs and AI agents: llms.txt, .md routes, Accept negotiation, Content-Signal

commit

Git commit workflow with conventional commits, branch creation, push, and PR support. Use when the user asks to commit, save changes, push, ship it, open a PR, send a PR, or says "/commit". Also triggers on short aliases: "cp" (commit and push), "cb" (commit to new branch), "cpr" (commit and PR). Trigger phrases: "commit", "commit and push", "commit new branch", "commit to new branch", "commit and pr", "commit push pr", "commit pr", "cp", "cb", "cpr", "push this up", "save my changes", "ship it".

repo-prose

Write clear technical prose for anything that lives in a repository or on a forge: commit messages, PR titles and descriptions, PR and code review comments, issue text, READMEs, documentation, changelogs, ADRs, code comments, error and log messages. Use when composing any of these, and when editing an existing one. Combines Strunk's composition rules with a kill list of AI writing tells tuned for Claude output. Not for prose that needs a personal voice, such as blog posts, essays, or launch announcements.

astro

Skill for building with the Astro web framework (v6 and v7). Covers component authoring, islands architecture (client and server islands), content collections with loaders, actions, sessions, view transitions, middleware, on-demand rendering (SSR), adapters, and project configuration. Use when the user works with Astro, mentions .astro files, asks about static site generation (SSG), islands architecture, content collections, server islands, actions, view transitions, deploying an Astro project, or upgrading Astro.

humanizer

Remove signs of AI-generated writing from voiced prose: blog posts, essays, announcements

refactor

Refactor code at method, file, or project scope. Assesses first and stops when the code is already clean, routes architecture problems elsewhere, and gates edits on test coverage. Language-agnostic.

ci

Report CI status for the current branch or its pull request

cp

Commit all changes on the current branch and push

cpr

Commit, push, and open a pull request

p

Push the current branch, setting the upstream when it has none

research

Investigate a question against high-trust primary sources and capture the findings as a Markdown file in the repo. Use when the user wants a topic researched, docs or API facts gathered, or reading legwork delegated to a background agent.

resolving-merge-conflicts

Resolves an in-progress git merge or rebase conflict by tracing why each side changed, reconciling every conflicted hunk, running the project's checks, and finishing the merge or rebase. Use when a merge, rebase, or pull stops on conflicts, when files contain conflict markers, or when the user asks to fix or resolve merge conflicts.

lint

Run every linter, formatter check, and typecheck the repository has, and fix to zero

grill-me

Stress-test any plan, design, or idea through relentless interviewing: domain-agnostic

browser-bugs

Audit frontend code for 50 known cross-browser bugs and mobile compatibility pitfalls documented in 'Fifty Problems with Standard Web APIs in 2025.' Scans HTML, CSS, and JavaScript/TypeScript for patterns that break on Safari iOS, Firefox iOS, Chrome, and mobile browsers — then produces a severity-ranked report with specific fixes. Use this skill when the user asks to check for browser bugs, audit cross-browser compatibility, review mobile compatibility, check Safari issues, find iOS bugs in their code, or asks why something doesn't work on mobile/Safari/Firefox. Also trigger when the user mentions viewport units breaking, audio not playing on iOS, drag-and-drop not working on mobile, fullscreen issues, or touch interaction problems.

command-creator

Guides creation of Claude Code slash commands. Use when users ask to "create a command", "make a slash command", "add a command", want to automate a repetitive workflow ("I keep doing X, can we make a command for it?"), or want to document a consistent process as a reusable slash command — project-level or global.

generate-cicd

Generate CI/CD workflows (GitHub Actions) through interactive conversation by analyzing repository structure and user preferences. Use when the user asks to: (1) set up CI/CD for a project, (2) create GitHub Actions workflows, (3) add automated testing/building/deployment pipelines, (4) improve or review existing CI/CD configuration. Also use when the user mentions automating tests, running checks on PRs, or deploying on merge — even without explicitly saying "CI/CD". Triggers on: "CI/CD", "CI", "GitHub Actions", "workflow", "pipeline", "continuous integration", "continuous deployment", ".github/workflows", "automate tests", "run checks on PRs", "deploy on merge".

taskwarrior

Taskwarrior CLI reference for managing tasks, bugs, and work items from the terminal. This skill contains the correct syntax for filters, dates, recurrence, UDAs, urgency tuning, custom reports, contexts, and hooks that you CANNOT reliably produce from memory alone — Taskwarrior's syntax is unusual (attribute:value, +tag, virtual tags like +OVERDUE) and easy to get wrong. ALWAYS use this skill when the user: (1) runs or asks about any `task` command, (2) wants to add, modify, complete, delete, or list tasks, (3) asks what's due, overdue, or what to work on next, (4) wants to track bugs or work items from the command line, (5) mentions priorities, projects, tags, filters, recurring tasks, or contexts, (6) wants a custom report, UDA, hook script, or urgency tuning, (7) mentions Taskwarrior by name. Do NOT skip this skill just because the request sounds simple — even basic operations like `task add` have non-obvious attribute syntax that differs from other CLI tools.

atomic-commits

Use when implementing features, fixing bugs, refactoring code, or making any multi-step code changes. Guides agents to commit early and often in atomic increments, separate feature/refactor/cleanup work, and keep pull requests under ~200 lines. Use whenever writing code that will be committed, even if the user doesn't mention commits or PRs.

wait-what

Stop. That last message did not land: re-pitch it.

oss-audit

Score an open source repository against the oss-kit standard and report what is missing. Checks documentation, community files, CI, security posture, release process, changelog discipline, and the structure of any agent skills the repository ships, then names the skill that fixes each gap. Use when the user asks how healthy a repo is, what an open source project is missing, to audit or review a repository's open source practices, or where to start improving one.

oss-changelog

Maintain a changelog and make versioning decisions for an open source project: Keep a Changelog structure, semantic version choices, release notes generated from merged work, and deprecation policy. Use when the user asks to write or update a CHANGELOG, decide whether a change is major, minor, or patch, draft release notes, or deprecate an API. The prose style belongs to oss-writing; the publishing mechanics belong to oss-publish.

oss-ci

Set up continuous integration for an open source project on GitHub Actions or GitLab CI/CD. Use when the user asks to set up CI, create workflows or pipelines, add automated testing, building, or linting on push and pull requests, deploy a docs or other static site to GitHub Pages or GitLab Pages, or review existing CI configuration. Also use when the user mentions automating tests, running checks on PRs, or a build matrix, even without saying CI. Covers what runs. Security posture of those workflows belongs to oss-harden, and publishing belongs to oss-publish.

oss-community

Create the community and governance files an open source project needs: CONTRIBUTING, CODE_OF_CONDUCT, SECURITY.md, issue forms and pull request templates, CODEOWNERS, FUNDING, and the license file, and set the forge project's description, topics, and homepage. Use when starting a new open source project, opening a private repo to the public, when a repo is missing its community health files, or when its issue templates collect reports that still cannot be triaged. Covers GitHub and GitLab. README structure belongs to oss-readme.

oss-harden

Harden the security posture of an open source repository: pin CI actions to full commit SHAs, restrict workflow permissions, keep untrusted input out of shell commands, enable automated dependency updates, lock dependency resolution, run static analysis on pull requests, detect committed secrets before they reach the default branch, watch every shipped dependency ecosystem for known vulnerabilities, configure branch protection, enforce code owner review, and sign tags. Use when the user asks to harden a repo, improve supply chain security, fix an OpenSSF Scorecard finding, pin actions, fix a workflow script injection, enable secret scanning or push protection, turn on dependency vulnerability alerts, or lock down CI. Covers GitHub and GitLab. Publishing belongs to oss-publish.

oss-publish

Set up a secure release process for an open source package so no long-lived publishing token exists to steal. Covers trusted publishing with OIDC, build provenance, and approval-gated release workflows for npm, RubyGems, PyPI, and crates.io on both GitHub Actions and GitLab CI/CD. Use for any request to publish a package, secure or harden a release process, set up trusted publishing or provenance, or create a release workflow.

oss-readme

Write or improve a README.md for an open source project. Use this for any request to create, rewrite, review, or polish a README, project description, or getting-started docs for a library, framework, or tool, or to make an open source project more attractive to users. Covers structure and section order. For the sentences themselves, oss-writing owns style. Do NOT use for internal or private repo docs, API reference generation, or CHANGELOG and CONTRIBUTING files.

oss-skill

Fix the structure, portability, and effectiveness of repositories that ship Agent Skills. Covers canonical layout, SKILL.md conformance, trigger descriptions, progressive disclosure, repeatable procedures, bundled scripts, evaluation, licensing, and host install paths. Use when a skill fails to load or trigger, produces inconsistent results, wastes context or tool calls, ships non-portable code, or needs an audit against the current Agent Skills specification and authoring guidance.

oss-writing

Write clear technical prose for anything that lives in a repository or on a forge: commit messages, PR titles and descriptions, PR and code review comments, issue text, READMEs, documentation, changelogs, ADRs. Use this whenever you are about to write or edit any of them, including short ones. A one-line commit message or a two-sentence review comment looks too small to need a skill, and that is exactly where the tells show up. Not for prose that needs a personal voice, such as blog posts, essays, or launch announcements.