Explore

Build and fix retrieval that actually returns the right passage — structure-aware chunking, one pinned embedding model, lexical plus vector search fused, reranking, and a recall measurement that is run separately from the generator. Use when a RAG system answers wrong or vaguely, when an index is being designed or reindexed, or when someone proposes a prompt change to fix what is really a retrieval miss. Not for prompt or output-quality work once the right passage is already in context, not for agent memory design, and not for choosing a vector database.

Treat everything an agent reads but did not author as data rather than instructions — an explicit trust boundary, a tool set fixed before content is read, consequential calls gated on the user, and destinations that cannot be chosen by the content. Use when an agent reads web pages, retrieved documents, emails, tool results, file contents or another agent's output and can also take actions, when adding retrieval or new tools to an agent, or when reviewing an agent for injection exposure. Not for authentication and authorization design, not for secret management, and never satisfied by "the model did not fall for it".

Write or revise a prompt so it holds up — output contract, instruction placement, examples that earn their place, an escape hatch for bad input — and measure the change against a saved set of cases instead of one good-looking run. Use when a prompt is being authored or patched, when output is inconsistent or the wrong shape, when a model or version changes, or when someone reports a prompt as fixed. Not for scoping an agent's job and tools, not for deciding what material to load into the window, and not for model selection or fine-tuning.

Pick a model per job and degrade sensibly when one fails — a quality bar per call site, candidates compared on the same task set, a readable routing rule, and an explicit retry-versus-fallback path with pinned model ids. Use when cost or latency has become a problem, when adding a cheaper or larger model to an existing system, or when a fallback fires silently and quality drops without anyone noticing. Not for prompt authoring, not for retrieval tuning, and not for capacity or infrastructure planning.

Decide what an agent should remember, which layer holds it, who it is scoped to, and how a stale or contradicted memory is detected and retired. Use when an agent forgets something across sessions, when a memory or persistent-context feature is being designed, or when stored memories have grown noisy, wrong, or are leaking between users. Not for retrieval over a document corpus, not for prompt or context-window packing, and not for conversation transcript storage.

Build an MCP server, or bring an existing one into a project — choosing the transport, deciding which tools, resources and prompts to expose, keeping reads separate from writes, handling auth and credentials, and defining what failure looks like to the model. Use when writing an MCP server, wrapping an internal system as one, or evaluating a third-party server before wiring it in. Not for designing the individual tool signatures inside it (tool-design), and not authorization to install, configure or run any server against real systems.

See what an agent actually did — one trace per run with nested model, tool and retrieval spans, token and latency accounted per step, and failures clustered by mechanism instead of read one at a time. Use when an agent misbehaves in ways you cannot reproduce, when cost or latency is unexplained, when "it sometimes fails" is the whole bug report, or before writing evals when you do not yet know which failures exist. Not for judging whether an output is correct (agent-evals), and not a replacement for the application's own monitoring.

Build an eval suite that can actually detect a regression — cases pulled from real traffic, graders that check properties rather than vibes, a recorded baseline, and per-case diffs in both directions. Use before claiming a prompt, model or agent change is an improvement, when agent behaviour must not regress, or when someone reports "it seems better" after eyeballing a handful of outputs. Not for tracing what one run did (llm-observability), not for testing deterministic code, and never as evidence that behaviour the suite does not measure is safe.

Strip explanatory copy out of user interfaces. Use when writing, editing, or reviewing any UI text, including headings, empty states, button labels, toggle and setting descriptions, helper text, dialogs, banners, permission notices, and onboarding, and whenever a screen leans on sentences to explain what it does. Replaces descriptions of features, side effects, backend behavior, and missing capabilities with specific verbs, controls, icons, and spacing.

Use when automating posts to X/Twitter end to end.

Debug Streamlit frontend and backend changes using make debug with hot-reload. Use when testing code changes, investigating bugs, checking UI behavior, or needing screenshots of the running app.

Apply when you catch yourself writing the same instruction a second time, or notice a recurring correction. Encode the rule as a lint, metadata flag, runtime check, or script instead of more text.

Finds or publishes a pkg.pr.new canary release for a Storybook branch. Use when the user wants the canary package specifier for a branch or needs to trigger the canary workflow manually.

