awesome-cursor-rules-mdc is a generator that creates Cursor MDC rule files from structured library information, using semantic search and language models to gather and organize guidance. Developers use it to produce reusable rules for libraries in Cursor, and the catalogue includes 200 of those rules.
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.
git clone --depth 1 https://github.com/sanjeed5/awesome-cursor-rules-mdcWrote 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/rules/sanjeed5/awesome-cursor-rules-mdc/jenkins)<a href="https://agentmods.dev/rules/sanjeed5/awesome-cursor-rules-mdc/jenkins"><img src="https://agentmods.dev/badge/rules/sanjeed5/awesome-cursor-rules-mdc/jenkins.svg" alt="Measured on agentmods" height="20"></a>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.02229 | $0.02229 |
| Opus 5 | $0.01115 | $0.01115 |
| Sonnet 5 | $0.00446 | $0.00446 |
| Haiku 4.5 | $0.00223 | $0.00223 |
Grade A, and why
jenkins 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 4d 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 — 324 lines — stays where its author put it; the contents beside it link to each section on GitHub.
jenkins Best Practices
This guide outlines essential best practices for developing Jenkins Pipelines. Adhere to these rules to ensure your CI/CD processes are efficient, secure, and maintainable.
1. Code Organization and Structure
1.1. Always use "Pipeline as Code"
Store your Jenkinsfile in the root of your project's SCM repository. This enables version control, peer review, and a traceable history for your pipeline definitions.
❌ BAD: Defining pipelines directly in the Jenkins UI.
// No Jenkinsfile in SCM, pipeline defined in UI.
// Hard to track changes, no version history.
✅ GOOD: Store Jenkinsfile in SCM.
// Jenkinsfile at project root (e.g., my-app/Jenkinsfile)
pipeline {
agent any
stages {
stage('Build') {
steps {
sh 'mvn clean package'
}
}
}
}
1.2. Prefer Declarative Pipeline Syntax
Declarative syntax is more readable, structured, and offers built-in validation. Use it for all new pipelines unless a specific, advanced scenario absolutely requires Scripted syntax.
❌ BAD: Using Scripted Pipeline for standard CI/CD flows.
// Scripted Pipeline (less readable, harder to validate)
node('agent-label') {
stage('Checkout') {
checkout scm
}
stage('Build') {
sh 'npm install'
sh 'npm run build'
}
}
✅ GOOD: Use Declarative Pipeline Syntax.
// Declarative Pipeline (structured, readable, validated)
pipeline {
agent { label 'agent-label' }
stages {
stage('Checkout') {
steps {
checkout scm
}
}
stage('Build') {
steps {
sh 'npm install'
sh 'npm run build'
}
}
}
}
1.3. Leverage Shared Libraries for Reusability
Extract common, complex, or security-sensitive logic into Jenkins Shared Libraries. This promotes code reuse, centralizes maintenance, and keeps Jenkinsfiles clean and focused on orchestration. Avoid script tags in Declarative Pipelines; they are a strong indicator that a shared library is needed.
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.
- 4d ago First seen · 324 lines · 2,229 tokens per session scan A c8e4632c0d26
jenkins is a cursor rule published in the GitHub repository sanjeed5/awesome-cursor-rules-mdc (3,571 stars, last pushed 3mo ago), licensed CC0-1.0. It adds 2,229 tokens to every session, about $0.0111 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-09-03.
Other cursor rules, from other repositories
no-mvn-compile
Do not run mvn compile; rely on IDE lint errors.
agents-shipgate
Run Agents Shipgate as the deterministic merge gate for AI-generated agent capability changes.
ci-cd-workflows
This rule provides guidance on the CI/CD pipeline, GitHub Actions workflows (defined in .github/workflows/), custom actions (in .github/actions/), versioning strategies, and release processes. Use this rule if the query involves CI/CD, build/test issues, release procedures, versioning questions, or if it references…
dev-workflow
Monorepo developer workflow standards - mise tasks, git hooks, CI/CD, release automation.
git-github-workflow
Git and GitHub PR workflow — merge commits, append-only history, CI gates, review resolution.
sciclaw-papercuts
Papercuts from Sol/ImageMagick/release cycles — release, brew, CI, and workspace hygiene for sciClaw agents.