agent-skills

Agent Skills

A growing set of skills for Claude Code, packaged as one plugin. Each skill lives in its own folder under skills/ and becomes one slash command.

Skills

Skill	Usage	What it does
/backend	/backend [what to build], /backend design <system>, /backend review <path>, /backend checklist [path], /backend load <url> or /backend <topic>	Designs and builds backend code under expert rules, reviews it for production readiness, runs the essentials checklist, or load tests a service you own
/uiux	/uiux [what to build] or /uiux <url> [focus]	Builds UI/UX frontend that follows strict UX rules and reviews it, or audits a live site as a real user
/security	/security <target-or-path> [phase]	Runs an authorized security review of an app you own or are cleared to test, or a static code review
/checkprod	/checkprod [path], /checkprod <url>, /checkprod <path> <url>, /checkprod frontend or /checkprod backend, /checkprod fix	Grades 40 launch items (20 frontend, 20 backend) with proof for every pass, from a static project scan and a live URL check, then fixes what failed
/research	/research references [path], /research audit [path], /research write <section> [path] or /research review [path] [venue]	Verifies every reference against a registry, audits a paper's logic, numbers and consistency, drafts sections to the field's conventions, or reviews it like a tough peer reviewer
/explain	/explain <topic>, /explain simpler, /explain deeper, /explain teach <topic>, /explain quiz, /explain back <topic> or /explain remember <thing>	Explains anything in the simplest true way, easy to understand and remember, teaches step by step, quizzes you, checks your own explanation, or drills something into memory

Terse Chat

Every skill except /explain keeps its chat replies terse to save tokens. The result comes first, with no filler, pleasantries or recaps. Code, files, reports, findings with their evidence, UI copy, commit messages, security warnings and ordered steps are always written in full.

• Turn it off: say verbose, "normal mode" or "full sentences", or add verbose to the arguments, for example /backend verbose review src. To turn it off for good, ask for verbose replies in your CLAUDE.md
• Turn it back on: say terse

/explain always writes full sentences, even when terse or caveman mode is on, because a learner needs the linking words.

Installation

As a plugin, which installs every skill:

claude plugin marketplace add MarvelCollin/agent-skills
claude plugin install agent-skills@marvelcollin

Or copy one skill into your personal skills folder. Each skill keeps everything it needs inside its own folder, so it works on its own. Swap backend for uiux, security, checkprod, research or explain:

git clone https://github.com/MarvelCollin/agent-skills
cp -r agent-skills/skills/backend ~/.claude/skills/backend

To try a local checkout without installing it:

claude --plugin-dir ./agent-skills

/uiux

Build

/uiux an admin dashboard for a school testing system

Claude also loads the skill on its own whenever you ask it to build or restyle UI. Every build follows these hard rules:

Rule	What it means
R1 Pastel palette	Pastel colors built in OKLCH unless you name your own. No saturated default blue, green, purple or orange fills. Contrast is still checked
R2 No icon-tile stat cards	Totals go in one summary strip with context and links, not a row of identical cards with colored icon squares
R3 No icons in rounded squares	Icons sit inline with their text, without a tinted tile
R4 No pill badges	Status and role labels use plain column values, a shape plus a word, or weighted text
R5 Filterable tables	Global search plus a filter on every column, sorting, a clear-filters line, and filters kept in the URL
R6 Overlays size to content	Modals, drawers and popovers fit their content within limits and become sheets on mobile
R7 Custom controls	Custom scrollbars, date pickers, selects, checkboxes, sliders, dialogs and tooltips, built on accessible APG patterns
R8 Specific, consistent layouts	Layouts come from the product's content and main task, not a template, with one set of tokens and one component per job
R9 Clean copy	No semicolons and no em dashes in UI text or in anything the skill writes
R10 Fast data loading	Tables and lists paginate from the backend with server-side sort and filter, skeleton loading states, no layout shift, no lag
R11 Real avatars	A real photo or a neutral placeholder, never a circle of initials
R12 Project conventions	New files follow the project's naming, code style and placement
R13 Layered structure	Types, API calls, hooks and components each live in their own files
R14 Form overlays	Header and action buttons stay pinned, only the body scrolls, fields in a row line up, and the container grows from modal to sheet to page as the content does
R15 No AI template tells	No sparkle icons, checkmark bullets, dot grids, orbs, glass, hover lift, sliding arrows, fake terminals, three default pricing tiers, invented testimonials, emoji icons, default fonts, harsh gradients, purple on black or neon
R16 Launch ready pages	A CTA above the fold, a sticky mobile CTA on long pages, a title, description and share image per page, a favicon set, alt text, a custom 404 that returns 404, inline form errors, a thank you state, and a footer with legal links and real contact details