Add or review RustFS `tracing` events with the repository field shape, level policy, privacy boundaries, and guardrails. Use when a change adds or edits a tracing macro/instrumentation site or the logging guardrail script.

Use when a user says "summarise ecosystem results", "summarize this ty ecosystem report", "what changed in this ecosystem run?", or asks to summarise or summarize ty ecosystem results for a Ruff PR from a PR number, PR URL, GitHub ecosystem-results comment, or detailed HTML report.

Use when a user says "minimize this ty ecosystem change", "reproduce this ecosystem result", "investigate a primer difference", "investigate a mypy_primer difference", "investigate a mypy-primer difference", or asks to reproduce, investigate, or minimize behavior changes in ty ecosystem/primer/mypy_primer/mypy-primer projects.

Use when a user says "add a ty diagnostic", "write this new ty diagnostic", "change a ty error message", "review ty diagnostics", or asks to add, update, or review ty checks, diagnostic messages, subdiagnostics, or concise output behavior.

Use when modifying or reviewing Qwik Router code under packages/qwik-router, including runtime routing, buildtime route generation, middleware, adapters, SSG, markdown/MDX handling, or router tests.

Use when modifying or reviewing the Qwik optimizer under packages/optimizer, Rust transform code, WASM/NAPI bindings, optimizer snapshots, or optimizer-facing runtime behavior.

Use when editing Qwik's .ruler guidance, adding or changing rules or skills, keeping AI guidance from going stale, updating assistant setup docs, or answering how Ruler should generate assistant-native guidance, skills, config, or policy for this repo.

Use when creating, modifying, debugging, or running Qwik Playwright e2e tests under e2e/, including router, adapters, docs, CLI, and React integration suites.

Use when writing, modifying, or reviewing Qwik docs content or docs-site code under packages/docs, including docs routes, MDX content, generated LLM outputs, docs build behavior, or docs-specific e2e tests.

Use when modifying or reviewing Qwik core package code under packages/qwik, especially reactive primitives, signals, VNodes, cursor behavior, QRLs, optimizer-facing runtime behavior, or Qwik core tests.

Writing `as` in TypeScript or TSX production code, modifying a file that contains a bare `as` cast, silencing a type error with a cast, encountering `as unknown as`, or reviewing a cast site.

Run the tests that cover a change in the pnpm repository, in the Rust workspace (pnpm/, pnpr/) or the TypeScript CLI (pnpm11/), and recognize the cases where a scoped run passes without testing anything. Use whenever verifying a change before committing or pushing, or when deciding what to run after an edit.

Take a change through a pull request in the pnpm repository — opening it, then staying with it after every push until CI is green and the review round is quiet. Use when opening a PR, after pushing to one, when a check fails, or when review comments arrive.

REQUIRED for end-user customization of Linux desktop, window manager, or system config. Use when editing ~/.config/hypr/, ~/.config/omarchy/, ~/.config/alacritty/, ~/.config/foot/, ~/.config/kitty/, or ~/.config/ghostty/. Triggers: Hyprland, window rules, animations, keybindings, monitors, gaps, borders, blur, opacity, omarchy-shell, bar, terminal config, themes, background, night light, idle, lock screen, screenshots, reminders, layer rules, workspace settings, display config, and user-facing omarchy commands. Excludes Omarchy source development through `omarchy dev link` workflows.

Generate and maintain the system recap block in a PR description - a GitHub-rendered visual summary of which system primitives a change touches, how risky it is, and what changed. Prefer mermaid sequence diagrams for the change; pick another graph type when it explains the diff better. Use when planning a non-trivial change (plan mode), when creating or updating a pull request (recap mode), or when the user asks for a visual recap, visual plan, system review, or PR recap.

Build and review Remix 3 applications using the `remix` npm package and subpath imports. Use when working on Remix app structure, routes, controllers, middleware, validation, data access, auth, sessions, file uploads, server setup, UI components, hydration, navigation, or tests.

Discover, wait for, sign in, create specific user data, and assert a PR preview deploy. Use on medium or high risk PRs, after pushing a ready-for-review PR, or when the user asks to test the preview URL.

