# sap-skills: 40 SAP plugins, and how portable they really are

> A GPL-3.0 plugin set for SAP development across BTP, CAP, Fiori, ABAP and Datasphere, with a 24-step validation script and a per-plugin verification ledger. Its own documentation is candid that the same files are live machinery in Claude Code and only Markdown guidance in Cursor or Gemini CLI.

**secondsky/sap-skills** — Production-ready plugins for SAP development with AI coding assistants — BTP, CAP, Fiori, ABAP, HANA, Analytics Cloud, Datasphere, and more

- Repository: https://github.com/secondsky/sap-skills
- Website: https://sap-ai-skills.com
- Stars: 458 · Forks: 119
- Language: JavaScript
- License: GPL-3.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/secondsky-sap-skills

## One repository, two different products

The portability note at the top of the documentation is the most useful paragraph in it. The repository is packaged for the Claude and Codex marketplaces, and the skill content is written to be portable. Then the qualification: in clients such as OpenCode, Cursor or the Gemini CLI, Claude-specific agents, hooks, slash commands and MCP configs should be treated as role guidance, optional validators, prompt templates and connection recipes unless that client supports them natively. In other words a hook in this repository is executable machinery inside Claude Code and a Markdown file describing hook-shaped intent everywhere else. The same applies to the install surface. Claude Code gets a marketplace: `/plugin marketplace add secondsky/sap-skills`, then `/plugin install sap-cap-capire@sap-skills`, several at once if you want them. A project-scoped install uses `claude plugin marketplace add secondsky/sap-skills --scope project`, or you add an `extraKnownMarketplaces` block to `.claude/settings.json`. A third route exists for clients that understand a generic skills CLI:

```bash
npx skills add secondsky/sap-skills
```

That route goes through vercel-labs/skills, and the documentation says plainly which agents it supports is controlled by that upstream CLI rather than by this repository.

## Verification is per plugin, and live tenant coverage is partial

The claim in the repository description is production-ready plugins, and the verification story is more careful than that word. Verification is public-source or package-registry verification tracked where available, and live tenant and system validation is tracked per plugin in a JSON ledger at `docs/project/source-verification-ledger.json`. Two tiers, then: some plugins are checked against published SAP material or a package registry, and the ones that have been exercised against a running system say so in the ledger. That distinction is the difference between a plugin that matches current documentation and a plugin that has been seen working in a tenant, and for enterprise work it is usually the second one you need. A dedicated plugin handles part of the problem: `sap-dependency-security` covers SAP dependency security, MCP executable trust, cooldown policies, lockfile hardening and supply-chain safeguards, which is the plugin you would point at your own agent's MCP configuration. The evidence-ledger check is wired into the validation script, so the ledger cannot quietly fall behind the plugins it describes.

## Twenty-four validation steps, named after the failure modes

The `validate` script in package.json is one line containing two dozen chained checks, and reading it tells you what the maintainers worry about. There is a JSON-schema pass, a Codex-layer validation, frontmatter validation, a reserved-words check, a bundled-resources check, a command and agent frontmatter check, an inventory check, a manifest-drift check, MCP security, MCP environment contracts, the verification ledger, packaging hygiene, harness portability, public claims, oracle browser safety, reference provenance, templates, command contracts, agent contracts and skill quality, followed by an effectiveness audit and three test targets for the LSP launcher, hooks and hook contracts. Several of those names correspond to mistakes that are easy to make and hard to see: harness portability is the check that the Claude-specific files degrade gracefully elsewhere, public claims is the check on marketing language like production-ready, and manifest drift exists because there are several marketplace manifests to keep in step. The tooling package itself is named `sap-skills-validation`, is marked private, and sits at version 1.0.0.

## The Codex layer is generated from the Claude layer

Two marketplaces would drift apart on their own, so this repository generates one from the other. There is a `generate:codex` script running `generate-codex-layer.mjs`, and a matching `validate:codex` running `validate-codex-layer.mjs`, which means the Codex plugin registry is a build artefact of the Claude one rather than a second hand-maintained copy. The same pattern covers marketplace schema validation, where `ajv` checks `.claude-plugin/marketplace.json` against `schemas/marketplace.schema.json`. Both marketplace roots are visible in the tree as `.claude-plugin/` and `.agents/`. Codex reads the repository marketplace from `.agents/plugins/marketplace.json` and uses the shared `SKILL.md` content, and the documentation describes that layer as skills-first, with Claude commands, agents, hooks, LSP configuration and MCP recipes remaining available as optional fallbacks. Installing from GitHub needs sparse checkout, which is a reasonable hint at how large the tree has become:

```bash
codex plugin marketplace add https://github.com/secondsky/sap-skills.git --sparse .agents/plugins --sparse plugins
```

Local checkouts are simpler: `codex plugin marketplace add .` followed by `codex plugin add sap-abap@sap-skills`.

## Auto-activation is a client behaviour, not a file property