It also applies the guides on navigation, color picking and Shneiderman's Eight Golden Rules.

After building, it reviews its own work and answers three questions with evidence: Is it easy to use? Is it nice to use? Is the navigation good? It runs a rule scan on the code, uses the UI in a browser when it can, and fixes what it finds before reporting.

/uiux review                     # review the UI built in this session
/uiux review src/pages/admin     # review existing code

Audit

/uiux https://example.com                                  # full audit, 12 phases
/uiux https://example.com a11y AA                          # one focus area
/uiux https://example.com flow "sign up for an account"   # one user goal, step by step
/uiux https://example.com vs https://example.org           # head-to-head comparison
/uiux report                                               # compile findings from this session

Focus areas: nav, flow, forms, errors, perf, mobile, a11y [A|AA|AAA], privacy, dark, 404, slop [strict]. A persona name (sarah, marcus, elena, david, aisha, tom) runs the full audit as that persona.

Requirements

• A browser tool: the agent-browser CLI (recommended), the Claude desktop browser pane, or the Playwright MCP server
• bash or PowerShell for the scripts
• Node.js and Chrome for the axe-core and Lighthouse scans (optional)

/security

An authorized security review of a web app you own or are cleared to test. It is built for your own and local or dev builds first (localhost, private hosts, your own source), and refuses targets you cannot show authorization for.

/security dev                            # find your running dev server and screen it, no setup questions
/security dev ./app                      # same, for a project in another folder
/security ./src                          # static secure-code review, runs nothing live
/security http://localhost:3000          # full review of your local app
/security http://localhost:3000 recon    # one phase
/security review ./api                    # code review of a folder

Dev mode is the quickest way to screen your own build. A dev-detect script finds the dev server running on 127.0.0.1 and reads the stack and dev command from the project. A scope-init script then writes the engagement folder and scope.md with safe default rules for a local build, so there are no setup questions. The skill runs every phase white-box, reading your source next to the live app, and stops only at the end with the report. scope-init refuses any host that is not local, so a public site still needs your stated authorization. The skill pins itself to Opus 5.5 at high effort while it runs.

It works in phases, based on the OWASP WSTG and ASVS:

1. Scope. Confirms authorization and writes the rules of engagement. Nothing active runs before this. A scope-check script verifies each target is in scope, and flags out-of-scope hosts.
2. Recon. Maps the attack surface inside scope, preferring the app's own source and traffic over noisy scanning.
3. Testing. Works through vulnerability classes matched to what recon found: injection, broken auth and access control, SSRF and server-side, XSS and client-side, session and tokens, business logic, misconfiguration, exposed secrets, client exposure (env values in the bundle, tokens in storage, over-fetched responses, public source maps), client tampering (an edited request that forges a role, owner, price or status), data the client reaches directly (tables without RLS, public buckets, open Firebase rules), API, and LLM features. Lightest touch that proves the issue, nothing destructive.
4. Validation. Six gates kill false positives. A finding ships only when reproduced with evidence and real impact.
5. Report. Every finding gets severity, evidence, impact and a concrete fix, mapped to OWASP and CWE, with fixes ranked by risk over effort.

