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 agentmods add skills/viknesh20-20/claude-code-tool-kit/ci-pipelinenpx skills add viknesh20-20/claude-code-tool-kit --skill ci-pipelinegit clone --depth 1 https://github.com/viknesh20-20/claude-code-tool-kitWrote 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/viknesh20-20/claude-code-tool-kit/ci-pipeline)<a href="https://agentmods.dev/skills/viknesh20-20/claude-code-tool-kit/ci-pipeline"><img src="https://agentmods.dev/badge/skills/viknesh20-20/claude-code-tool-kit/ci-pipeline.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.00046 | $0.00674 |
| Opus 5 | $0.00023 | $0.00337 |
| Sonnet 5 | $0.00009 | $0.00135 |
| Haiku 4.5 | $0.00005 | $0.00067 |
Grade A, and why
ci-pipeline 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 6d 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 — 88 lines — stays where its author put it; the contents beside it link to each section on GitHub.
CI Pipeline Generator
Detect Project Stack
!ls package.json requirements.txt pyproject.toml go.mod Cargo.toml *.csproj *.sln Gemfile composer.json mix.exs Makefile Dockerfile 2>/dev/null
!ls .github/workflows/ .gitlab-ci.yml Jenkinsfile .circleci/ .travis.yml bitbucket-pipelines.yml 2>/dev/null
!cat package.json 2>/dev/null | grep -E '"(scripts|devDependencies)"' -A 10 | head -20
Pipeline Design
Step 1: Detect Requirements
From project files, determine:
- Language and version (Node 20, Python 3.12, Go 1.22, etc.)
- Package manager (npm, pnpm, yarn, pip, poetry, cargo, etc.)
- Test command
- Lint command
- Build command
- Required services (database, Redis, etc.)
Step 2: Generate Pipeline Stages
Stage 1: Install
- Cache dependencies for fast subsequent runs
- Use lock file hash as cache key
Stage 2: Lint
- Run linter (ESLint, ruff, golangci-lint, clippy, etc.)
- Run type checker if applicable (tsc, mypy, go vet)
- Run formatter check (prettier, black, gofmt)
Stage 3: Test
- Run unit tests with coverage
- Run integration tests (with service containers if needed)
- Upload coverage report
Stage 4: Build
- Production build
- Verify build artifacts are created
Stage 5: Security (optional)
- Dependency vulnerability scan
- Secret scanning
- SAST if available
Stage 6: Deploy (placeholder)
- Staging deployment (on push to main)
- Production deployment (on tag/release)
- Mark as manual/approval required
Step 3: Platform-Specific Output
GitHub Actions:
name: CI
on: [push, pull_request]
jobs:
ci:
runs-on: ubuntu-latest
steps: ...
GitLab CI:
stages: [install, lint, test, build, deploy]
Step 4: Optimizations
- Dependency caching (npm cache, pip cache, cargo cache)
- Parallel test execution where possible
- Matrix builds for multiple versions (if needed)
- Fail-fast on lint errors (don't waste time on tests)
- Artifact upload for build output
Rules
- Always include a lint stage — catch issues early
- Always include caching — speed up repeat runs
- Keep the pipeline under 10 minutes for PRs
- Don't hardcode versions — use variables or matrix
- Include both push and PR triggers
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.
- 6d ago First seen · 88 lines · 46 tokens per session scan A f8906e50e079
ci-pipeline is a skill published in the GitHub repository viknesh20-20/claude-code-tool-kit (7 stars, last pushed 4mo ago), licensed MIT. It adds 46 tokens to every session and 674 once invoked, about $0.0002 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-31.
Other skills, from other repositories
tutti-app-release
Set up, review, run, or debug external repositories that publish a Tutti workspace app through the reusable Tutti App Release GitHub Actions workflow. Use for caller workflows, tutti.app.json manifests, @tutti-os/app-release-tools, S3/CloudFront release hosting, latest.json, versions.json, catalog.json, catalog-only…
fix-failing-pipelines
This skill should be used when the user asks to "fix pipelines", "fix CI", "check staging pipelines", "fix failing workflows", "fix failing actions", or wants to find and fix failing GitHub Actions workflows on the staging branch of the babysitter repo.
beevibe-verify-pr
CI verification before marking a PR-bearing task done. Use BEFORE calling mcpbeevibeupdateprogress(done) on any session whose deliverable is a pull request — including the first dispatch (you opened the PR with gh pr create) and any revision dispatch (you pushed new commits to an existing PR). Watches the PR's…
ci-troubleshoot
Diagnose failed GitHub Actions runs for pi-agent-dashboard: the 10-file workflow taxonomy, the release pipeline, known failure modes, and how to read gh run logs and retrigger jobs. Use when a CI run is red, a release is stuck, a workflow won't dispatch, or you need to know which workflow does what. See release-cut to…
suede-ci-gate
Suede Labs AI CI and branch-protection wiring for any repo and any stack: path-aware jobs, a single aggregator required check that cannot deadlock, lockfile hygiene, runtime pinning from the repo, and the exact branch-protection settings. Use when asked to set up CI, protect main, make CI block a bad merge, fix a…
release-readiness-check
Verify all prerequisites are met before a release by checking PRs, CI/CD status, environment health, and blocking issues across GitHub, ArgoCD, and Jira. Use before cutting a release, deploying to production, or during release planning.