Skills
96,981 packaged capabilities and playbooks for agents. Install any of them with one command.
Testing & quality
Converts desktop workflow markdown into a self-contained Playwright test project with authentication scaffolding and CI workflow. Use when the user says "convert desktop workflows to playwright", "translate desktop workflows to CI", "generate desktop playwright tests", or wants to promote desktop workflows to automated CI tests.
Performs security-focused differential review of code changes (PRs, commits, diffs). Adapts analysis depth to codebase size, uses git history for context, calculates blast radius, checks test coverage, and generates comprehensive markdown reports. Automatically detects and prevents security regressions.
Use when evaluating projects for production or enterprise readiness, implementing supply chain security (SLSA, cosign, SBOMs, pnpm), hardening CI/CD pipelines, establishing quality gates (TYPO3: CI matrix PHP 8.2-8.5 x TYPO3 12.4/13.4/14.3 LTS), pursuing OpenSSF Best Practices Badge (Passing/Silver/Gold) or OSPS Baseline levels, reviewing code quality, writing ADRs, or configuring Git hooks and CI pipelines.
Create new eval suites for the deepagentsjs monorepo. Handles dataset design, test case scaffolding, scoring logic, vitest configuration, and LangSmith integration. Use when the user asks to: (1) create an eval, (2) write an evaluation, (3) add a benchmark, (4) build an eval suite, (5) evaluate agent behaviour, (6) add test cases for a capability, or (7) implement an existing benchmark (e.g. oolong, AgentBench, SWE-bench). Trigger on phrases like 'create eval', 'new eval', 'add eval', 'benchmark', 'evaluate', 'eval suite', 'write evals for'.
How to find, build, and run tests in workerd. Covers wd-test, kj_test target naming, bazel query patterns, and common flags. Also covers parent project integration tests if workerd is used as a submodule. Load this skill when you need to locate or run a test and aren't sure of the exact target name or invocation.
Persist flaker's DuckDB storage across GitHub Actions runs and feed it from multiple sources (vitest reports, custom adapter reports, etc.). Use when wiring `@mizchi/flaker` into a new repo's CI, adding a new ingest source to an existing flaker setup, or debugging why `flaker apply` / `flaker run --gate ...` "lost its history" between runs. Encodes the cache key shape, fetch-depth requirements, `--changed` derivation, and the import-step placement that internal flaker users converged on.
Shared workflow for browser-based review of user-visible frontend changes in Langfuse. Use when a change affects UI behavior, layout, styling, navigation, or browser-visible regressions and should be checked with available browser automation before signoff.
Use when assessing code quality hygiene — TypeScript strictness, lint violations, dead code, and duplication. Runs `audit-typescript.sh`, `audit-lint.sh`, `audit-similarity.sh`. Does NOT cover dependency freshness or CVE audit — use `frontend-review-deps` for that.
Use when reviewing React rendering performance — profiler-first diagnosis, memo/useCallback/useMemo correctness, virtual scroll, useTransition/useDeferredValue, and canvas/WebGL separation for data-heavy UIs. Covers checklist 24-rendering-performance.md.
Expert Go backend code reviewer specializing in microservices, GORM/DAL patterns, dependency injection, and resource management. Focuses on logic correctness, goroutine leak detection, and Go-specific best practices for production-grade services.
Apply the grug brain philosophy to software development - fight complexity, prefer simplicity, and build maintainable code. Use when the user asks to "simplify this code", "is this too complex", "should I abstract this", "review for over-engineering", "grug brain", "keep it simple", or when reviewing code for complexity issues, making architectural decisions, or refactoring code to reduce complexity.
Use when planning tests for Arduino, ESP32, ESP32-S3, Pico, or Pico W firmware; deciding what can run off-target; using Wokwi or simulation; writing host fakes; or accepting a physical hardware feature without confusing compile proof with system proof.
Runs the deterministic structural lint over a tempa-spec change's artifacts (hashtag counts, checkbox format, delta headers, capability<->spec-file correspondence, Covers: target existence, design.md section presence, unverified External Dependencies rows, tasks.md group graph: Depends on, task coverage: Covers: per group in both directions, the threat chain: every threat answered by a negative scenario or a named check, and proposal size and shape warnings) so a language model does not do this by hand. Called from hrt-adversarial-authoring and hrt-align-consistency-review. Judgement checks stay with the reviewers.
Validate whether two raster image layers are suitable for reveal, before/after, morph, mask-compositing, or interactive cursor reveal effects. Use when comparing base/reveal images, checking whether the main subject stayed in the same position, separating primary subject drift from background or secondary-object differences, producing annotated overlays/difference maps, or deciding whether an image layer must be shifted, scaled, cropped, or regenerated before frontend compositing.
Use when initializing or correcting Prettier, lint-staged, simple-git-hooks, and LF line-ending configuration in a Node.js project, or when you need to install a Node/pnpm environment in a GitHub PR cloud job and safely format PR changes; applies to prettier-plugin-lint-md version drift, plugin load failures, git hooks, EOL, CRLF/LF, and phantom modification issues.
Assesses pre-launch readiness across every function and produces an explicit Go / Conditional Go / No-Go recommendation. Use when preparing for any product or feature launch, running a pre-launch review, or determining whether a release is safe to ship. Produces a function-by-function readiness status, a ranked blockers list with owners and deadlines, a risk register, and a clearly reasoned launch recommendation.
Expertise in LLVM security features including sanitizers, hardening techniques, exploit mitigations, and secure compilation. Use this skill when implementing security-focused compiler features, analyzing vulnerabilities, or hardening applications.
Audit macOS app release readiness including app bundle identity, signing, notarization, sandboxing, hardened runtime, permissions, keychain, app support data, launch agents, login items, menu bar, Dock behavior, file associations, universal builds, auto-update, crash logs, backup, uninstall, and support diagnostics. Use when shipping or reviewing macOS desktop apps and utilities.
Configure, manage, and troubleshoot markdownlint in projects. Use when user wants to setup/install/configure markdownlint, add/remove/modify linting rules, fix markdown validation issues, customize .markdownlint.yaml, update ignore patterns, integrate with tools (Husky, CI), or troubleshoot markdown linting errors. Use even when user mentions markdown formatting problems, quality issues, or style consistency without explicitly saying "markdownlint".
Build Simulink models that co-simulate with Eclipse SUMO traffic simulator. Use when creating SUMO-Simulink co-simulation, traffic simulation, TraCI connection, vehicle-in-the-loop testing, or ADAS scenario validation with SUMO. Covers Server/Client setup, Reader/Writer/Actor block configuration, random traffic generation, ego vehicle control, and SUMO file creation. Also use when the user mentions SumoInterfaceLibrary, .sumocfg files, or wants to connect Simulink to an external traffic simulator.
Port a Cypress test suite to CodeceptJS 4. Trigger when the project contains `cypress.config.{js,ts,mjs}`, a `cypress/` directory (`cypress/e2e/`, `cypress/support/{commands,e2e}.*`, `cypress/fixtures/`), `cypress` in `devDependencies`, or test code calling `cy.*` (`cy.visit`, `cy.get`, `cy.contains`, `cy.session`, `cy.intercept`, `cy.request`, `cy.task`, `cy.fixture`, `cy.origin`, `cy.mount`), `Cypress.Commands.add(...)`, or `Cypress.env(...)`.
Generates mobile browser workflow documentation by exploring the app's codebase, then walking through the live app with the user step-by-step via Playwright in a mobile viewport (393x852) to co-author verifications. Use when the user says "generate mobile workflows", "create mobile workflows", "update mobile workflows", or "generate mobile browser workflows". Produces numbered workflow markdown files that feed into the mobile converter and Playwright runner. Includes iOS HIG awareness and mobile UX anti-pattern detection.
Code and product quality gates for shipping with confidence. Runs code review, QA testing, performance checks, and security audits. Use when the user says 'review my code', 'is this ready to ship', 'check quality', 'run QA', 'test this', 'security check', 'pre-launch review', or wants a quality assessment before deploying.
Use when a reviewer CLI must analyze a skill, command, workflow, document, config, or code artifact and produce a structured defect report for the current CLI to consume, especially after requests like "分析这个 skill 的问题", "输出结构化问题报告", or "做多 CLI 审查".
Use when the current CLI is the sole fixer for one or more `multi-cli-review` reports and must reconcile reviewer findings before any edits, especially after requests like "汇总审查报告", "处理 multi-cli-review 输出", or "按 reviewer 建议执行修复".
Converts multi-user workflow markdown into a self-contained Playwright test project with per-persona authentication, multi-context test patterns, and CI workflow. Use when the user says "convert multi-user workflows to playwright", "translate multi-user workflows to CI", or "generate multi-user playwright tests".
Review and audit NetBox integration code for correctness, performance, and reliability. Use when reviewing scripts or applications that interact with NetBox APIs, checking for pagination bugs, authentication issues, performance anti-patterns, error handling gaps, and SDK misuse.
Create, review, remediate and publish Skills. Use when the user wants to create a Skill from scratch, review an existing Skill, check whether it is actually useful, fix its triggering or execution flow, or improve first-use experience, stability, token cost, file layering, weak-model readability and cross-platform compatibility. Do not use it to perform the actual task a target Skill is responsible for, and do not trigger it for ordinary coding, design or writing requests.
The independent review step, second to last in the QA process. After qa-test-runner finishes execution, review the code itself from an independent perspective — checking architecture, security, concurrency correctness, data consistency, regression risk, and test coverage gaps — uninfluenced by the executor's conclusions. Produce code-review.json (with severity-graded findings and readiness constraints) which, together with the assert-code-review gate, forms the code review evidence passed to qa-report-generator for the final report. P0/P1 security issues, funding logic defects, permission vulnerabilities, and data inconsistency risks are marked as blocking. Not applicable to: generating test cases, executing tests, modifying product code (unless the user explicitly asks), report generation.
Upstream phase of QA — build a factual profile and environment evidence for the repository. Triggered when you need to collect code context for a module, index existing cases and tests, check frontend/backend service reachability, or prepare an environment snapshot. Collect facts only; do not perform risk analysis, write test cases, or judge quality. Usually executed as the first phase under the scheduling of quality-assurance-agent. Not applicable to: risk analysis, test case design, test execution, quality determination (handled by downstream phases).
The closing phase of the QA process — aggregate the artifacts of the three gates (completion, code-review, readiness), render the final HTML report, and give the final readiness determination. Triggered after qa-test-runner finishes execution and qa-code-reviewer finishes review. Read only the existing gate artifacts; do not re-run tests or review code. Not applicable to: executing tests, fixing failures, code review, test case design.
Before designing test cases, identify high-risk business paths and required verification assertions (oracles). Analyze requirement documents, code diffs, existing cases, and context to find high-risk areas such as funding/permissions/state machines/concurrency/async/data consistency, and output each risk's businessPath, requiredAssertions, suggestedTestLayers, plus coverage gaps. Do not write business test cases before the risks are clear. Not applicable to: writing business test cases, writing test code, modifying product code.
Once the spec-tasks and test scripts are ready, run them case by case, classify failures, fix the minimal root cause, collect evidence, and run the completion gate. You are only responsible for "running" — you do not generate reports, review code, or decide Ready. Review is left to qa-code-reviewer; the report and determination are left to qa-report-generator. Not applicable to: report generation, code review, test case design.
After the user confirms the test cases, expand the confirmed business cases into executable spec-tasks and test scripts. What you produce is test-spec-tasks.json — the later execution phase uses it to run case by case and collect evidence. You are only responsible for "generating the executable artifacts", not for "execution". Judging pass/fail/ready is done by the later execution phase. Not applicable to: executing tests, marking pass/fail, readiness determination.
After risk analysis is complete and before writing test code, generate Chinese business test cases and wait for user confirmation. This is the only mandatory human gate in the entire QA process — once confirmed, the cases cannot be revised. Starting from context, risk-analysis, and the existing case index, generate test-cases.json containing only business behavior (excluding technical checks such as Maven/build/install), render test-cases.html for user review, run a three-model cross review, synthesize feedback, revise, and submit for confirmation. After confirmation, promote to the long-term knowledge base. Not applicable to: writing test code, executing tests, code review.
End-to-end QA acceptance orchestrator. Triggered when the user asks for feature acceptance, regression testing, quality checks, or systematic testing of a module/flow/branch/PR. As the top-level router, it schedules sub-skills by phase (context collection → risk analysis → case design → script generation → execution and fixing → code review → report generation). You do not write test code yourself, nor do you directly judge quality — you hand each phase to a dedicated sub-skill. Test case confirmation is the only mandatory human gate in the process; the remaining phases connect automatically. Not applicable to: one-off manual testing, pure development/code generation tasks, technical Q&A with no clear acceptance scope.
Repo-local workflow skill for large coding tasks. Initializes .agent/tasks/TASK_ID artifacts, installs project-scoped Codex and Claude subagents, updates AGENTS.md plus the repo's Claude guide file with the workflow, and runs a spec-freeze → build → evidence → verify → fix loop with fresh-session verification.
New to MCP?
From what the protocol is to installing your first server, these answers cover most first questions.
An open protocol that defines how AI applications connect to external tools and data in a uniform way. Clients talk to the model; MCP servers provide tools, resources and prompt templates. They exchange standard messages, so one server can be reused by many clients.