A grep-audit script speeds up code review by flagging risky sinks and hardcoded secrets for a human to read, including secrets behind public env prefixes, tokens in web storage, public source maps, decoded but unverified JWTs, cookies without HttpOnly, roles, prices and identity headers taken from the client, RLS switched off, write policies open to everyone, public buckets and open Firebase rules. The skill only tests targets the user owns or is authorized to test, and never helps evade detection, target at scale, run denial-of-service, or attack third parties.

/backend

Backend engineering at a staff level: correct under concurrency, fast at real data volume, safe by default, and easy to operate.

/backend add a paginated orders endpoint       # build under the hard rules
/backend design a multi-tenant billing service # design doc first, then build
/backend review ./api                          # scored production-readiness review
/backend review diff main                      # review a branch or the current changes
/backend checklist ./api security              # stress test first, then the essentials checklist
/backend load http://localhost:3000/api/orders # load or stress test your own service
/backend n+1                                   # one topic: explain, audit this code for it, fix

Claude also loads the skill on its own when you write endpoints, queries, migrations or jobs, or ask to optimize or harden a backend.

Build

Every build follows these hard rules, then ends with a Rules Check that says pass, not applicable or still open for each one:

Rule	What it means
B1 Authenticate every route	Global auth with a public allowlist, argon2id or bcrypt, rate-limited login, short tokens fully verified
B2 Authorize every object, function and field	Owner or tenant scope inside the query, server-side permission checks, write allowlists and read DTOs, identity never from the client
B3 Validate at the boundary	A schema on every input, global size limits, problem details on failure, a DTO on every response
B4 No N+1 queries	Eager loading or batching, DataLoader for GraphQL, lazy-load guards in dev, query-count tests
B5 Bounded, paginated, lean queries	Default and max page size, keyset pagination for big lists, no SELECT *
B6 Index and constrain in the database	Indexes that match hot queries checked with EXPLAIN, indexed foreign keys, constraints, safe online migrations
B7 Transactions, concurrency, idempotency	Short transactions, atomic updates or locks instead of check-then-act, idempotency keys, outbox
B8 Timeouts, retries and limits	A timeout on every outbound call, bounded retries with jitter, circuit breakers, rate limits
B9 Structured logs	JSON logs with request and trace ids, redaction of secrets, one log per error, audit log
B10 Metrics, traces, health	RED metrics, OpenTelemetry tracing, separate liveness and readiness
B11 Safe errors	One handler, RFC 9457 problem details, nothing leaked, nothing swallowed
B12 Slow work off the request path	Durable idempotent jobs, nothing that blocks the event loop
B13 Config and shutdown	Typed config validated at startup, no secret fallbacks, graceful shutdown, a secret scan of the git history and a dependency audit in CI
B14 Correct types	Money as integer cents or decimal, UTC timestamptz, UUIDv7 or bigint keys
B15 Prove it with tests	Real-database integration tests, authorization matrix, query counts, parallel and idempotency tests, tamper tests, a build check for leaked secrets
B16 Nothing secret reaches the client	No secret behind a public env prefix or in the bundle, no public source maps or debug pages, an opaque HttpOnly session cookie, no tokens in web storage, DTO responses with no hashes or config
B17 The server decides	Role, owner, price, total and status come from the server and a forged field changes nothing, hidden UI is never the check, tokens are verified and not only decoded
B18 Lock the data the client can reach	RLS on every table the browser can reach with owner scoped policies, no using (true) on writes, private storage buckets with signed URLs, Firebase rules that check the owner, and the service role key only on the server

The rules link to 22 topic guides: API design, authentication, authorization, validation, database and N+1, migrations, concurrency, caching, performance, resilience, background jobs, logging, observability, errors, testing, config and deploy, architecture, distributed systems, real-time, client trust (secrets out of the browser, never trust client values), client data access (RLS, storage buckets and Firebase rules), and a security baseline mapped to the OWASP API Security Top 10 (2023). A Postgres guide ranks its rules by impact with wrong and right SQL, and a stack guide covers the concrete fixes for Node, Python, Rails, Laravel, Spring, .NET, Go and GraphQL.

Design

