Claude Skills
The open format is called Agent Skills and works in Claude Code, Codex, Cursor and other agents — most people know it as Claude Skills.
Every Agent Skill we could find on GitHub, deduplicated by content. 80 290 files from 1 781 authors, of which 62 619 are unique — the rest is the same skill repackaged into someone else's repository. For each one: what it weighs in tokens, whether it ships runnable scripts, and which MCP servers it needs.
Plans and delivers a single project — scope, estimation, scheduling, critical path, tracking, and recovering when it slips. Use this to plan a project, build or challenge a schedule, estimate credibly, track progress meaningfully, or recover a project that is late.
Defines and applies visual brand — logo usage, palette, typography, imagery direction, and the guidelines that keep expression consistent across product and marketing surfaces. Use this to establish a brand from scratch, audit whether an existing brand is being applied consistently, build brand guidelines, or decide how a brand should express itself in an unfamiliar format.
Governs the portfolio of work — intake, prioritization, stage gates, resource contention, and stopping things. Use this to set up intake and prioritization, run a stage gate, decide between competing initiatives, resolve resource contention across projects, or work out why everything is in flight and nothing is finishing.
Owns what gets built and why: product strategy, roadmap, discovery, user experience, and the definition of success for each release. Use this to decide what to build next, to cut scope, to turn a business goal into a product bet, to judge whether a feature is worth its cost, or when engineering and go-to-market disagree about what a release is for. Also use for roadmap sequencing and for killing work that is not earning its place.
Applies a deliberate visual direction to an interface — minimalist editorial, industrial utilitarian, or high-polish commercial — each with its own type scale, palette behavior, surface treatment, and motion. Use this when a product needs a point of view rather than defaults, when choosing between visual directions, when an interface reads as generic, or when restyling something without changing its structure.
Raises the visual and interaction quality of an interface — layout, hierarchy, type, spacing, density, and the details that separate a considered product from a generic one. Use this when a screen works but looks unfinished or default, when a layout feels crowded or arbitrary, when a page has no clear focal point, or when an interface needs to feel trustworthy rather than merely functional.
Builds and maintains the design system a product is assembled from — tokens for color, type, spacing and elevation, component contracts, and the rules that keep them coherent as the product grows. Use this when starting a new interface, when screens have drifted apart visually, when the same component exists three times in slightly different forms, or when a token or component needs adding without breaking what exists.
Upgrades an existing interface to a higher standard without rebuilding it — auditing what is there, identifying what reads as generic or unfinished, and sequencing changes by impact. Use this when a product works but looks dated or default, when a redesign is being considered, when deciding whether to restyle or rebuild, or when a screen needs to look substantially better with limited effort.
Designs slide decks, one-pagers, and marketing graphics that carry an argument rather than decorate one. Use this to build or fix a pitch deck, board deck, or conference talk; to design a banner, social graphic, or one-pager; or when a deck is dense, unfocused, or being read aloud from the slides.
Audits a website, app, onboarding flow, or design for usability, conversion, and product problems, tying every finding to a business outcome and a severity. Use this to review an interface, diagnose low conversion or activation, find where users drop off, get structured product feedback, or decide which UX fixes to ship first. For raising visual quality rather than finding problems, use `interface-craft`.
Gets new users from signup to first real value — signup flow, onboarding, time-to-value, and the early experience that determines whether someone becomes a user or a lapsed account. Use this to design or fix signup and onboarding, diagnose why signups do not convert to active use, reduce time-to-value, or decide what a new user must accomplish first.
Produces design reference imagery before implementation — screen concepts, layout directions, and flows for web or mobile that make a verbal brief concrete enough to argue with. Use this when a brief needs visualizing before anyone builds, when comparing layout directions, when handing a developer a target, or when stakeholders are describing different things with the same words.
Finds, qualifies, and reaches prospects through cold outreach — list building, qualification criteria, cold email and multi-channel sequences, and the follow-up that actually gets replies. Use this to build a prospect list, write cold outreach, fix a sequence that is not getting responses, define qualification criteria, or decide whether a segment is worth pursuing.
Sets price, structures packages and tiers, and designs the monetization surfaces that carry them — upgrade paths, paywalls, and offer construction. Use this to set or change pricing, design or restructure tiers, choose a pricing metric, build an offer, design upgrade prompts and paywalls, or evaluate whether a pricing change is safe to make.
Owns the revenue engine end to end: sales, monetization, pricing, customer success, retention, and partnerships. Use this for pricing and packaging decisions, sales strategy and coverage, forecast and pipeline health, churn and expansion, partner and channel strategy, or when marketing-sourced demand is not converting. Also use to decide which segments to pursue and which to decline.
Runs the mechanics of the revenue engine — lead lifecycle definitions, routing, CRM hygiene, forecasting process, pipeline reporting, and the marketing-to-sales handoff. Use this to fix a broken handoff, define lifecycle stages, improve forecast accuracy, clean up CRM data, design territory or routing rules, or diagnose why pipeline numbers are not trusted.
Designs and improves referral, affiliate, and word-of-mouth programs — incentive structure, mechanics, timing, and fraud control. Use this to build a referral or affiliate program, diagnose one that is not producing, decide what incentive to offer, or judge whether referral is a realistic channel for a product.
Diagnoses and reduces churn — cancellation flows, save offers, failed-payment recovery, at-risk detection, and the product and service causes underneath. Use this when churn is rising or unexplained, to design a cancellation or win-back flow, to recover involuntary churn, to identify at-risk accounts before they leave, or to decide whether a retention problem is a product problem.
Builds what a sales team needs to sell — pitch decks, one-pagers, objection handling, competitive battlecards, demo scripts, and case studies. Use this to create or fix sales collateral, prepare for a competitive deal, build a demo flow, document objection responses, or diagnose why a pitch is not converting.
Designs and audits who can reach what — authentication, authorization models, privileged access, service credentials, and joiner-mover-leaver process. Use this to design a permissions model, run an access review, reduce standing privilege, handle offboarding, set up SSO or MFA, manage service and machine credentials, or diagnose why permissions have sprawled.
Runs a security incident from detection to closure — triage, containment, investigation, communication, and the review afterward. Use this when a compromise is suspected or confirmed, when preparing an incident response plan or running an exercise, when deciding whether something is an incident, or when a breach may trigger notification obligations.
Owns the security posture of the organization — architecture, program strategy, risk acceptance, incident command, and the authority to stop work that creates unacceptable exposure. Use this for a security strategy or program decision, when a technical choice creates security risk that needs a verdict, when deciding whether to accept or block a risk, when standing up a security function, or when security and delivery priorities conflict and someone has to decide.
Reviews a design or change for security before it ships — authentication and authorization, data handling, secrets, dependencies, and the secure-development practices around it. Use this to review an architecture or pull request for security, set secure coding standards, choose or tune SAST and DAST tooling, assess a third-party integration, or decide whether a design is safe to build.
Identifies what could go wrong in a system before it is built or changed — the assets worth attacking, the entry points, the trust boundaries, and the controls that actually address the realistic threats. Use this when designing a feature or system, when a change touches authentication, data handling, payments, or external input, before a security review, or when deciding which security work is worth doing at all.
Designs AI systems, automations, and agent workflows for a business — identifying which manual work is worth automating, how to structure the system, which tools fit, and what could go wrong. Use this to automate part of an operation, design an agent or MCP workflow, reduce repetitive manual work, connect tools into a system, decide which automation to build first, or audit an automation that is not delivering.
Runs the loop from discovering a weakness to confirming it is fixed — scanning, triage, prioritization by real exploitability, remediation tracking, and patch policy. Use this to stand up or fix a vulnerability program, triage scanner output, decide what to fix first, set patch SLAs, handle a disclosure from an outside researcher, or report posture to leadership.
Designs interfaces that survive their consumers — resource modeling, errors, versioning, pagination, and compatibility. Use this to design a new API, review one before it ships, decide how to version or deprecate, fix an interface consumers keep misusing, or work out whether a change is breaking.
Isolates feature work in its own branch or worktree and integrates it cleanly when done. Use this when starting work that should not disturb the current workspace, when several efforts must proceed in parallel on one repository, or when implementation is finished and the change needs merging, rebasing, or splitting for review.
Owns architecture, engineering delivery, infrastructure, data platform, and internal systems. Use this for build-versus-buy calls, technology selection, architectural direction, engineering capacity and delivery risk, technical debt tradeoffs, platform and tooling decisions, or when a technical choice has business consequences that need stating in business terms. Also use to judge whether a technical plan is sound before it is committed to.
Designs and runs cloud infrastructure — environments, infrastructure as code, networking and isolation, scaling, and cost. Use this to design a cloud environment, control infrastructure spend, set up environment separation, plan for scale or region failure, or review infrastructure someone configured by hand.
Conducts and responds to code review — reviewing a change for correctness, design, and risk, and evaluating review feedback received on your own work. Use this before merging, when asked to review a diff or pull request, when review feedback has arrived and needs acting on, or when feedback seems wrong and needs a reasoned response rather than compliance.
Turns a spec or requirement into a written plan a separate session or agent can execute, then drives that plan through review checkpoints. Use this before touching code on any multi-step task, when work needs handing to someone else, when a task keeps sprawling mid-implementation, or when a plan exists and needs executing in order with verification between steps.
Verifies that work is actually complete before it is claimed to be — running the checks, reading the output, and confirming the original request was satisfied rather than approximated. Use this before saying something is done, fixed, or passing; before committing or opening a pull request; and whenever a claim of success has not been backed by command output.
Makes systems debuggable and reliably operable — instrumentation, alerting that is worth waking for, service objectives, and learning from failure. Use this to instrument a service, fix alerting that is ignored, set error budgets or reliability targets, prepare for on-call, or run a blameless post-incident review.
Splits work across multiple agents or sessions running at once, keeping their surfaces disjoint so results merge cleanly. Use this when facing several independent tasks with no shared state, when a plan has parallelizable steps, when a broad search or audit would be faster fanned out, or when deciding whether work can safely be split at all.
Turns rough intent or a weak prompt into a reliable one — diagnosing why output is inconsistent, restructuring the instruction, and adapting it across models. Use this when a prompt is not producing what was wanted, when output varies run to run, when writing a prompt for a repeated task, when moving a prompt between models, or when someone describes what they want an AI to do and needs it written properly.
Writes and revises agent skills so they trigger at the right moments and give usable instruction when they do. Use this when creating a new skill, editing an existing one, diagnosing a skill that fires too often or never fires, or reviewing a set of skills for overlap. Also use before adding to a skill library, to check the capability is not already covered.
Ships changes safely and often — pipelines, deployment strategies, feature flags, rollback, and database changes. Use this to design a deployment pipeline, reduce release risk, roll out a risky change gradually, plan a schema migration, or work out why releases are infrequent and frightening.
Finds the root cause of a bug, test failure, or unexpected behavior before proposing any fix. Use this whenever something is broken and the cause is not yet proven — a failing test, a production error, intermittent behavior, or a symptom that appeared after a change. Also use when a fix has been attempted and did not work, or when the same bug keeps coming back.
Explores the problem and the range of possible approaches before any code is written — clarifying what is actually being asked, surfacing options with their tradeoffs, and converging on one. Use this at the start of any feature, component, or behavior change, when a request is ambiguous, when the first idea is the only idea on the table, or when a design decision needs pressure-testing before commitment.
Makes technical debt visible and decidable — distinguishing real debt from mess, quantifying its cost, and arguing for remediation in business terms. Use this to assess and prioritize debt, decide whether to fix or live with something, justify remediation work to non-engineers, or plan a migration off a system nobody wants to touch.
Drives implementation by writing a failing test first, then the smallest code that passes it. Use this before writing implementation code for any feature or bugfix, when a bug needs a regression test, when existing code is hard to change safely, or when someone asks whether a change is covered. Also use to decide what is worth testing and what is not.
Designs system structure and makes architectural decisions defensible — boundaries, coupling, trade-offs, and recording why. Use this to design a new system or major component, choose between architectural options, review an existing design, decide where a boundary belongs, or document an architectural decision so it survives the people who made it.
当用户要做/研究一个东西、想提升某个技能、或觉得某个产出不够好想改进时使用。用「改良主义」先逼出一个最垃圾但能跑的原型，再引导他自己洞察缺陷、提出问题，提改良假说→实践检验→迭代，信奉「洞察缺陷 > 如何优化 > 最终答案」，并把每次改进的方法本身沉淀成方法论。触发场景：要做 X、研究 X、提升 X、X 做得不好想改进、怎么优化 X、不知从哪下手做。
用户学任何新概念/新技术/新理论的默认深度入口——一次性用五个视角把概念讲透并帮他选深入方向：crossover 用已会的撬动、occam 框定该学多深、graph 建知识地图、prototype 最小原型迭代、feynman 拷问检验。触发场景：我想学 X、理解 X、X 是什么、讲讲 X、搞懂 X、学一下 X、深入 X、给我讲讲 X。除非用户明确只要某一个视角（那时改用对应的单个 learn-* skill）。
当用户学完一个东西想自查是否真懂、或觉得「好像懂了」但不确定时使用。用「费曼学习法」让他用自己的话把概念讲出来，你扮好奇学生专挑他含糊/跳过的地方追问，把「讲不顺的模糊处」揪出来作为没真懂的漏洞，定位是缺前置知识还是没想透，判断理解是否闭环。触发场景：我学完了考考我、自查一下、我好像懂了、我讲讲你看对不对、检验我的理解、这个我真懂了吗。
Use when 用户想以一对一苏格拉底导师的方式系统学习一个课题——开一门新课、推进课题的下一篇、提交学习反馈或说「我读完了」、或整理/查看学习日志。基于 Bloom 2 Sigma 的交互式学习系统。触发词：开个文件夹学X、我想学X、帮我学X、继续、下一篇、我读完了、整理学习、查看学习日志、interactive Socratic tutoring、Bloom 2 sigma learning。
当用户要系统学一个新领域、不知道从哪入手、或担心「学得不够系统」时使用。用「知识图谱学习法」和用户一起构建该领域的概念/用途/父子节点图谱（自己建图的过程本身就是学习），标出复用价值最高的节点和「从常识就能入门的点」，给出有效学习路径并回答「学到哪算够」。触发场景：系统学 X 领域、从哪开始学、学得不系统、想要 X 的全貌、规划学习路径、这个领域有多大。
当用户纠结要不要学某个东西、学到什么程度，或在做时间/精力/项目取舍时使用。用「简易策略」先逼问要解决的既定问题，检验现有知识能否搞定，评估知识贬值速度与 ROI，用「探索 vs 应用」判断该学新的还是用现有的，给出「学 / 不学 / 只学最小够用」的结论，避免囤积会贬值的知识。触发场景：要不要学 X、值不值得深入、学到什么程度够、时间不够该学啥、该深挖还是够用就行。
当用户学习或接触一个新概念/新技术/新算法/新领域时使用（尤其感到陌生或有点难时）。用「跨界原则」拿用户已掌握的知识快速撬动新知识——指出他其实已经学过的同一个东西（换了名字）、结构同构的旧知识、能解释新知识的已有知识，并点出新概念体现的跨领域元知识模式。让「学新东西」变成「发现你已经会了一半」。触发场景：学 X、接触 X、这个好难、X 是什么、帮我理解 X。
Query Google Health API v4 — steps, heart rate, exercise, sleep, weight, SpO2, HRV, ECG, blood glucose, nutrition, and 40 total data types
Shared prerequisites for all ghealth skills — auth, setup, global flags, command structure
Deploy Discovery catalog agents end-to-end with one command: discover the agent, build and bind its tool when present, skip tool stages for agents without tools, deploy the agent, and optionally run validation. Use this skill whenever the user asks to deploy a Discovery agent, publish or rebuild an agent tool image, register a Discovery tool from a repo Dockerfile/tool.yaml, resume a failed deployment, or produce a dry-run deployment plan for an agent in this catalog.
Inventory the contents of this Discovery catalog repo. Lists publishers, agents, starter-kits, and the tools shipped under each agent. Use this skill whenever the user asks what's in the catalog, who publishes what, what agents/tools/starter-kits exist, lists or counts of any of those, "show me the catalog", "do we have an agent for X", "what starter kits do we have", "list the publishers", "list tools per agent", or any inventory/discovery question about repo-resident assets — even if the user doesn't explicitly say the word "list".
Deploy Discovery catalog starter-kits end-to-end: validate kit.json agentRefs, build and deploy every referenced agent tool, deploy each referenced agent individually, and summarize deployed agents/tools plus customer-ready sample prompts. Use this skill whenever the user asks to deploy a Discovery starter-kit or deploy all agents listed in starter-kits/*/kit.json.
WordPress performance code review and optimization analysis. Use when reviewing WordPress PHP code for performance issues, auditing themes/plugins for scalability, optimizing WP_Query, analyzing caching strategies, checking code before launch, or detecting anti-patterns, or when user mentions "performance review", "optimization audit", "slow WordPress", "slow queries", "high-traffic", "scale WordPress", "code review", "timeout", "500 error", "out of memory", or "site won't load". Detects anti-patterns in database queries, hooks, object caching, AJAX, and template loading.
Qdrant provides client SDKs for various programming languages, allowing easy integration with Qdrant deployments.
Diagnoses Qdrant production issues using metrics and observability tools. Use when someone reports 'optimizer stuck', 'indexing too slow', 'memory too high', 'OOM crash', 'queries are slow', 'latency spike', or 'search was fast now it's slow'. Also use when performance degrades without obvious config changes.
Guides Qdrant monitoring setup including Prometheus scraping, health probes, Hybrid Cloud metrics, alerting, and log centralization. Use when someone asks 'how to set up monitoring', 'Prometheus config', 'Grafana dashboard', 'health check endpoints', 'how to scrape Hybrid Cloud', 'what alerts to set', 'how to centralize logs', or 'audit logging'.
Claude Skills — questions
Answers built from the skills we actually parsed.