Explore AI Agent Skills & Claude Prompts
Discover open-source agent skills for Claude Code, Codex, ChatGPT, and any tool that uses SKILL.md.
Enter through keywords, occupations, creators, and GitHub sources to see what kinds of skills are emerging across domains.
Use the same catalog through the API
Connect 381,784 public skills to your own search, analytics, or agent workflow with the REST API.
Querying local SQLite index...
sap-gui-screen-check
by sapdev-aiLive half of the golden-screen regression harness. Replays the screen fingerprint baselines (`references/<stem>.screens.json`, schema sapdev.screenbaseline/1) against the CURRENT SAP system and reports control / screen-identity drift BEFORE a user hits a silent false-success. For each checkpoint the orchestrator (`sap_screen_check.ps1`) drives the read-only probe (`sap_screen_check_probe.vbs`): navigate to the screen via the `reach` OK-code, read its identity (program + dynpro), and test that every control ID the driving VBS depends on still resolves via findById. Language-independent (asserts IDs + program/dynpro, never displayed text). A missing control or an identity mismatch on a `captured` checkpoint is reported as DRIFT (BLOCKER) — the named VBS will silently mis-step on this release; a `pending_live` checkpoint is captured and (only with --update-baseline) promoted to `captured`. Pairs with the static CI coverage gate in scripts/check-consistency.mjs and the contract in contributing/golden_screen_basel
sap-check-fm
by sapdev-aiValidates ABAP CALL FUNCTION statements in ABAP source code against the actual function module parameter definitions retrieved via RFC. Checks parameter names (unknown, missing mandatory, wrong section) and data types (compatibility of the passed variable's type with the FM parameter type). For structure parameters, validates every component field by field. Uses RPY_FUNCTIONMODULE_READ_NEW to get FM definitions, DDIF_FIELDINFO_GET for structure/table type details, and DDIF_DTEL_GET for data element details. Prerequisites: SAP GUI installed (provides SAP.Functions 32-bit COM object).
sap-docs-check-ddic
by sapdev-aiValidates DDIC objects (domains, data elements, tables) extracted from a design document. Checks naming conventions, data type validity, and cross-references between domains, data elements, and table fields. Optionally verifies existence in SAP system via RFC_READ_TABLE on DD01L/DD04L if SAP login info is provided. Input: work folder path containing {doc_name}_domains.txt, _dataElements.txt, _tables.txt Output: {work_folder}/check_result_ddic.txt
sap-se11
by sapdev-aiCreates and updates ABAP Dictionary objects in SAP via SE11 using SAP GUI Scripting. Supports all 9 DDIC object types: Database table, View, Data element, Structure, Table type, Type group, Domain, Search help, and Lock object. Uses tab-delimited definition files for structured input. Existence check, create or update, save, and activation. Also supports delete mode: when the user asks to delete a DDIC object (e.g. "delete table ZTABLE", "drop structure ZSTRUCT", "remove domain ZDOM"), routes by object type to the correct SE11 radio + name field, presses Shift+F2 from the initial screen, confirms via btnSPOP-OPTION1 (Yes), handles dependent-object and post-delete TR popups, and verifies removal. Deletion is irreversible — the skill asks for explicit confirmation before running the VBS. For database tables, SE14 is the canonical drop path; this skill flags the SE14 fallback if the SE11 delete leaves the table in place. Prerequisites: Active SAP GUI session (use /sap-login first).
sap-compare
by sapdev-aiCompare the SAME ABAP object across two SAP systems — the pinned connection (LEFT) and a second saved profile selected with --against <hint> (RIGHT). DDIC objects (table / structure / data element / domain / table type) are compared field-by-field over RFC on BOTH sides (DDIF_FIELDINFO_GET). Programs / includes / function modules are compared by source over RFC via RPY_PROGRAM_READ (sap_rfc_read_source.ps1). Emits a structured field diff (diff.json), a unified source diff, and an AI summary that annotates each difference with the likely cause — including release skew using each system's saved release marker. Read-only: never modifies either system. Prerequisites: BOTH systems saved via /sap-login (RFC password required, same Windows user — DPAPI is CurrentUser-scoped). Class source compare is limited (RFC class source unsupported until ADT mode).
sap-activate-object
by sapdev-aiActivates an inactive SAP repository object via SAP GUI Scripting. Routes to the correct transaction by object type: SE38 for reports/programs/function- group main programs, SE37 for function modules, SE24 for classes/interfaces /methods, SE11 for DDIC objects (table, view, dataelement, structure, tabletype, typegroup, domain, searchhelp, lockobject). Handles the "inactive objects worklist" popup that SAP shows when there are multiple inactive objects of the same locality (transportable vs. local — SAP filters the popup by package locality of the triggering object). Verifies activation via PROGDIR (programs/FMs include) and DWINACTIV. Prerequisites: Active SAP GUI session (use /sap-login first).
sap-impact-analysis
by sapdev-aiPre-change / pre-release impact analysis — answers "if I change this object, what else might break?" from SAP's system-maintained CROSS-REFERENCE INDEX (D010TAB, D010INC, WBCROSSGT, CROSS, DD04L), NOT by parsing source (REPOSRC is blocked) and NOT by driving the slow GUI where-used. Resolves the object, then gathers: reverse dependencies (where-used — programs/objects that use it), forward dependencies (what a program uses), runtime entry points (tcodes, jobs, variants, RFC-enabled flag), and transport history (E071/E070). Computes a transparent LOW/MEDIUM/HIGH risk band from where-used fan-out + standard-object flag, writes a markdown report + per-dimension TSVs + risk findings, and registers them in the artifact index for /sap-evidence-pack. Always discloses the dynamic-dispatch blind spot (CALL FUNCTION lv_name, dynamic SELECT, SUBMIT (rep)) and reports COULD_NOT_CHECK rather than guessing on read failures. Inputs: program / class / FM / table / data element / domain / tcode (and TR / package by expansion)
sap-se19
by sapdev-aiFull lifecycle for SAP BAdI implementations via SE19 (BAdI Builder) using SAP GUI Scripting: Create, Update, Display, Delete, Activate, and Deactivate — for BOTH Classic BAdIs (SXS_ATTR / SXC_*) and New BAdIs (Enhancement Framework / BADI_IMPL). Auto-detects the BAdI type via RFC (SXS_ATTR-EXIT_NAME for Classic, BADI_IMPL-BADI_NAME for New); asks the user when a migrated BAdI is genuinely ambiguous (e.g. MB_MIGO_BADI, ME_PROCESS_PO_CUST). For Create the user supplies a BAdI DEFINITION / enhancement-spot name; for all other operations the user supplies a BAdI IMPLEMENTATION name. Implementing-class work (method source, class create/activate) is delegated to /sap-se24; package reassignment is delegated to /sap-change-package. NEVER deletes a BAdI definition or any implementation it did not create. Prerequisites: Active SAP GUI session (use /sap-login first). SAP NCo 3.1 (32-bit) for the RFC type-detection step.
sap-diagnose
by sapdev-aiIncident triage orchestrator for SAP support. From a single incident anchor (a time window, user, transaction, background job, business object key, or a known short-dump) it fans out across the read-only Diagnose readers — /sap-st22 (dumps, GUI), /sap-sm13 (update-task failures), /sap-sm12 (locks), /sap-slg1 (application log), /sap-sm37 (jobs) — then correlates the collected evidence into incident clusters and produces ranked root-cause hypotheses with a recommended fix path. PURE READ-ONLY: this skill never writes to SAP. When a fix implies a write (release a lock, reprocess an update) it only PROPOSES the gated command; the matching reader's remediate mode owns the confirmation. With --fix, after presenting the hypotheses it hands a CUSTOM-CODE-DEFECT top hypothesis to /sap-fix-incident (the write-capable companion, which keeps its own confirmation gate + DEV-only / Z-Y-only guard rails) — /sap-diagnose itself still writes nothing. Mostly RFC-driven (SM13/SM12/SLG1/SM37) and therefore robust across releases
sap-se01
by sapdev-aiManages SAP transport requests via transaction SE01 using SAP GUI Scripting. Two modes: (a) CREATE — default. Creates a new TR. Defaults to Workbench (W); only creates Customizing (C) when the user explicitly asks. Description is rendered per userConfig.rule_of_tr_description (ASK/PATTERN/FIXED/ RANDOM) and truncated to the 60-char SE01 limit. After creation the VBS itself resolves the new TRKORR via SE16N on E070 (filter by AS4USER + AS4DATE today, sort by AS4TIME desc, first row with TRFUNCTION K or W) and echoes `INFO: TRKORR=<...>`. (b) RELEASE — invoked as `/sap-se01 release <TR>`. Releases the TR (and any open tasks) via SE01 Transport Organizer (Display + F9 loop). Asks the user for explicit confirmation before releasing — release is irreversible. Prerequisites: Active SAP GUI session (use /sap-login first).
sap-doctor
by sapdev-aiRead-only environment preflight ("doctor") for the sap-dev toolchain. Diagnoses why skills fail BEFORE they run, across five groups: * gui — SAP GUI installed + SAP GUI Scripting reachable (client + server) * cfg — 32-bit PowerShell, SAP NCo 3.1 in GAC_32, work_dir env var + writability, connections.json present + valid * rfc — RFC connectivity to the AI-session's pinned connection profile * srv — client Repository modifiability (T000 change option) * devenv — TR / package / function group / wrapper artefacts (delegated to /sap-dev-status) Emits one parseable CHECK line per probe and an overall verdict (READY / DEGRADED / BLOCKED). DEGRADES GRACEFULLY: a probe that cannot run reports SKIP, never a false PASS. Every failure carries a copy-pasteable FIX. Pure read-only; never modifies the SAP system (only writes/deletes a tiny temp probe file under work_dir to test writability). Auto-invokable as a pre-flight from any sap-dev skill — exit 0 = ready, 1 = blocked. P
sap-transport-readiness
by sapdev-aiRelease gate for an ABAP transport request — answers "is this transport safe to release?" before it moves to QA / production. Resolves the TR (explicit number, or --current from the dev defaults), builds its object inventory from E071, and runs read-only RFC structural checks: unreleased child tasks (E070), inactive objects (DWINACTIV), local / $TMP objects inside a transportable request (TADIR), and a multi-package note. Optionally chains /sap-atc and /sap-run-abap-unit and folds their verdicts in. Evaluates everything into the reconciled finding model, gates each finding via the customer brief's Quality bar (§6, --strict promotes warnings), and rolls up to GO / GO_WITH_WARNINGS / NO-GO. Writes a reviewer report + findings TSV/JSON + object inventory and registers them all in the artifact index for /sap-evidence-pack. Read-only; never releases the TR — release stays a deliberate /sap-se01 step. Prerequisites: SAP profile saved via /sap-login (RFC); SAP NCo 3.1 (32-bit, .NET 4.0) in GAC. Z_GENERIC_RFC_WRAPPER
Browse Agent Skills by Occupation
23 major groups · 867 SOC occupations
Browse by Category
Explore agent skills organized by their primary use case
Explore the agent skills ecosystem by occupation and creator
SkillMD is not just a keyword search box. It is an open map that organizes public skills by occupation, creator, and repository, helping you see which workflows, judgment criteria, and domain habits people are writing for AI agents.
Then follow creators and GitHub repositories back to the source: compare the skills a team maintains, whether the repo is active, and how the README frames the work before you open, install, or reuse anything.
Use it three ways: learn an unfamiliar field by occupation, study how creators organize skills, then use source context to decide what is worth opening or reusing.
01 Map a field
Browse 23 occupation groups and 867 SOC roles to learn what skills exist in adjacent domains and how they break down real work.
02 Follow creators
Use creator and repository pages to inspect maintained skill collections, recent updates, and source context before trusting a result.
03 Search with sources
Search 1.7M+ collected skills, then use occupation tags, creators, and GitHub source context to decide what is worth opening.
Start with the occupation map, then follow creators and repositories back to real code. SkillMD helps explain why a skill is worth opening, not only what it is named.
Standardizing Agent Capabilities with SKILL.md and Model Context Protocol (MCP)
In the rapidly evolving landscape of artificial intelligence, LLM agents (Large Language Model agents) have transitioned from simple text predictors to autonomous problem solvers. To orchestrate complex, multi-step agentic workflows, developers require a standardized format to specify agent capabilities, prompt instructions, system rules, and database bindings. This is where SKILL.md and the Model Context Protocol (MCP) have emerged as standard developer paradigms. SkillMD serves as the central directory for indexing, exploring, and sharing these critical agent configurations.
Our open-source registry currently tracks over 1.7 million collected SKILL.md configurations and system prompts. By compiling agent configurations from active developers on GitHub, we bridge the gap between prompt engineering research and production execution. Whether you are building agents with Anthropic's Claude Code, OpenAI's GPT-4, Google's Gemini, or local models using Ollama and LlamaIndex, standardized skill definitions ensure your agents behave predictably across different runtime environments.
What is the Model Context Protocol (MCP)?
The Model Context Protocol (MCP) is an open-source standard designed to connect LLMs to data sources, developer tools, and external environments. MCP establishes a bidirectional communication channel between client applications (like Cursor, Claude Desktop, or custom agent systems) and servers hosting data or capabilities. Standardizing instructions via SKILL.md enables LLMs to query databases, read local files, execute terminal commands, and integrate third-party APIs. SkillMD allows you to find ready-to-run MCP servers and prompt instructions for various occupations and technical tasks.
The Structure of a Professional SKILL.md File
A valid SKILL.md configuration is designed to be easily read by humans and parsed by LLMs. It contains precise system instructions, trigger conditions, required parameters, and execution examples. Below is the typical architectural blueprint of a professional agent skill:
- Metadata & Core Scope: Declares the name of the skill, author details, target models, and a description of the capability.
- Triggers & Intent Detection: Details semantic triggers that help the agent decide when to invoke this skill.
- System Prompts: Explicit system-level instructions that direct the agent's behavior, personality, safety guardrails, and formatting preferences.
- Capabilities & Tools: Lists the files, databases, or APIs the agent must access to complete the tasks.
- Few-Shot Examples: Demonstrates real inputs and outputs, helping the model generalize behavior through in-context learning.
Optimizing Agent Workflows for Modern LLMs
Writing effective agent skills requires deep knowledge of prompt engineering. With the release of advanced reasoning models like Claude 3.5 Sonnet, ChatGPT o1, and DeepSeek-V3, prompt templates must focus on structured thinking. Developers are encouraged to use XML tags (e.g., <thought>, <context>, and <rules>) to isolate execution boundaries. Standardized prompts prevent agents from suffering from context drift, ensuring that long-running tasks remain aligned with the initial system parameters.
Exploring by SOC Occupations and Creator Profiles
What makes SkillMD unique is its taxonomy. Instead of simple text search, we parse and organize files according to the Standard Occupational Classification (SOC) system. This means you can discover skills written for Computer and Mathematical roles, Business and Financial operations, Legal, Design, and and Educational Instruction fields. By tracking creator profiles, developers can study how different teams organize their custom instructions, compare version updates, and fork public configs for specialized enterprise use cases.
SkillMD operates as a high-performance index running on a fast Go backend and a highly responsive Astro SSR frontend. All search queries execute in milliseconds, featuring smart debouncing to prevent multiple API requests while keeping user data secure. Join our community of developers to standardize your AI agent instructions and optimize your LLM prompting workflows today.
Frequently Asked Questions
A practical guide to agent skills: what they are, how to inspect them, and how SkillMD helps you explore the ecosystem.