/backend design <system> is for a new service or a change that is costly to undo. It asks only the questions the code cannot answer (traffic, data size, tenancy, consistency, latency and recovery targets), each with a recommended answer. It then estimates capacity, picks the simplest shape the numbers support, models data from access patterns, drafts the API contract and records decisions as ADRs. It stops for your approval before building anything expensive to reverse.

Review

/backend review <path> maps the system, runs the backend-scan script, walks 13 areas against the rules, measures query counts and plans when the app runs locally, and confirms every finding through five gates before it is reported. The report has a weighted score out of 100, a severity for each finding, and a fix plan ranked by impact over effort.

backend-scan flags leads with a rule tag: N+1 calls inside loops, maps and comprehensions, unscoped id lookups, client-supplied roles, mass assignment, unbounded queries, SELECT *, offset pagination, blocking index builds, HTTP calls without timeouts, unstructured or secret-leaking logs, swallowed and leaked errors, blocking calls, credentials in connection strings, secret fallbacks, float money, naive timestamps, decoded but unverified JWTs, cookies without HttpOnly, secrets behind public env prefixes, public source maps, the whole environment sent in a response, tokens in web storage, client-sent prices, status and identity headers, public storage buckets and open Firebase rules. It skips tests, vendored code and build output. /backend review diff [base] reviews only a branch, pull request or the current changes.

db-lint does the same for SQL migrations and Prisma schemas: blocking index builds, constraints validated under lock, NOT NULL without a default, column type changes, unbatched backfills, foreign keys without an index, float money, timestamps without a time zone and random UUID keys. In Supabase style migrations it also flags tables created without RLS, write policies of using (true) and public storage buckets.

Checklist

/backend checklist [path] [maintenance|security|db|caching|speed] is the fast pass for the essentials. It stress tests first, when it has a runnable target you own, to find the real bottleneck, then grades 52 items in five groups and ranks the fixes so the ones that explain the bottleneck come first. Each item links to its rule and topic file, and every pass needs proof (file and line, config value, command output). With no runnable target the baseline is reported as not measured, never invented. Items that live outside the repo, such as backups, CDN and HTTPS at the load balancer, are marked unverified instead of guessed.

Group	Items
Maintenance	Migrations, health check, logging, error monitoring, database backups, tests, profiling slow endpoints
Security	Password hashing, rate limiting, parameterized queries, input validation, secrets in env vars, HTTPS, CORS whitelist, httpOnly and secure cookies, JWT expiry with refresh tokens, no stack traces to users, secrets and sessions kept out of the browser, no trust in client-sent roles or prices, RLS on tables the client can reach, locked storage buckets, a git history secret scan, a dependency audit
Database speed	Indexes, composite and covering indexes, N+1, selected columns, LIMIT, cursor pagination, batching, pooling, precomputed counts, denormalized hot reads, EXPLAIN, query timeouts, transactions
Caching	Redis for reads and sessions, HTTP cache headers, CDN, TTL, invalidation on update
Response speed	Compression, small payloads, pagination, HTTP/2 and keep-alive, async I/O, background jobs, parallel calls, request timeouts, image resizing on upload

Load test

/backend load <url> [smoke|load|stress|spike|soak|breakpoint] plans the traffic mix and pass criteria, runs the test, watches the server side, and names the bottleneck with evidence. The load-test script wraps autocannon (it needs Node.js) and reports requests, RPS, p50, p90, p99, error rate and a pass or fail against thresholds. For ramps and mixed traffic the skill writes a k6 script.

Load tests only run against services you own. Local and private hosts are allowed by default. Any other host needs you to state your authorization, and the script refuses it without --authorized and a rate cap. The skill never load tests third parties.

/checkprod

Checks whether a web app is really ready for production, the things a vibe coded site usually misses. Claude also loads it on its own when you ask if a site is ready to launch or production ready.

/checkprod                             # the current project
/checkprod ./app https://myapp.com     # static scan plus live check, the strongest proof
/checkprod backend                     # only BE1 to BE20
/checkprod fix                         # fix the failed items, blockers first

