claude-plugins

Org-internal engineering standards. Invoke when scaffolding a repo, auditing one, setting up CI, or configuring `Cargo.toml`, `rust-toolchain.toml`, `justfile`, `.editorconfig`, `.markdownlint-cli2.yaml`, `tsconfig.json`, `package.json`, `pnpm-lock.yaml`, `bunfig.toml`, `pyproject.toml`, `uv.lock`, `.python-version`, `lefthook.yml`, or `*.tf`. Also for `axum`, `utoipa`, `async-graphql`, `markdownlint-cli2`, `uv`, `ruff`, `pyright`, `pytest`, `eslint`, `prettier`, or Node package-manager setup (pnpm is the org default). Fully documented: Rust (workspace inheritance, MSRV, `just`, coverage, test tiers, Axum+utoipa, published-crate conventions, async-graphql), Python (uv workspaces, `src` layout, ruff, pyright strict, pytest tiers), TypeScript/Node (tsconfig, project references, npm scripts), Terraform (workspaces, backend, naming). Only Bun is a stub — invoke anyway so the user defines the convention rather than getting an improvised one.

Expert guidance for the Model Context Protocol (MCP), the JSON-RPC 2.0 protocol connecting LLM apps to external tools and data. Covers spec versions 2024-11-05 through 2025-11-25 (architecture, transports, Resources, Prompts, Tools, Sampling, Roots, Elicitation, Tasks, lifecycle, OAuth 2.1, utilities) plus the official language SDKs: the Rust SDK `rmcp` (full guide — `ServerHandler`/`ClientHandler`, `#[tool_router]`/`#[tool_handler]`/`#[task_handler]` macros, `StreamableHttpService`, Cargo features, SEP-1686 tasks, `tokio::io::duplex` test harness) and the TypeScript SDK `@modelcontextprotocol/sdk` (incl. the `pkce-challenge` Vite/bundler resolver failure). Use when building MCP servers or clients in any language, working with transports or OAuth, or debugging SDK-specific issues. Always invoke for questions mentioning MCP, modelcontextprotocol, `rmcp`, tools/list, tools/call, sampling/createMessage, elicitation/create, Streamable HTTP, Mcp-Session-Id, `pkce-challenge`, or `@modelcontextprotocol/sdk`.

Audit and improve a project's persistent memory across BOTH CLAUDE.md files and the .claude/rules/ directory. Use when the user asks to check, audit, review, update, improve, fix, organize, or restructure their CLAUDE.md or rules; when CLAUDE.md has grown too long and should be split into path-scoped rules; when setting up .claude/rules/; or for "CLAUDE.md maintenance" and "project memory optimization". Covers every scope — project ./CLAUDE.md and ./.claude/CLAUDE.md, nested CLAUDE.md, ./CLAUDE.local.md, user ~/.claude/ CLAUDE.md, and rules in .claude/rules/ and ~/.claude/rules/. Trigger even without exact wording: "is my CLAUDE.md up to date", "my CLAUDE.md is too big", "split this into rules", "review my .claude/rules", "clean up project memory" all count.

