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 196628
reflect
Review a session's transcripts (the main agent and every subagent it spawned) for confusion and waste, such as hallucinated paths and symbols, repeated failures, edit churn, user corrections, expensive or redundant tool calls, long hunts for a file and review misses; audit each repo it touched for missing guardrails and instruction bloat; then file GitHub issues for the fixes the user approves. Also reports instruction-file metrics. Use only when invoked as /reflect, /reflect <session id>, /reflect metrics or /reflect status.
openspec-continue-change
Continue working on an OpenSpec change by creating the next artifact. Use when the user wants to progress their change, create the next artifact, or continue their workflow.
openspec-bulk-archive-change
Archive multiple completed changes at once. Use when archiving several parallel changes.
find-skills
Not for building skills — for finding them. Use when the intent is to discover, search, or inventory what agent skills already exist for a topic. The user wants to know "what's out there for X" rather than "make me something." Triggers on: "find a skill for X", "skill search: X", "what skills exist for X", "discover skills for X", "is there already a skill for X", "before I build this, has someone done it?", or any pre-build audit. Also trigger proactively before any skill-creator session when the user hasn't searched yet — finding what exists prevents duplicate effort. Output is a ranked table plus a thematic synthesis document, never a new skill.
openspec-archive-change
Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.
openspec-apply-change
Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
update-project-docs
Sync documentation with the codebase and generate token-lean architecture codemaps. Use when user wants to update docs, sync documentation, generate codemaps, update architecture docs, run /update-docs, or run /update-codemaps.
testing-policy-creator
Writes, or brings up to date, a repo's own testing-policy skill at .claude/skills/testing-policy/SKILL.md: which code gets which kind of test, with which doubles, asserting what, and why. Surveys the codebase for its layers and boundaries, proposes a draft map, grills the user on it row by row, then lists the tests and boundaries that break the policy. Use when the user says "create a testing policy", "write our testing-policy skill", "decide what we test in this repo", "which tests should we keep", "our tests are a mess, set some rules", "purge tests that don't conform", or asks to update an existing testing policy. Not for writing a test (use the language's testing skill and tdd) or reviewing a diff.
tdd
Use when implementing any feature or fixing any bug. TDD is the default — not an optional approach. Trigger on any implementation work, not just when the user explicitly mentions TDD.
tailwind-shadcn
shadcn/ui + Tailwind CSS standards. Auto-detects the framework — React uses the shadcn CLI with Base UI primitives, SolidJS uses shadcn-solid with Kobalte. TRIGGER — load BEFORE writing or editing any styling, not after: a `class=` or `className=` attribute is being added or changed; tailwind.config.*, globals.css, or anything under components/ui/ is touched; the prompt names Tailwind, shadcn, a variant, a design token, a CSS variable, a responsive breakpoint, dark mode, or a colour; or an arbitrary bracket value like [24px] or [#1a1a1a] is about to be written. Trigger on plain requests — "style this", "add a colour", "make this responsive", "match the other buttons" — the user will not say "Tailwind discipline"; the class attribute is the trigger. SKIP only when no styling and no component file is touched.
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.