Group	Items
Frontend FE1 to FE20	Custom 404, CTA above the fold, title and description per page, Open Graph image, favicon set, robots.txt, sitemap.xml, alt text, mobile breakpoints, sticky mobile CTA, loading, form error and success states, privacy and terms pages, cookie consent, analytics, real contact details with no placeholder content, HTTPS on the real domain
Backend BE1 to BE20	Hidden API keys, RLS, IDOR, git history secrets, admin routes, user isolation, rate limits, storage buckets, input validation, unauthenticated routes, SQL injection, sensitive logs, field tampering, file uploads, server logic, trimmed responses, auth sessions, dependency audit, record access, production config

prod-scan reads the project once and prints a graded line per item with file and line evidence, plus leads such as images without alt, secrets behind public env prefixes, open Firebase rules, tables without RLS and placeholder text. It also searches the git history for committed keys (commit hashes only, never the secret) and names the dependency audit command for the stack. prod-url acts like one visitor with about a dozen requests: HTTPS and security headers, title, description, Open Graph and favicon, robots.txt, sitemap, the 404 status, images without alt and load time. Its exposure probes (/.env, /.git/HEAD, public source maps) only run on local and private hosts, or with --authorized after you confirm you own the host.

Every pass needs proof. Items a scan cannot see are graded manual and checked in a browser at 375 and 1440 when one is available. The active tests (IDOR, SQL injection, user isolation, record access) are handed to /security, never run by checkprod. In fix mode it asks you for real contact details, the legal entity, analytics IDs and keys instead of inventing them, never writes testimonials, and marks any drafted legal page as a draft for review.

/research

Checks, audits, drafts and reviews research documents (papers, theses, reports, proposals) in any field, written in LaTeX, Markdown, Word exported to text or plain text. Claude also loads it on its own when you ask to check citations, sanity check a paper, rewrite an abstract or predict reviewer objections.

/research references paper.tex        # every citation real, resolvable and where a claim needs it
/research audit thesis/               # logic, numbers and consistency, quoted with locations
/research write abstract paper.md     # draft or restructure a section to the field's conventions
/research review paper.tex NeurIPS    # tough peer review with scores, objections and a rebuttal plan

Mode	What it does
References	Runs cite-check, then resolves each entry against Crossref or the publisher, flags invented or mismatched entries, checks that every claim that needs a citation has one that supports it, and makes the style consistent
Audit	Runs fixed passes in order (map, claims, numbers, missing pieces, logic, consistency, structure). Finds numbers that differ between abstract, text and tables, missing baselines, ablations, definitions and limitations, causal claims from correlation, circular reasoning and contradictions between sections. Every finding quotes the text, gives its location, a severity and a fix
Write	Gathers the facts first, outlines before prose, then writes paragraph by paragraph with a claim to evidence map. Anything it cannot source becomes a visible placeholder
Review	Reads as a reviewer for the stated venue, scores five dimensions, ranks the objections that decide the outcome, and plans the rebuttal

Two scripts speed it up. cite-check reads .tex, .md and .bib files and lists cited keys missing from the bibliography, entries never cited, entries with no DOI or URL, malformed DOIs and duplicates. With --online it checks each DOI against Crossref and reports DOIs that do not exist and titles or years that do not match. numbers-extract lists every number with its zone and sentence, and flags abstract numbers found nowhere else, sample sizes that change, and percentages that do not add up.

It never invents a reference, DOI, author, number or result. What it cannot confirm becomes a placeholder such as [CITE: source for the 62 percent figure].

/explain

Explains anything you do not understand in the simplest true way, so it is easy to understand and easy to remember. Claude also loads it on its own when you say you do not get something or ask for a simple explanation.

/explain what is a database index
/explain this error: ECONNREFUSED 127.0.0.1:5432
/explain src/auth/session.ts     # explains your own code with your own names
/explain simpler                 # same idea from a new, simpler angle
/explain deeper                  # one layer down, real terms tied to the first picture
/explain example                 # another example and a near miss
/explain teach recursion         # short lesson, one chunk per turn with a check
/explain quiz                    # questions on what was explained, one at a time
/explain back closures           # you explain it, Claude finds the gaps
/explain remember <paste text>   # logic map, fading cues, recall drills, spacing schedule

