Audits a Claude Code skill for security risks in three modes: before download (from a URL or install command), after download but before install (from a .skill file), or after install (from a local skills directory). Use this skill whenever a user is about to install a skill from any source — including GitHub URLs, git clone commands, npx/npm commands, curl/wget downloads, pip installs, marketplace links, or raw SKILL.md URLs. Also trigger when a user asks "is this skill safe?", "should I trust this skill?", "can you check this before I install it?", "audit this skill", or pastes any link to a skill repository or .skill file. If a user mentions installing ANY skill, proactively offer to audit it first — do not wait for them to ask.

Sets up and repairs JavaScript / TypeScript unit tests - a suite that cannot resolve the project's path aliases (`@lib/...` declared in jsconfig or tsconfig), a regression that shipped because the tests asserted too little, or a module dependency that needs mocking, spying, or fake timers. Jest and Vitest as co-primary frameworks: install, config (`jest.config.js` / `vite.config.ts` test block), mocking (`jest.fn`/`jest.mock`/`jest.spyOn`, `vi.fn`/`vi.mock`/`vi.spyOn`, `__mocks__/`, fake timers), coverage (Istanbul/babel vs v8 providers, `coverageThreshold` gating), watch mode, and CI (`jest --ci`, `vitest run`, JUnit XML). Use when authoring, configuring, or repairing unit tests in a JS/TS project.

Build OpenTelemetry collector configs, instrument services, transform telemetry with OTTL, and debug missing traces, metrics, or logs. Use for OTel/otelcol collector config, OTLP export, SDK instrumentation, sampling, cardinality, TLS/PII controls, Kubernetes/Helm values.yaml deployments, collector health and alerts, and AI coding-agent telemetry (Claude Code, Codex, Gemini CLI, Antigravity, GitHub Copilot, Cursor).

Use when a requirement or an unproven technique must be made clickable before it is built — produces a single self-contained HTML prototype that doubles as a design spike, whose control panel is the open questions. Rebuilds existing screens at high fidelity from real source (structure, copy strings, icons, tokens, each cited file:line; invents only what the requirement adds), derives one control per acceptance criterion or technical unknown, drives real data through a dev-server proxy that also proposes the route shape (live > capture > labeled stub, never invented), verifies every state in a real browser, and reports what the spike settled. Triggers on 'prototype FR-NNN', 'clickable prototype of FR-NNN', 'make this requirement clickable', 'spike this technique'. NOT for inventing UI from a prompt — use a generative-design skill. NOT for production frontend code. NOT the client-confirmation record — that is a spec-playback step. NOT an ADR writer.

Plans and runs time-boxed exploratory testing when tester hours are scarce before a release - one tester with two free 45-minute blocks before code freeze, a high-stakes window such as year-end payroll, or a device and environment the scripted suite never touches. Session-based per the Bachs' SBTM: charters (Explore X with Y to discover Z), 60-90 minute sessions, session sheets with TBS metrics, and the PROOF debrief. Bundles the exploration heuristics as references - Whittaker's seven tours, Kelly's FCC CUTS VIDS, Bach's SFDPOT. Broader than exploratory-charter-author, which writes one charter document: this owns the whole cycle from budgeting the available hours to debriefing what was found. Use when deciding what to explore with the time available, and how to run and record those sessions.

Explains CI test numbers that disagree with what the suite actually did - a 'slowest tests' list dominated by the wrong suite, a release gate or dashboard reading only the summary attributes on the suite element and never the cases below them, or a pass rate that quietly counts skipped tests as passes. Parses JUnit-format XML (the interchange format Jenkins, GitHub Actions, GitLab, Buildkite, and CircleCI all ingest) into per-suite and per-case metrics tables - passed / failed / errored / skipped, time, classname, message, stack - groups failures by classname for trend analysis, and separates new failures from flakes by cross-referencing the `flakyFailure` and rerun elements. Use when a report, gate, or metric derived from test results cannot be trusted.

