sap-skills: 40 SAP plugins for Claude Code and Codex, and what the verification ledger actually covers
Production-ready plugins for SAP development with AI coding assistants — BTP, CAP, Fiori, ABAP, HANA, Analytics Cloud, Datasphere, and more
At a glance
- What is it?
- The repository packages SAP domain knowledge as SKILL.md files that AI coding assistants load on demand, with a per-plugin ledger separating public-source checks from live-tenant validation. The portability claim is narrower than the plugin count suggests.
- Who is it for?
- Adopt sap-skills if your team already works inside Claude Code or Codex on CAP, Fiori, BTP or ABAP projects and you want the assistant to pull SAP-specific guidance without pasting documentation into prompts. Do not adopt it if you need a vendor-supported SAP product, if your client forbids GPL-3.0 tooling, or if you expect the SAPUI5 plugins to work identically in Cursor and Gemini CLI.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap sap-skills is trying to close
An AI coding assistant knows general JavaScript and general REST conventions. It does not know that a CAP service definition belongs in a .cds file, that a Fiori Elements app has a specific annotation vocabulary, or that deploying to BTP involves a particular set of service bindings. Without that context the assistant produces plausible code that fails at the first SAP-specific step. sap-skills addresses this by shipping 40 plugins whose SKILL.md files activate when the assistant detects a matching request. The README gives the trigger examples directly: asking for a new CAP service activates sap-cap-capire, asking for a Fiori Elements app activates sap-fiori-tools, asking to deploy to BTP activates sap-btp-cloud-platform. The audience is SAP developers who already use an AI assistant and want SAP conventions injected without maintaining their own prompt library. It is not aimed at developers who have never touched the SAP stack, because the skills assume you can judge whether the generated CDS or ABAP is correct.
How activation and the verification ledger work
The mechanism is file-based skill loading, not a runtime service. Each plugin directory carries SKILL.md content, and the assistant reads the relevant file when a prompt matches. The README describes this as automatic activation with no manual invocation. Around that core, some plugins bundle Claude-specific extras: the feature table marks commands with a terminal icon, agents with a robot icon, hooks with a shield icon, and MCP servers with a plug icon. sapui5 is the heaviest, listing five commands, four agents, a hook and an MCP server. sap-hana-cli and sap-fiori-tools each carry an MCP entry. The more interesting design choice is the verification model. The README states that public-source or package-registry verification is tracked where available, and that live tenant and system validation is tracked per plugin in docs/project/source-verification-ledger.json. That file is the honest part of the project: it distinguishes what was checked against public documentation or a package registry from what was checked against an actual SAP system. The README does not claim every plugin has been validated against a live tenant, and the phrase "where available" is doing real work. Read the ledger before trusting any plugin's output in a production change.
Installing for Claude Code, Codex, or a generic client
Three installation paths exist and they are not equivalent. The portable option uses the upstream skills CLI: npx skills add secondsky/sap-skills. The README notes that supported agents are controlled by that upstream CLI and lists Claude Code, OpenCode, Codex, Cursor, Gemini CLI and GitHub Copilot among current examples. For Claude Code the native marketplace is used: /plugin marketplace add secondsky/sap-skills followed by /plugin install sap-cap-capire@sap-skills, and multiple plugins can be installed in one command. Team-wide setup uses claude plugin marketplace add secondsky/sap-skills --scope project, or a manual entry in .claude/settings.json under extraKnownMarketplaces with a source object of type github and repo secondsky/sap-skills. Codex reads a different registry at .agents/plugins/marketplace.json; from a local checkout the commands are codex plugin marketplace add . and codex plugin add sap-abap@sap-skills. Installing from GitHub uses sparse checkout with --sparse .agents/plugins --sparse plugins. The README is explicit that in clients such as OpenCode, Cursor or Gemini CLI, the Claude-specific agents, hooks, slash commands and MCP configs should be treated as role guidance, optional validators, prompt templates and connection recipes unless the client supports them natively. That is a significant caveat: the plugin count stays at 40, but the functional surface shrinks outside Claude Code and Codex.
Where the portability claim breaks down
The README frames the SAP skill content as portable while the packaging is marketplace-specific, and those two statements pull in opposite directions. The SKILL.md text travels. The hooks do not run themselves in a client that has no hook system, so a validator that would have blocked a bad commit becomes a Markdown file you are supposed to read and apply manually. The README says exactly this: run hook validators manually when desired. The same applies to MCP servers, where the documentation points to docs/contributor-guide/mcp-manual-connections.md and advises reading it before configuring any server. There is also a supply-chain surface here. sap-dependency-security covers MCP executable trust, cooldown policies and lockfile hardening, which is a reasonable thing for the project to ship but also an admission that installing MCP servers from a community marketplace carries risk. If your team standardises on Cursor, you are getting prompt templates with SAP vocabulary, not the guarded workflow the feature table implies.
The GPL-3.0 choice and what it means for adoption
The repository is licensed GPL-3.0. For a plugin collection that is largely Markdown guidance plus JavaScript tooling, that is a deliberate choice rather than an obvious one, and it has consequences worth stating plainly without giving legal advice. GPL-3.0 is a copyleft licence. If you fork the plugins and distribute a modified version, the licence terms apply to what you distribute. Internal use inside a company does not trigger distribution in the usual reading, but embedding plugin code into a product you ship is a different question that your legal team should answer, not this article. The practical friction is smaller than it looks for most SAP teams, who consume the plugins through a marketplace rather than vendoring them. It becomes real if you want to build a commercial offering on top of the skill content or ship a modified plugin to customers.
A different approach: writing your own SKILL.md files
The realistic alternative is not a competing SAP plugin marketplace, it is doing this in-house. A SKILL.md file is Markdown with front matter describing when the skill applies. A team with strong SAP documentation practices can write a handful of skills covering exactly the services they use, keep them in the same repository as the application code, and review them alongside pull requests. The difference in approach is scope versus control. sap-skills gives you 40 plugins covering BTP, CAP, Fiori, ABAP, HANA, Analytics Cloud and Datasphere out of the box, which is far more surface than most teams would write themselves, but you inherit the project's verification status and its release cadence. A homegrown set is narrower and stays current with your own SAP release, because the person updating it is the person who hit the problem. The trade-off is maintenance: 40 plugins is a lot of SAP surface for one maintainer to keep aligned with SAP's own release cycle, and the repository's last push date is the only signal the supplied material gives about how actively that is happening.
Maintenance cost and who should install this
Upgrade cost depends on how you consume the plugins. Through the Claude or Codex marketplace, an update is a marketplace refresh and the version badge in the README moves; the CHANGELOG.md file is the record. Through npx skills add, you are tracking the upstream vercel-labs/skills CLI as well, which means two moving parts. Through a clone, you own the merge. The per-plugin verification ledger is the piece that determines whether an upgrade is safe for your environment, because a plugin whose live tenant validation is stale may still carry correct public-source documentation while missing a service change. The honest summary is that this project reduces the cost of getting SAP conventions into an AI assistant and adds a small ongoing cost in tracking which plugins have been validated against what. Teams on Claude Code or Codex with active CAP, Fiori or BTP work get the most from it. Teams on other clients get the SKILL.md text and should plan to run the validators by hand. Anyone evaluating it should start with docs/project/source-verification-ledger.json and the plugin list, not the feature icons.
Editorial conclusion
Adopt sap-skills if your team already works inside Claude Code or Codex on CAP, Fiori, BTP or ABAP projects and you want the assistant to pull SAP-specific guidance without pasting documentation into prompts. Do not adopt it if you need a vendor-supported SAP product, if your client forbids GPL-3.0 tooling, or if you expect the SAPUI5 plugins to work identically in Cursor and Gemini CLI. Before installing anything, open docs/project/source-verification-ledger.json and check which plugins carry live tenant validation for the release you are targeting, because the README only promises public-source or package-registry verification where available.
Community notes