A default explanation is 80 to 200 words with this shape, and any part that adds nothing is dropped:

Part	What it does
Core	The answer in one plain sentence, by what it does or why it exists
Picture	One everyday comparison with the parts mapped and its limit stated
Example	One real case before any definition, your own code when there is some
How it works	At most three steps, with a small text diagram for flows
Watch out	The common wrong idea and where it fails
The name	The real term last, so you can search it
Remember	One bold line to keep
Your turn	One small question that makes it stick, never "does that make sense?"

Every explanation follows rules E1 to E14 (answer first, plain words, what it does before what it is called, concrete before abstract, three new ideas at most, one picture with its limit, cut everything extra, simple but true, name the trap, short by default, respect the reader, leave one thing to do, match the learner, clean copy). The rules come from research on cognitive load, worked examples, analogies, misconceptions, retrieval practice and AI tutoring, plus the methods of explainers like Feynman, 3Blue1Brown and Julia Evans. Sources are in skills/explain/references/research.md.

/explain remember is for things you need to memorize, like an essay template, a formula or a list. It explains the meaning first, builds a logic map that says the job of each part, then drills you through four levels (full text, first words only, the logic chain only, blank page) with feedback on each attempt. It gives a spacing schedule (day 1, 2, 4, 7, 14 and 30) and ends with practice using the material on new content, because rereading feels like learning but fades fast.

Project Structure

.claude-plugin/
  plugin.json                 Plugin manifest
  marketplace.json            Marketplace entry so the repo can be installed directly
skills/
  uiux/
    SKILL.md                  Entry point: build, review and audit modes
    references/               Build rules, color, navigation, golden rules, UI review,
                              browser protocol, personas, rubric, heuristics, flow test,
                              accessibility, comparison, slop catalog, report
    templates/                Report and flow test templates
    scripts/                  rule-scan, perf-check, axe-scan, lighthouse-audit, conventions (.sh + .ps1)
  security/
    SKILL.md                  Entry point: scope, recon, test, validate, report, code review
    references/               Authorization, recon, validation, reporting, code review,
                              testing/ (13 vulnerability classes)
    templates/                Report and finding templates
    scripts/                  dev-detect, scope-init, scope-check, grep-audit (.sh + .ps1)
  backend/
    SKILL.md                  Entry point: build, design, review, checklist, load test and topic modes
    references/               Build rules B1 to B18, design, review, essentials checklist, load testing,
                              Postgres guide, stack notes, topics/ (22 backend topic guides)
    templates/                Design, review and load test report templates, OpenAPI starter
    scripts/                  backend-scan, db-lint, conventions, load-test (.sh + .ps1)
  checkprod/
    SKILL.md                  Entry point: project, live site, frontend, backend and fix modes
    references/               The 40 item checklist, where each item lives per framework
    templates/                Launch report template
    scripts/                  prod-scan, prod-url (.sh + .ps1)
  research/
    SKILL.md                  Entry point: references, audit, write and review modes
    references/               One file per mode, field conventions, statistics checklist
    templates/                Audit, review and references report templates
    scripts/                  cite-check, numbers-extract (.sh + .ps1)
  explain/
    SKILL.md                  Entry point: explain, simpler, deeper, example, teach, quiz, explain back and remember
    references/               Rules E1 to E14, plain words, pictures and examples, teach mode, remember mode,
                              research sources
evals/                        Cases for claude plugin eval
tests/                        Unit tests for the scripts

Development

Run the script tests. They start a local fixture server and use a fake npx, so they need Python 3 but no network or Chrome:

bash tests/run-tests.sh

Validate the manifests and skill frontmatter:

claude plugin validate .

Run the behavior evals, starting with one case:

claude plugin eval . --case build-dashboard --allow-tools Bash Write Edit

License

MIT