Drive and verify the Kody app with a Feature Map and one CLI. Use when changing UI, account routes, preview deploys, or proving a Cloud Agent change with a real origin, session, and /health SHA.

Prepares, publishes, verifies, and curates Hunk releases. Use for release metadata, benchmarks, tags, publishing, release videos, backports, or recovery.

Interacts with live Hunk diff review sessions via CLI. Inspects review focus, navigates files, hunks, and exact lines, reloads session contents, adds inline review comments, and paints attention marks on character ranges. Use when the user has a Hunk session running or wants to review diffs interactively.

Maps the `hunkdiff/extension` authoring surface for Hunk, the terminal diff viewer — hiding or reordering reviewed files, docked panes, alternate file views, commands and key bindings, dialogs, workspace writes, themes, syntax languages, VCS backends, lifecycle events. Use when writing, debugging, or installing a Hunk extension, or when a request asks Hunk itself to behave differently. Not for reviewing a diff in a live session — that is hunk-review.

Control Herdr, a terminal multiplexer for coding agents. Use only when the user explicitly mentions Herdr or asks to use Herdr to inspect or control panes, tabs, workspaces, commands, or another agent. Do not use merely because a task could benefit from a background terminal, delegation, or parallel work. Requires HERDR_ENV=1.

Write unit and E2E tests for Grafana visualization panels and viz utilities to the conventions this repo expects. Use when adding, backfilling, or reviewing tests for panels (barchart, timeseries, table, xychart, heatmap, canvas, etc.), grafana-ui viz components (Table, uPlot, VizLegend, VizTooltip), or grafana-data viz utils; when a panel test only asserts "it rendered" or "it's defined"; when reviewing AI-generated panel tests for slop; or when a canvas/rendering test is flaky.

Write unit and E2E tests for Grafana frontend code (React/TypeScript, any package or feature area) to the conventions this repo expects. Use when adding, backfilling, or reviewing frontend tests; when a test only asserts "it rendered" or "it's defined"; when reviewing AI-generated tests for slop; or when a frontend test is flaky. For visualization panels and grafana-ui viz components specifically, also load the `panel-testing-strategy` skill.

Guide for performing Node.js version upgrades in the Electron project. Use when working on the roller/node/main branch to fix patch conflicts during `e sync --3`. Covers the patch application workflow, conflict resolution, analyzing upstream Node.js changes, building, running the Node.js test suite, and proper commit formatting for patch fixes.

Guide for performing Chromium version upgrades in the Electron project. Use when working on the roller/chromium/main branch to fix patch conflicts during `e sync --3`. Covers the patch application workflow, conflict resolution, analyzing upstream Chromium changes, and proper commit formatting for patch fixes.

Use before opening a PR, or whenever asked to self-review a diffusers contribution. Applies the same rubric as the `@claude` CI (checks the diff against references/review-rules.md, traces call paths for dead code). Reports findings grouped by severity, flagging what to fix before submitting (blocking issues + dead code) vs what to leave for the actual review. Report-only — does not edit files.

Use when adding a new model or pipeline to diffusers, setting up file structure for a new model, converting a pipeline to modular format, or converting weights for a new version of an already-supported model.

Use when the user wants to run a diffusers pipeline from a terminal (one-off generation, batch jobs, smoke-testing a new model), run on HF Sandbox hardware via `--remote`, introspect a pipeline's input schema before calling it, or attach a LoRA at inference time. Prefer this over writing ad-hoc Python scripts for generation tasks.

Use this skill when selecting or running Biome test fixtures, quick tests, `insta` snapshot workflows, expectation comments, orphan checks, or required code generators. Do not use for subsystem implementation design.

Use this skill whenever writing or editing Rust `//`, `///`, or `//!` comments in Biome, including comments added incidentally and end-user rustdoc inside lint/assist declarations. For lint/assist rustdoc, also load lint-rule-development for content requirements. Do not use for formatter handling of comments in user code.

Use this skill when a Biome change may affect users and you must decide whether it needs a changeset, choose the release level, or create and edit `.changeset/*.md` release-note text. Do not use for implementation details or PR descriptions.

