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 192262
tailwind-design-system
Tailwind CSS v4 design system architecture: CSS-first `@theme` configuration, the brand/semantic/component token hierarchy, OKLCH colour, CVA component variants, native dark mode. TRIGGER — load BEFORE writing the CSS, not after: a `@theme`, `@custom-variant` or `@import "tailwindcss"` block is being written or changed; a design token, CSS custom property or colour scale is being added or renamed; a component library or shared variant set is being built; a project is migrating from tailwind.config.* to v4 CSS-first config. Trigger on plain requests — "add a brand colour", "set up dark mode", "standardise these buttons", "upgrade us to Tailwind v4" — the user will not say "design tokens"; the theme file is the trigger. For day-to-day `className=` work inside an existing token set, use tailwind-shadcn instead.
swift-testing
How Swift tests are written in these repos: Swift Testing (`@Test`, `#expect`, `#require`), suites, traits and tags, parameterized tests, async and actor-isolated tests, confirmations, testing `@Observable` models and SwiftData, and migrating from XCTest. TRIGGER — load BEFORE writing, editing or reviewing any Swift test file: a path under a `*Tests/` or `*UITests/` directory, a file ending `Tests.swift`/`Test.swift`, or one that imports `Testing` or `XCTest`. Also when the task says `@Test`, `#expect`, XCTestCase, XCTest migration, test plan, flaky test or "write a test" in a Swift or Xcode project. Plain requests count: "add tests for this model", "fix the failing test", or a feature task whose last step is testing it. Load alongside swift-ios, not instead of it. SKIP when no Swift test code is written or judged.
swift-ios
SwiftUI and iOS engineering standards: state and data flow, view structure, navigation, layout, modern and deprecated APIs, accessibility, animation, performance, Swift concurrency, SwiftData and Liquid Glass. TRIGGER — load BEFORE writing or editing Swift, not after: any .swift, Package.swift, .xcodeproj or .xcworkspace file is touched, SwiftUI, iOS, iPadOS, Xcode or Swift concurrency is named, or the working directory holds an Xcode project or Swift package and the task is implementation, refactor, review or test-writing. Plain requests in an iOS repo ("add a screen", "fix this view", "why does this list flicker", "make this async") count; the user will not say "SwiftUI best practices". Load it for test files too, alongside swift-testing, and even when another skill (tdd, simplify) is active. SKIP only when no Swift file is involved and Swift is not named.
record-decision
Capture a design or architecture decision as an ADR in docs/adr/ and update CONTEXT.md if terminology is affected. Use when the user says "document this decision", "record this design choice", "write an ADR", "capture the decision to X", or after any implementation where a non-obvious trade-off was made. Also trigger after refactors or design changes where the *why* isn't visible in the code: if a decision just landed that meets the ADR criteria below, offer to record it.
readme-generator
Generates a simple, honest README.md for the current project — what it does and why, how to install, how to use it with a minimal example. Use for "write a readme", "generate the readme", "refresh the readme".
postgres-best-practices
Postgres schema and query rules, independent of the calling language. TRIGGER — load BEFORE writing or editing a .sql file, a migration, or any schema, index, constraint or query change against Postgres: new tables, foreign keys, status columns, claim or lease queries, backfills, ON CONFLICT upserts. SKIP for MySQL, SQLite and other engines, and for code that never touches SQL.
improve-codebase-architecture
Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.
htmx-go-templates
htmx on Go html/template: how a handler picks page, fragment or redirect, how templates carry hx-* attributes, where client JS lives, and how errors and polling surface. TRIGGER — load BEFORE writing, not after: a .tmpl or .gohtml file is created or edited; an hx-* attribute or HX-* header is added or changed; a Go handler calls ExecuteTemplate or reads HX-Request; the prompt names htmx, hx-get, hx-swap, a fragment, partial, swap target, polling or an htmx event. Trigger on plain requests in a Go + htmx repo — "add a page", "make this form inline", "refresh this every 5s", "why doesn't the error show". Load alongside go-idiomatic. SKIP for templ components, JSON APIs and React or Solid UIs.
goquery-parsing
Builds robust, maintainable Go HTML parsers with goquery — stable CSS selectors, typed structs, and parsers that survive minor markup changes. TRIGGER — load BEFORE writing the parser, not after: raw HTML or a .html file is in context and structured data is wanted out of it; goquery is imported or `Find(`/`Attr(`/`Each(` is being written; the prompt names goquery, scraper, parser, extract, scrape, crawl, or selector alongside HTML or a page. Trigger on plain requests — "pull the prices off this page", "get these fields out of this markup", "turn this listing into structs" — the user will not name goquery; the HTML plus a Go repo is the trigger. SKIP when the extraction target is JSON or an API response rather than markup, or when the project is not Go.
go-testing
How Go tests are written in these repos: assertions, tables, test doubles, helpers, async waits, golden files, fuzzing, benchmarks, and integration tests against a real Postgres via the bundled pgtest helper (one shared testcontainer, a fresh database per test). TRIGGER — load BEFORE writing, editing or reviewing any *_test.go file, testdata/ golden file, fuzz target or benchmark, or when the task says go test, test helper, fake, mock, stub, table test, testcontainers, TestMain, test database, flaky test or coverage in a Go repo. Plain requests count: "write the tests", "add a test for this", "fix the failing test", or a feature task whose last step is testing it. Load alongside go-idiomatic and tdd, not instead of them. SKIP when no Go test code is written or judged.
go-idiomatic
Go engineering standards for this repo — package layout, error handling, logging, testing, concurrency and design patterns. TRIGGER — load BEFORE writing or editing Go, not after: any .go, go.mod, go.sum or go.work file is touched, Go or Golang is named, or the working directory contains go.mod and the task is implementation, refactor, review or test-writing. Plain feature requests in a Go repo ("add an endpoint", "extract a helper", "write a test for this") count; the user will not say "idiomatic". Load it even when another skill (tdd, simplify) is active. SKIP only when no Go file is involved and Go is not named.
frontend-best-practices
Frontend engineering standards — component architecture, state, async, forms, accessibility, performance and TypeScript discipline. Detects the project's framework and loads only the matching guidance. TRIGGER — load BEFORE writing or editing frontend code, not after: any .tsx, .jsx, .vue, .svelte, or component/hook file is being created or edited; the prompt names a component, hook, prop, state, form, modal, route, page, React, Next, Solid, SolidStart, solid-js, signal, useState, useEffect, createSignal, createStore, createResource, createAsync, <For>, <Show>, store, context, a11y, or web vitals. Trigger on plain feature requests in a frontend repo — "add a button", "wire up this form", "make this load faster", "fix this rerender" — the user will not say "best practices"; the component file is the trigger. Load it even when another skill (tdd, impeccable, simplify) is already active. SKIP only for backend-only work with no UI file touched.
compare-tools
Use whenever the user needs to *choose* a technology, library or tool for this project: "which library should I use", "help me pick a tool", "what's the best X for this", "compare these technologies", "should I use X or Y", "what are my options for Z". Trigger even when it isn't phrased as a comparison. Explores the codebase, aligns on priorities (community support, maintenance, lock-in, extensibility), researches the market, and writes a report to ./ideas/ with every viable option, doc links, a comparison table, and a ranked list scored out of 100 against the user's own priorities.
codebase-design
Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.
code-review
Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X". Reviews changes since a fixed point (commit, branch, tag, or merge-base) along two parallel axes — Standards (does this follow the repo's documented coding standards?) and Contract (does this match the ticket and the feature's frozen contract?) — reported side by side. Also defines the Journey axis, which /fleet reconcile applies to a completed slice. For whole-system design assessment rather than a diff, use architecture-review.
clean-comments
Remove comments that fail ~/.claude/rules/comments.md from source files. Use when user wants to clean comments, remove redundant comments, strip obvious comments, or run /clean-comments on staged files before committing.
architecture-review
Use when the user wants an architecture review, a design health check, a staff-level read on architectural risk, or an assessment of coupling and cohesion: "review my architecture", "is this codebase well-architected", "architecture health check", "where's the design risk", "design review before we scale". Maps the system, detects the stack, fans out seven parallel reviewers (one per quality dimension — boundaries, coupling, data flow, failure modes, information hiding), and synthesises a verdict plus a prioritised roadmap. Diagnoses only — does not refactor. For a diff or PR, use code-review; to actually apply refactors, use improve-codebase-architecture.
app-performance-testing
Investigate why this app's HTTP API endpoints are slow and how to make them faster. Discovers the endpoints, measures their response times, works out which layer the time goes to (network, middleware, handler code, database, external calls, cache, serialization) using Grafana metrics, traces, logs and profiles plus the code, and produces a ranked list of fixes. Use whenever the user asks why the app or an endpoint is slow, wants the API to feel snappier, mentions latency, p95, slow queries, N+1, or wants a performance check or audit of the backend, even if they don't say "performance testing".