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 jrjsmrtn/project-orchestration-skills --skill harden-gitlab-cigit clone --depth 1 https://github.com/jrjsmrtn/project-orchestration-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/jrjsmrtn/project-orchestration-skills/harden-gitlab-ci)<a href="https://agentmods.dev/skills/jrjsmrtn/project-orchestration-skills/harden-gitlab-ci"><img src="https://agentmods.dev/badge/skills/jrjsmrtn/project-orchestration-skills/harden-gitlab-ci/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/jrjsmrtn/project-orchestration-skills/harden-gitlab-ci"><img src="https://agentmods.dev/badge/skills/jrjsmrtn/project-orchestration-skills/harden-gitlab-ci.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 1 finding, 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 Tool Misuse · line 255 Code deploys a privileged Kubernetes workload (privileged container, hostPath mount, or host namespaces). This grants root on the node and is a node/cluster takeover vector.Fix: Remove privileged, hostPath, and host-namespace settings from workloads. Use a least-privilege securityContext, drop capabilities, and avoid mounting the host filesystem.
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.00143 | $0.04344 |
| Opus 5 | $0.00072 | $0.02172 |
| Sonnet 5 | $0.00029 | $0.00869 |
| Haiku 4.5 | $0.00014 | $0.00434 |
Grade A, and why
harden-gitlab-ci 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 — 307 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Harden GitLab CI
Harden GitLab CI/CD pipelines against supply-chain attack: pin what runs, minimise what it can reach, and stop long-lived secrets from existing at all.
GitLab-specific by design. Like
harden-github-actions, this skill is deliberately bound to one forge. The controls are properties of the GitLab CI execution model —include:resolution, theCI_JOB_TOKENallowlist, project/group variable scoping,id_tokens— not portable concepts in GitLab syntax. It is a sibling ofharden-github-actions, not a translation of it: the two forges differ in what the risks are, not merely in how they are spelled.
When to Use
- When adding a
.gitlab-ci.ymlto a project (aftersetup-git-hooks) - When auditing an existing pipeline before making a GitLab project public
- When a supply-chain review (or the
supply-chainskill) flags CI hardening gaps - When standardising pipeline hardening across GitLab projects
Not for: GitHub Actions (use harden-github-actions) or Forgejo/Gitea Actions. The controls do not carry over — say so rather than approximating.
Required Inputs
- Repository — a GitLab project (auto-detected from git remotes). Self-hosted GitLab is a first-class target, not an exception: authenticate once and every control below is identical.
- Project visibility — public/internal or private. Phases 3 and 4 branch on it: public and internal projects expose pipeline artifacts to unauthenticated users, and fork merge requests are the main variable-exfiltration route.
- Scope — what to run:
audit— report findings against the checklist below; no writes (default)fix— apply the mechanical fixes (pin includes/components/images), leave judgment calls to the maintainerfull—audit, thenfixafter confirmation
The GitLab Threat Model — What Actually Differs
Where the risk sits differs from GitHub Actions; the controls are not one-for-one equivalents:
| Concern | GitHub Actions | GitLab CI |
|---|---|---|
| Third-party code execution | uses: actions/x@ref from the Marketplace |
include: + CI/CD Catalog components — same class of risk, different keyword |
| Ambient credential | GITHUB_TOKEN with repo-wide default scopes |
CI_JOB_TOKEN — defaults to own project only; risk is a widened allowlist |
| Secret exfiltration surface | workflow can read all repo secrets | variable scoping — protected/masked/environment-scoped, plus fork-MR exposure |
| Provenance / keyless auth | OIDC via id-token: write |
id_tokens: with an aud claim |
| Runner trust | GitHub-hosted vs self-hosted | shared vs group/project runners, privileged Docker, shell executor |
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 · 307 lines · 143 tokens per session scan A 4c388d5a4f46
harden-gitlab-ci is a skill published in the GitHub repository jrjsmrtn/project-orchestration-skills (15 stars, last pushed 7d ago), licensed MIT. It adds 143 tokens to every session and 4,344 once invoked, about $0.0007 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
setup
Guided onboarding for nullius in this repo — detects test frameworks to propose Oracle config, offers the GitHub Action CI check, and walks through enabling the hook plugin. Use when a user asks to set up, install, enable, configure, or onboard nullius, or asks what nullius needs to be fully working here.
cpv-publish-to-marketplace
Use when publishing a plugin to a GitHub-hosted marketplace. Used dynamically via cpv-the-skills-menu (TRDD-478d9687).
turborepo
Turborepo monorepo build-system guidance — turbo.json task pipelines, caching, the turbo CLI, --filter/--affected, CI, env vars, and packages. Use when configuring tasks, sharing code between apps, or debugging the cache.
c-jira
Manage Jira issues using jira (jira-cli). List and filter issues, create new tickets, transition issue status, manage sprints, and add comments — all from the terminal without opening a browser.
ci-routing
The canonical route-on-verdict protocol for a red CI diagnosis — fixable/flake/infra/needs-debug handling, the single-render rule, and the fix-then-re-watch loop. Use after orc-ci-investigator returns; /orc:ci Phase 3 and /orc:flow's post-open CI gate delegate here.
linear
Linear project management — issues, cycles, and projects via GraphQL API.