Use only for reviewing completed Biome PRs, branches, commit ranges, diffs, or working trees against business logic and requirements. Excludes broad code-quality and process audits, triage, reproduction, and implementation.

How to write JSDoc (/** */) and inline (//) comments in the Astro codebase, for contributors reading the source — not end users. Use whenever writing or editing comments in .ts/.js source, including comments added incidentally while fixing bugs or building features. Does not cover the @docs-generated config/error reference.

Prepare Anarlog Nightly builds and promote tested desktop stable versions with current CLI, local and hosted MCP, API, agent packages, and documentation. Deploy any required hosted services during the release. Validate and merge release updates before publishing. Distribute mobile builds when requested.

Execute Anarlog work immediately while recording issues, decisions, progress, and lessons in Linear. Use for Anarlog repository or Anarlog desktop, web, mobile, and API work, including related worktrees and ANLG issues. Explicit brainstorming stays discussion-first. Do not use for unrelated repositories or meeting-data queries.

Core agent-browser usage guide. Read this before running any agent-browser commands. Covers the snapshot-and-ref workflow, navigating pages, interacting with elements (click, fill, type, select), extracting text and data, taking screenshots, managing tabs, handling forms and auth, waiting for content, running multiple browser sessions in parallel, and troubleshooting common failures. Use when the user asks to interact with a website, fill a form, click something, extract data, take a screenshot, log into a site, test a web app, or automate any browser task.

Use when adding A2UI rendering to any AG-UI-supported framework or custom AG-UI application, scaffolding an AG-UI app that should render A2UI, adapting an AG-UI integration to emit A2UI surfaces, or wiring the AG-UI A2UI middleware/toolkit with a compatible renderer.

Evaluate an open source project's AGENTS.md and produce a corpus entry for the /agents-md directory. Use when adding a project to the directory, refreshing an existing entry, or running a batch of candidate repositories.

Build, test or lint BashCut and retain full logs.

Pick the output format that makes an explanation easiest to understand, following Karpathy's understanding ladder — (1) plain controlled text, (2) diagram, (3) interactive HTML page, (4) 3Blue1Brown-style explainer video. Classify the content (definition/steps, process/causality, parameter→outcome, unfolding derivation), recommend the lowest rung that fully answers, then produce it. Works in English and Chinese. Use when the user says "explain this clearly", "help me understand", "draw a diagram", "make it interactive", "make an explainer video", "what's the best way to explain X", "understanding ladder", "Karpathy ladder", or 「讲清楚」「帮我理解」「画个图」「做个交互页」「做个讲解视频」「用哪种方式讲最好懂」「理解阶梯」; also when explaining a non-trivial concept, mechanism, algorithm, or an AI agent's output.

用简明中文写解释、步骤和总结：一句一事、一词一义、主动句、不铺垫，内容一点不删。写中文的技术解释、操作步骤、学习笔记、报告，或者解释 AI/agent 的产出时使用。用户说「说人话」「写清楚点」「太绕了」「看不懂」「简明中文」「用 STE 的写法」「改得好懂一点」时也使用。受 ASD-STE100 启发，不是它的中文版。

Run a daily job search and auto-apply session for the candidate in profile/profile.md. Use when the user runs /seekter-run or asks to start applications, search for jobs, run today's scan, or apply to postings.

Summarise the job search from the markdown tracker - funnel, response rate, what's working, where applications come from, what's pending on the user. Use when the user runs /seekter-report or asks how the search is going, for weekly numbers, or what to change.

Update the application tracker. Record replies (rejection, screening, interview, offer), log an application the user made by hand, or sweep the inbox for replies. Use when the user runs /seekter-log, says a company replied or rejected them, or asks to check emails for responses.

Set up Seekter for a new candidate. Interviews the user one question at a time and writes profile/profile.md, profile/settings.json and profile/documents/. Use when the user runs /seekter-init, says "set up seekter", or when profile/profile.md is missing.

Ship the Seekter kit to git. Branch, commit and push the tracked, person-independent files (skills, references, scripts, templates) after a run has taught the kit something. Use when the user runs /seekter-git or asks to commit, push, or open a PR for the changes made to Seekter itself.