GITHUB AGENT SKILLS / 技能收录
给你的 AI 助手
装上专业技能
我们从 GitHub 持续收录、审核并分类优质的 Agent Skills，按职业与使用场景整理，复制一行命令即可安装到 Claude Code、Cursor 等智能体。
按职业浏览 Agent Skills
为不同岗位挑选的高频技能
按使用场景浏览 Agent Skills
从你要完成的任务出发
按创作者浏览 Agent Skills
按 GitHub Stars 排序的优秀创作者
Microsoft
@microsoft
openclaw
@openclaw
OpenAI
@openai
The Apache Software Foundation
@apache
GitHub
@github
Anthropic
@anthropics
AutoGPT
@Significant-Gravitas
Garry Tan
@garrytan全部 Skills 196935
azldev-overlays
Read this before adding, changing, or diagnosing any overlay; never edit a spec or rendered file from memory. Explains how to modify a component's RPM spec or loose source files with azldev overlays (semantic patches applied at render time) instead of forking the spec, covering overlay types, the render-and-inspect loop, common failures, pitfalls, and metadata. Triggers include overlay, overlay failed, no match, spec-add-tag, spec-remove-tag, patch-add, fix spec, backport, disable test, prune subpackage, edit spec.
azldev-overlay-metadata
Read this before adding or reviewing an overlay `metadata` table; do not guess the category or upstream status from memory. Explains the overlay metadata schema that documents why an overlay exists and when it can be dropped, covering the required category and upstream-status values, commit/bug URL references, and the per-file overlay metadata block. Triggers include overlay metadata, category, upstream-status, upstream-backport, azl-pruning, azl-branding-policy, needs-upstream-hook, why overlay.
azldev-mock
Read this before testing or inspecting a built RPM; do not drive mock by hand from memory. Explains how to test and inspect built packages in a mock chroot with 'azldev adv mock shell', covering non-interactive (heredoc) and interactive chroot workflows, the -p/--add-package flag, and resetting stale chroot state. Triggers include test package, mock shell, inspect rpm, smoke test, chroot, verify build output.
azldev-image
Read this before building, booting, or configuring an azldev image. Explains the azldev image commands (list, build, boot, test, customize) and the [images.<name>] config (kiwi definition, capabilities, tests, publish); the kiwi XML format itself is upstream KIWI NG. Triggers include image build, image boot, kiwi, container image, VM image, images.toml.
azldev-comp-toml
Read this before authoring, editing, or reviewing a *.comp.toml file; do not work from memory. Explains the azldev component definition format and review workflow, covering component structure, spec sources, build config, release calculation, render options, file organization, overlay hygiene, stale files, disabled tests, and testing verification. Triggers include comp.toml, component config, review component, component hygiene, spec source, upstream-distro, build defines, release calculation, includes.
azldev-build-component
Read this before building a component or diagnosing a build failure; do not guess build flags or the inner loop. Explains how to build, iterate on, and debug an azldev component, covering comp build flags (local-repo, preserve-buildenv), the render/build/test inner loop, diff-sources, and disabling a failing %check via check.skip. Triggers include build component, build failed, build error, inner loop, preserve buildenv, local repo, disable check.
azldev-add-component
Read this before adding or importing a component; follow the workflow instead of guessing. Explains how to add a new component to an azldev distro, covering inspecting the upstream spec, the inline-versus-dedicated-file decision, and validating with render, diff-sources, and build. Triggers include add component, new package, import package, create comp.toml, new component.
vibe
Authoritative reference for Mistral Vibe — the CLI agent you (the model) are running inside. LOAD when the user: - asks anything about Vibe itself, even by indirect name ("this CLI", "this tool", "you"); - wants to change, inspect, or reset their setup; - asks why the agent did or did not act; - asks how to make the CLI do X, where X lives, or what a flag/command/setting does; - asks any meta question about your own behavior; - is unsure whether a command, flag, env var, or file is in scope — this skill is the source of truth. SCOPE: config under `~/.vibe/` and project-local `.vibe/`; `VIBE_*` and `LOG_*` env vars; models and providers; agents and subagents; skills; tools and their permission model; every slash command and CLI flag; hooks; MCP servers; connectors; plugins; trusted folders; `@`-file mentions; logs; themes; voice.
skill-creator
Load this skill before creating, updating, or deleting a Vibe skill, or whenever you plan to add or modify SKILL.md files under a skills directory. It explains Vibe's SKILL.md frontmatter, discovery order, support files, and the permission flow.
import
Import the user's setup from other coding CLIs (Claude Code, Codex, OpenCode) into Vibe — instructions, skills, subagents, commands, hooks, MCP servers, permissions, and plugins. Load when the user wants to switch to Vibe, import or reuse another CLI's configuration, or asks whether a file from another CLI works in Vibe.
create-plugin
Create a Vibe plugin package — the Agent Plugins 1.0 format with optional Vibe extensions for skills, MCP servers, hooks, knowledge, agents, libraries, and connectors. Use when the user wants to create, scaffold, or author a plugin for Mistral Vibe.
worktree
Create, reuse, and clean up git worktrees under $VIBE_HOME/worktrees. Use when the user wants to work in an isolated git worktree, create a worktree for a task, or list/remove existing worktrees.
prompts
暂无简介
write-vibe-tests
Write or refactor Mistral Vibe tests with proper decoupling. Use when adding behavior coverage, testing ports/adapters, replacing brittle mocks, creating fakes, adding characterization tests before refactors, or changing tests under tests/ for vibe/core, vibe/app_server, vibe/acp, tools, config, sessions, skills, hooks, MCP, or setup.
write-vibe-adr
Create or update Architecture Decision Records for the Mistral Vibe Python CLI. Use when a design discussion creates a new architectural constraint, when an undocumented convention causes confusion or review feedback, or when architecture guidance in docs/adr or AGENTS.md must be changed.
instrument-feature-analytics
Plan analytics instrumentation for a feature. Use when implementing any feature — every feature must ship with telemetry. Decides which events and properties the metrics need (funnels, adoption, status flows), checks compatibility with the existing datalake and event registry, and walks through local, staging, and production verification.
vibe-rust-tui
Ratatui UI conventions for the Mistral Vibe Rust CLI (vibe/cli-rust). Use when adding or changing any screen, list, picker, footer hint, keyboard shortcut, list navigation, scrolling or mouse clicks, back/close behavior, search field, selection highlight, color, or onboarding/dialog copy in the Rust TUI.
vibe-python-style
Python coding conventions for Mistral Vibe. Use when writing, reviewing, or refactoring Python code in the Vibe codebase. Covers style, type hints, imports, Pydantic patterns, logging, error handling, and file I/O.