The How It Works section promises that plugins activate on context with no manual invocation, and the examples are specific: asking to create a new CAP service activates `sap-cap-capire`, setting up a Fiori Elements app activates `sap-fiori-tools`, deploying to BTP activates `sap-btp-cloud-platform`, writing an ABAP CDS view activates `sap-abap-cds`, and creating a SAC planning model activates `sap-sac-planning`. That mapping is the part worth reading, because it tells you the trigger is the phrasing of a request rather than anything in your project files. Which means it inherits the activation behaviour of whichever client is running. In a client that loads skills on demand, you get the mapping. In one that does not, the same five plugins sit there as documents and you invoke them yourself. The feature markers in the plugin tables give a second read on the same point: a legend maps commands, agents, hooks, MCP servers and the language server, and the tables show that most plugins are commands plus little else. `sapui5` is the heaviest at five commands, four agents, a hook and an MCP server, while several BTP plugins are a single command and nothing more.

## The validation chain calls an oracle the manifest never declares

Here is the gap worth knowing before you run the checks yourself. The package.json scripts include `oracle`, `oracle:login`, `oracle:review`, `oracle:status` and `oracle:mcp`, and each one invokes a bare binary named `oracle` or `oracle-mcp`. The visible manifest declares no dependencies and no devDependencies, and there is a `.oracle/` directory in the tree. So `npm run validate` cannot be satisfied from the manifest alone; you need those tools on your PATH or installed separately. What they do is worth understanding before you install them, because the login script is explicit about driving a real browser: it runs with `--engine browser`, `--browser-archive never`, `--browser-manual-login`, `--browser-keep-browser` and a browser input timeout of 120000, passing the prompt `HI`. A validation system that can sign into an SAP system is a different category from a linter, and the flags suggest a deliberate choice not to archive browser sessions. The one validation step that names this explicitly is `validate-oracle-browser-safety`.

## A plugin for a deprecated service, GPL-3.0, and no releases

Three details to close on. First, the coverage is not uniformly current: one of the BTP plugins is `sap-btp-intelligent-situation-automation`, described as deprecated Intelligent Situation Automation data export, unsubscription and legacy reference. A plugin retained for a deprecated product is a legitimate thing to ship and a useful signal that the set is maintained against installed estates rather than against the current product catalogue. Second, the licence is GPL-3.0, with a `THIRD-PARTY-NOTICES.md` at the root, which is a heavier obligation for a plugin bundle than a permissive licence and one that enterprise users tend to route through legal review. Third, there are no GitHub releases. The 40 plugins have no versioned distribution of their own, even though the private validation tooling sits at 1.0.0, so what you install is whatever the default branch holds at the moment you run the install command. The last push to main was on 2026-09-28, the project publishes a site at sap-ai-skills.com, and the plugins are distributed by reference to the repository rather than by pinned version.

## Conclusion

Adopt sap-skills if you build on SAP BTP, CAP, Fiori or Datasphere and your team is standardised on Claude Code or Codex, where the bundled commands, agents and hooks are real machinery rather than documents. Do not adopt it on the strength of the production-ready description, since that is the project's own assessment, the repository has no GitHub releases at all, and the verification ledger deliberately separates public-source checks from live tenant validation. Verify first which plugins have actually been validated against a tenant like yours, then check that the ones you rely on carry the feature markers you need, since many ship commands only.

## FAQ

### How many SAP plugins does sap-skills ship?

Forty, grouped by category. Tooling and Development holds five, SAP BTP Platform fifteen, UI Development four and Data and Analytics seven, with further categories beyond those. Each plugin table shows which of commands, agents, hooks, an MCP server and the language server it bundles.

### How do I install sap-skills for Claude Code?

Run `/plugin marketplace add secondsky/sap-skills`, then `/plugin install sap-cap-capire@sap-skills`, or install several plugins in one command. For a project-scoped install use `claude plugin marketplace add secondsky/sap-skills --scope project`, or add an `extraKnownMarketplaces` block to `.claude/settings.json` directly.

### Do the sap-skills hooks and agents work in Cursor or Gemini CLI?

Not natively. The README states that in clients such as OpenCode, Cursor or Gemini CLI, 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.

### How does sap-skills verify its plugins?

Public-source or package-registry verification where available, plus live tenant and system validation tracked per plugin in `docs/project/source-verification-ledger.json`. The validation script includes both a verification-ledger check and a public-claims check, so the ledger is kept in step with the plugins.

### What licence does sap-skills use?

GPL-3.0, with third-party attributions recorded in `THIRD-PARTY-NOTICES.md` at the repository root. The repository publishes no GitHub releases, so plugins are installed by reference to the repository rather than by pinned version.

## Sources

- [Issues](https://github.com/secondsky/sap-skills/issues)
- [License: GPL-3.0](https://github.com/secondsky/sap-skills/blob/main/LICENSE)
- [Project website](https://sap-ai-skills.com)
- [README](https://github.com/secondsky/sap-skills/blob/main/README.md)
- [secondsky/sap-skills on GitHub](https://github.com/secondsky/sap-skills)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/secondsky-sap-skills