Remove AI-writing tells and rewrite prose to sound natural and human. Triggers: humanise, humanize, de-AI, deAI, sound natural, less robotic, remove AI tells, AI writing, chatbot tone, Wikipedia AI writing signs, voice match, voice calibration. Uses AskUserQuestion for intake; Read/Write for files; WebSearch/WebFetch when the user wants terminology or usage research; Bash when applying edits in a repo. Outputs: interactive Q&A then rewritten text (and optional brief edit log). Do NOT use for: inventing facts, changing the author's stance, weakening safety or compliance language without explicit instruction, or skipping intake when the user's goals and preservation rules are unclear.

Contribute to ai-slop-gate — an open-source CI/CD policy gate that detects AI-generated code slop, security issues, and compliance violations. Use when adding a new LLM provider (Gemini, Groq, Ollama) or static provider, writing analysis rules, extending the policy engine, working with reporters, fixing compliance sidecar logic, or writing tests. Activate when working with ai_slop_gate/ source tree, policy.yml, snapshot, or GitHub Actions workflows.

Adversarial reviewer personality for architecture discussions. Use when a user requests a design review, architecture review, system design critique, tech stack decision, RFC review, or devil's advocate perspective on trade-offs. Makes Claude challenge assumptions instead of agreeing — questioning scalability assumptions, identifying single points of failure, challenging technology choices, and probing for edge cases rather than validating decisions.

Execute a strict Red-Green-Refactor TDD cycle for a single requirement at a time, in any language or framework. Use when the user provides a business rule, acceptance criterion, or feature requirement and wants a failing test written first, followed by minimum implementation, then a clean refactor. Works for unit tests, integration tests, UI component tests, and API tests across stacks including TypeScript, JavaScript, React, .NET (C#/xUnit/NUnit), Python, Java, and others. Triggered by phrases like "write a test first", "TDD", "red-green-refactor", "behavioral test", "test-driven", "failing test first", or "write the test before the code".

Health check and readiness endpoints for web services — liveness probes, dependency checks, and graceful startup/shutdown. Use when building any backend service that will be deployed behind a load balancer, in containers, or in any environment that monitors service health.

Start here for Tessl Code Review. Use when someone mentions Tessl Code Review or Tessl's AI review, wants automated review of pull requests in a repository, asks to review a diff, branch, or pull request ("review this change", "check this diff for security issues", "what would Code Review say"), asks what Tessl Code Review does, or asks for something and it is not yet clear which Code Review job it is. Works out whether they want to install it on a repository, run a review, change what reviews catch, change which lenses run on which paths, or answer a review's findings. Installing is the Tessl Review GitHub App, which this skill links the user to; the other jobs hand off to create-code-review-lens, respond-to-code-review, or the tessl code review command. The review-* skills in this plugin are lenses that tessl code review runs as reviewer instructions; do not follow one directly to review code, run the command instead.

Author a review lens for Tessl Code Review, the reviewer skill that decides what a review looks for in a diff. Settles the review question and the bar a finding has to clear, drafts the lens, runs it against changes that should and should not trip it, backtests it against changes that already carry review feedback, and packages it as a reference a review can select, either pinned to the version that was backtested or following the newest published version. Use when someone wants their code review to catch something it misses, to stop flagging something it should not, or to write, fork, tune, or debug a code review lens. Not for `tessl review` rubrics, which score skill quality rather than code.

Answer a Tessl Code Review on a pull request the responder authored. Decides what each finding deserves, fixes, refutes, or declines it with a reason, replies on the thread, and keeps the pull request doing what it was opened to do. Use when review feedback has arrived on an open pull request and the responder is the one answering it, for example "address the review", "respond to the findings", "Tessl left comments", "deal with the review comments", "the check is red and there are findings", or when review rounds keep coming and are not converging. Not for performing a review of someone else's change; that is tessl code review.

Vue 3 Composition API patterns that agents commonly get wrong: reactivity pitfalls, composable structure, Pinia setup stores, watch vs computed, storeToRefs, template refs, provide/inject, and accessibility. Use when building or reviewing Vue 3 apps.

SQLite best practices for Node.js with better-sqlite3 — WAL mode, pragma configuration, foreign keys, transactions, migrations, STRICT tables, prepared statements, graceful shutdown, and performance patterns. Use when building or reviewing a Node.js app with SQLite, when you see better-sqlite3 imports, when setting up a new database, when debugging slow queries or SQLITE_BUSY errors, or when migrating from in-memory storage to SQLite.