Scaffold a project's persistent memory the way Claude Code's built-in /init would, but as a HYBRID layout instead of one monolithic file: a lean root CLAUDE.md holding only repo-wide essentials, PLUS path-scoped .claude/rules/*.md for area-specific conventions. The rules-aware analog of /init. Run manually with /claude-md-management-reloaded:init-claude-md on a repo that has little or no memory yet: it analyzes build/test/lint commands and big-picture architecture, decides what stays in CLAUDE.md versus what becomes a path-scoped rule, derives and verifies paths: globs against real files, and writes the files only after you approve. If memory already exists it proposes improvements instead of overwriting. For auditing memory that already exists, use the companion claude-md-improver skill.

Capture learnings from the current session into project memory, routing each one to the right place: a project CLAUDE.md, a path-scoped .claude/rules/ file, a gitignored CLAUDE.local.md, or user-scope ~/.claude memory. Use at the end of a session, or whenever something is worth remembering for next time — a build command discovered, a gotcha hit, a convention confirmed, a correction the user made. Invoke directly with /revise-claude-md, or let it run when the user says "capture what we learned", "update CLAUDE.md with this", "remember this for the project", "add this gotcha", or "write this down for next time". For auditing or reorganizing memory that already exists (not capturing new learnings), use the companion claude-md-improver skill instead.

Capture an agent's wrong, stale, unsupported, or mis-routed answer from the current conversation into a standalone eval case in the project's JSONL eval set. Run manually with /capture-eval-case right after you spot a bad answer worth regression-testing; it reads the failing exchange from the live conversation, so it runs in the main session, not a subagent.

Set up, configure, and debug Lefthook, the fast polyglot Git hooks manager. Covers installation (npm, Homebrew, Go, etc.), `lefthook install`, authoring `lefthook.yml` (hooks, the modern `jobs` syntax plus classic `commands`/`scripts`), file-list templates (`{staged_files}`, `{push_files}`, `{all_files}`, positional `{1}`), `glob`/`exclude`/`root` filtering, `parallel` vs `piped` execution, auto-staging linter fixes with `stage_fixed`, `tags`, `skip`/`only` conditions, job `group`s, local overrides (`lefthook-local.yml`), `extends`/`remotes`, and the CLI (`install`, `run`, `add`, `validate`, `dump`). Use whenever the user wants to add or configure Git hooks, run linters/formatters/tests on commit or push, lint staged files, wire up commitlint/eslint/prettier/rubocop, migrate from Husky or pre-commit, or troubleshoot a `lefthook.yml` — even when they don't say "lefthook" by name. Trigger on lefthook, lefthook.yml, git hooks, pre-commit/pre-push/commit-msg hooks, a Husky alternative, or staged-file linting.

Expert guidance for the A2A (Agent2Agent) Protocol — an open HTTP-based protocol for independent, opaque AI agents to collaborate as peers. Covers v1.0: data model (Agent Card, Task, Message, Part, Artifact, Extension); operations (`SendMessage`, `SendStreamingMessage`, `GetTask`, `ListTasks`, `CancelTask`, `SubscribeToTask`, the `*TaskPushNotificationConfig` family, `GetExtendedAgentCard`); task lifecycle and multi-turn flows; three protocol bindings (JSON-RPC, gRPC, HTTP+JSON/REST) and custom bindings; agent discovery (well-known URI, registries, signed Agent Cards); enterprise security (TLS, OAuth 2.0 / OIDC / mTLS, in-task authorization); SSE streaming and webhook push notifications; the extension framework; A2A↔MCP relationship; and the six SDKs (`a2a-python`, `a2a-js`, `a2a-java`, `a2a-go`, `a2a-dotnet`, `a2a-rs`). Always invoke for A2A, Agent2Agent, agent card, A2A tasks / messages / artifacts / parts, push notification configs, A2A extensions, Agent Card signing, or any of the six SDK package names.

Eval-driven prompt refinement that runs entirely inside Claude Code via the Agent/Task tool — no Python, no SDK, no API key. Each candidate run and each judge call executes in an isolated subagent with a fresh context window, so samples are independently graded and the main session stays focused on synthesis and iteration. Trivially parallel: spawn N candidate + M judge subagents in one assistant message. Invoke when the user wants to evaluate, A/B test, regress-test, or iterate on a prompt directly inside Claude Code, especially when they reference subagents, the Task/Agent tool, or "test this prompt without writing code". Phrases like "use Claude Code to evaluate this prompt", "spawn subagents to test", "parallel-test these variants", "A/B these prompts in Claude Code", "grade this rubric with subagents", or "iterate this prompt with fresh contexts" qualify. Pairs with the broader `prompt-evaluation` skill for shared dataset-design and binary-judge methodology.

Eval-driven prompt refinement for Anthropic / Claude API prompts. Turn vibes-based prompt tweaking into a measurable loop: look at real failures, build a dataset, pick a grading approach (code-graded, model-graded, or both), scaffold a runnable eval (Anthropic SDK, `promptfoo`, or Claude Console), run it, analyze failures by category, propose targeted edits, re-run, compare. Invoke whenever the user wants to evaluate, improve, compare, A/B test, regress-test, or iterate on a prompt — even if they don't say "eval". Phrases like "is this prompt good?", "make this prompt better", "compare these two prompts", "my prompt fails on X", "tests for this prompt", "edge cases this classifier misses", "switch to Haiku without regressions", "evaluate this RAG answer", "grade this agent's tool use" all qualify. Covers code-graded, model-graded (LLM-as-judge), RAG-specific (faithfulness, answer-relevance), tool-use / agent evals, dataset design, and production patterns (capability vs regression suites, CI/CD).

Maintains a Known Error Database (KEDB) of documented errors, symptoms, workarounds, root causes, and solutions. READ mode (autonomous): on any error, stack trace, test/build failure, or unexpected behavior, consult `kedb-index.md` before investigating from scratch. Triggers: "this error", "is this a known issue", "check KEDB", "known error database", "have we seen this before". WRITE mode (human-invoked only): create or update entries via `kedb-template.md` when asked to "add to KEDB", "document this issue", "record this fix", "log this error", "save this workaround", or "create a KEDB entry". Always update `kedb-index.md` after writing. Never auto-create entries.

Write, format, and review conventional commit messages following the Conventional Commits 1.0.0 spec and this project's house rules. Use this skill whenever the user asks you to write a commit message, format or fix a commit message, check whether a commit message is valid, explain the commit convention, suggest a type or scope, or describe what changes to make before committing. Trigger even when the user doesn't say "conventional commits" explicitly — phrases like "how should I word this commit", "what type is this", "write a commit for", "is this commit message ok", or just pasting a raw description and asking for a commit all count.

Expert guidance for Qwik (v1 and v2) and its meta-framework — Qwik City in v1, Qwik Router in v2 — covering resumability, components, signals, stores, tasks, context, QRLs, file-based routing, route loaders/actions, middleware, endpoints, layouts, async data (useResource$/useAsync$/Suspense), v1→v2 migration, and deployment. Use whenever someone writes, debugs, or reviews Qwik code, asks about useSignal, useStore, useTask$, useAsync$, routeLoader$, routeAction$, component$, the $ suffix, resumability vs hydration, migrating v1 to v2, server-side data fetching, REST/JSON endpoints, middleware, or deployment. Always invoke for any question mentioning Qwik, Qwik City, Qwik Router, QRL, routeLoader$, routeAction$, useVisibleTask$, useAsync$, noSerialize, or the resumable architecture.

Expert guidance for implementing the View Transition API — covering same-document (SPA) transitions with `document.startViewTransition()`, cross-document (MPA) transitions with `@view-transition`, customizing animations via CSS pseudo-elements (`::view-transition-old`, `::view-transition-new`, `::view-transition-group`), per-element animations with `view-transition-name`, JavaScript control via the `ViewTransition` promises (`ready`, `finished`, `updateCallbackDone`), context-aware transition types with `:active-view-transition-type()`, and graceful fallbacks for unsupported browsers. Use this skill when someone wants page transition animations, shared-element transitions, slide/fade/circular-reveal effects, or asks about `startViewTransition`, `@view-transition`, `view-transition-name`, `::view-transition-*` pseudo-elements, or the `ViewTransition` object — even if they just say "smooth page transitions" or "animate between routes".

Expert guidance for building browser extensions with WXT — covering project setup, file-based entrypoints (background, content scripts, popup, options, side panel), the unified browser API, auto-imports, manifest configuration, storage, content script UIs (integrated, shadow root, iframe), frontend frameworks (React, Vue, Svelte, Solid), multi-browser targeting (Chrome, Firefox, Safari, Edge), MV2/MV3 compatibility, and publishing. Use this skill whenever someone is building, debugging, or reviewing a WXT extension, asking how entrypoints work, trying to add a popup or content script, using `defineBackground`, `defineContentScript`, `createShadowRootUi`, `storage`, `wxt.config.ts`, or wondering why their extension code breaks at build time. Always invoke this skill for any question that mentions WXT, wxt.config.ts, defineBackground, defineContentScript, or refers to building a Chrome/Firefox extension using WXT, even if the question seems simple.

Markdown linting and automated fixing using markdownlint-cli2. Use when Claude needs to: (1) Check markdown files for style issues, (2) Fix markdown formatting problems, (3) Ensure markdown follows best practices, (4) Validate markdown documents, or (5) Apply consistent markdown styling

Create diagrams and visualizations using Mermaid syntax. Use when users request flowcharts, sequence diagrams, class diagrams, state diagrams, entity relationship diagrams, Gantt charts, pie charts, mindmaps, timelines, user journey maps, Git graphs, quadrant charts, or requirement diagrams. Also use when users want to visualize processes, workflows, systems, data structures, or relationships.

Expert guidance for the Toasty Rust ORM (v0.7): `#[derive(toasty::Model)]` with `#[key]`, `#[auto]`, `#[unique]`, `#[index]`, `#[has_many]`, `#[belongs_to]`, `#[has_one]`, `#[version]`; `Deferred` for lazy relations/columns vs. bare types for eager; multi-step `via` relations; `create!`, `update!`, `find_by_*`, `filter_*` macros; increment/decrement/add/subtract update ops; `toasty::Json`, embedded types, scalar `Vec` arrays; raw SQL via `toasty::sql::*`; `tracing`; batch ops; transactions; per-driver behavior for SQLite, Turso, PostgreSQL, MySQL, DynamoDB (`.ilike()` is PostgreSQL-only). Internals: app/db schema, `schema::diff::Schema`, the query pipeline (Simplify → Lower → Plan → Execute), the driver trait. Always invoke for any question mentioning Toasty, `toasty::Model`, `toasty::Db`, `toasty::Deferred`, `toasty::Json`, `toasty::create!`, `toasty::update!`, `toasty::sql`, code under `submodules/toasty/`, `crates/toasty-app/`, or any Rust code importing `toasty`.