Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add selvarajmurugesan90/ops-engineering-skills --skill jenkins-centralized-shared-librarygit clone --depth 1 https://github.com/selvarajmurugesan90/ops-engineering-skillsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/selvarajmurugesan90/ops-engineering-skills/jenkins-centralized-shared-library)<a href="https://agentmods.dev/skills/selvarajmurugesan90/ops-engineering-skills/jenkins-centralized-shared-library"><img src="https://agentmods.dev/badge/skills/selvarajmurugesan90/ops-engineering-skills/jenkins-centralized-shared-library/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/selvarajmurugesan90/ops-engineering-skills/jenkins-centralized-shared-library"><img src="https://agentmods.dev/badge/skills/selvarajmurugesan90/ops-engineering-skills/jenkins-centralized-shared-library.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 2 findings, up to high
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- high Anti-Refusal · line 254 Skill instructs the agent to omit warnings, disclaimers, or ethical commentary. Stripping safety caveats hides risk from the user and is a common jailbreak preamble.Fix: Remove instructions that suppress warnings, disclaimers, or ethical commentary. Let the agent surface safety-relevant caveats to the user.
- medium Agent Snooping · line 321 Skill enumerates or reads other installed skills. Access to other skills' SKILL.md files or the skills directory reveals prompt instructions, capabilities, and secrets that should be invisible to peer skills.Fix: Remove all code or instructions that list or read other skills' files or directories. Skills should operate independently; cross-skill access is a privilege escalation.
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00094 | $0.03411 |
| Opus 5 | $0.00047 | $0.01706 |
| Sonnet 5 | $0.00019 | $0.00682 |
| Haiku 4.5 | $0.00009 | $0.00341 |
Grade A, and why
jenkins-centralized-shared-library scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 11d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 322 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Jenkins Centralized Shared Library
Purpose
When ten, fifty, or a hundred repos each carry their own hand-written
Jenkinsfile (jenkins-declarative-pipeline-per-repo),
a single change — a new required security scan, a registry migration, a
Groovy bugfix — has to be copy-pasted into every repo, drifts immediately,
and is untestable in isolation. A Jenkins Shared Library solves this by
hosting the real pipeline logic in one Git repository (vars/ for
callable global steps, src/ for supporting Groovy classes), registered
once with the Jenkins controller, so every consuming repo's Jenkinsfile
shrinks to a few lines that call one shared function with parameters. This
skill covers the shared library's structure, how a thin per-repo
Jenkinsfile consumes it, and how to version the library so a change
doesn't break every pipeline simultaneously.
When to use
- More than a handful of repos have near-duplicate Jenkinsfiles and a change (new stage, new gate, new notification channel) requires editing each one individually.
- Standing up Jenkins pipeline standards for a new team/org and wanting every repo's Jenkinsfile to be a thin wrapper from day one.
- An existing shared library needs a new global step (
vars/*.groovy) or a breaking change that must be versioned so consumers can opt in gradually. - Deciding what belongs in the shared library (org-wide, stable logic) versus the per-repo Jenkinsfile (repo-specific parameters) — see jenkins-declarative-pipeline-per-repo for the per-repo side of that boundary.
- Debugging why a pipeline behaves differently after a shared library
update landed on
main/masterand consumers pinned to a floating ref.
Prerequisites & environment
- A dedicated Git repository for the shared library (commonly named
jenkins-shared-libraryorpipeline-library), separate from any consumer application repo. - Jenkins Pipeline: Shared Groovy Libraries plugin, and the library
registered in Manage Jenkins → System → Global Pipeline Libraries
with a
Name(e.g.shared-lib), a default version, and either "Load implicitly" off (recommended — require explicit@Library) or on. - Git tags or branches in the library repo to serve as version references
(e.g.
v1.4.0, or a floatingmainfor early adoption only). - Repo admin/Jenkins admin coordination: consuming repos need to reference the library by name and version in their Jenkinsfile; the library itself needs its own CI (recommended — see Step 6) so changes are tested before every consumer picks them up.
- Groovy familiarity for anyone modifying
src/classes — see jenkins-groovy-scripting-best-practices for sandboxing and testing guidance specific to this code.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 11d ago First seen · 322 lines · 94 tokens per session scan A 4ce6c10b6ded
jenkins-centralized-shared-library is a skill published in the GitHub repository selvarajmurugesan90/ops-engineering-skills (38 stars, last pushed 1mo ago), licensed Apache-2.0. It adds 94 tokens to every session and 3,411 once invoked, about $0.0005 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
import-prom-rule
Bulk import of a Prometheus alert rule YAML file (create a whole set of rules at once). Dedicated to handling a remote URL or local YAML text, automatically parsing the three formats groups / a plain rules array / a single rule. ⚠️ Do not use this skill for single-rule creation — when the user describes a single alert…
chinese-git-workflow
A reference for configuring Git with Chinese code-hosting services such as Gitee, Coding.net, GitLab China, and CNB, including SSH, HTTPS, credentials, CI, and repository mirroring.
configure-env-variables
Configures environment variables for Power Pages site settings to support ALM across environments. Creates environment variable definitions in Dataverse, guides the user through linking site settings to those variables via the Power Pages Management app, adds the variables to the solution, and generates a…
atmos-profiles
Atmos profiles: profile directories, --profile and ATMOSPROFILE activation, profile merge behavior, environment switching, and routing profile-specific auth/toolchain/config overrides.
webhook-management
Configure and validate CCAM webhook targets across supported chat, incident, automation, and generic providers. Use when listing provider requirements, creating or updating a target, scoping it to alert rules, sending a test notification, reviewing delivery history, or deleting a target.
managing-github-actions-secrets
Creates and updates GitHub Actions secrets for PostHog workflows. Use when adding a new CI secret, rotating an existing secret, wiring a workflow to an API token, package registry credential, deploy key, or any value referenced via ${{ secrets. }} in .github/workflows/.