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 ShaftHQ/SHAFT_ENGINE --skill ci-cdgit clone --depth 1 https://github.com/ShaftHQ/SHAFT_ENGINEWrote 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/shafthq/shaft_engine/ci-cd)<a href="https://agentmods.dev/skills/shafthq/shaft_engine/ci-cd"><img src="https://agentmods.dev/badge/skills/shafthq/shaft_engine/ci-cd/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/shafthq/shaft_engine/ci-cd"><img src="https://agentmods.dev/badge/skills/shafthq/shaft_engine/ci-cd.svg" alt="Reviewed on agentmods" width="80" 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.00047 | $0.01664 |
| Opus 5.5 | $0.00019 | $0.00666 |
| Sonnet 5.5 | $0.00009 | $0.00333 |
| Haiku 4.5 | $0.00005 | $0.00166 |
Grade A, and why
ci-cd 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 today.
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 — 91 lines — stays where its author put it; the contents beside it link to each section on GitHub.
CI/CD tiers and PR merge time
Learned in a large monorepo: the median open→merge time was about 30 minutes, and the gate took 6–11 minutes. Fix the loop first, then the slowest leg.
Targets (evidence)
- Merge-blocking gate ≤ 10 min p90: Fowler's 10-minute build.
- Open→merge median ≤ 15 min for auto-merge PRs. DORA elite lead time is < 1 h, and the LinearB elite merge time is < 1 h.
- Small changes: elite PR size is < ~90 changed lines. Google's median review is < 4 h with one reviewer.
Measure first
- Gate wall-clock:
gh run list --workflow <gate> --event pull_request --status success -L 40 --json createdAt,updatedAt. Report p50, p90 and max. - Open→merge:
gh pr list --state merged -L 30 --json createdAt,mergedAt. Report the median. - Runs per PR and the failure share. Re-push loops usually cost more than slow legs do.
- Per-job durations plus queue time. The critical path is the slowest leg, not the sum.
Three tiers
| Tier | Runs | Rule |
|---|---|---|
| PR (blocking) | path-filtered affected-module build + unit tests, lint/guards, required governance | only what MUST block; light |
| Push to main | the same path filters (tests for unrelated modules never run), never cancelled, plus slow OS/E2E legs | a red leg opens or updates one tracker issue, which auto-closes on green |
| Nightly/scheduled | full cross-OS acceptance, live/external suites, security scans, EAP verifiers | tracker issue, no Closes keyword |
| Release | full verify, always | never weakened |
Move a leg off PR only when all three hold:
- it is > 5 min or is the critical path;
- it caught no PR-only regression in its last ~20–30 runs;
- the main tier runs it.
Keep a live-label opt-in such as ci:<leg>, plus ci:full, and re-run the gate when the label is added. Read labels from the API, because re-runs replay the old event payload.
Quality layers are never removed
Tests, static analysis, coverage and review may be rearranged or added, but never removed. The one exception is a layer that repeated, evidenced analysis proves an utter waste. Moving a layer, for example from PR to main or from blocking to reporter, must keep equal or better coverage:
- a blocking in-repo equivalent;
- findings resolved before merge;
- a tracker issue on main.
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.
- today Changed · +18 lines · -6 tokens per session 5ca7587243ec
- yesterday First seen · 73 lines · 53 tokens per session scan A 0ce97367378a
ci-cd is a skill published in the GitHub repository ShaftHQ/SHAFT_ENGINE (414 stars, last pushed yesterday), licensed MIT. It adds 47 tokens to every session and 1,664 once invoked, about $0.0002 per session on Opus 5.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-10-16.
Other skills, from other repositories
513-frameworks-micronaut-db-migrations-flyway
Use when you need to add or review Flyway database migrations in a Micronaut application — micronaut-flyway, db/migration scripts, flyway.datasources. configuration, and alignment with JDBC or Micronaut Data. This should trigger for requests such as Add or review Flyway migrations in a Micronaut project; Configure…
aws-cloudformation-task-ecs-deploy-gh
Provides patterns to deploy ECS tasks and services with GitHub Actions CI/CD. Use when building Docker images, pushing to ECR, updating ECS task definitions, deploying ECS services, integrating with CloudFormation stacks, configuring AWS OIDC authentication for GitHub Actions, and implementing production-ready…
shipping-and-launch
Pre-deploy hygiene for a Spring Boot 4 feature — verify gates, capture rollback plan, sign off observability, generate release notes, and stage the rollout. Used by /ship after /review approves the diff. The agent never deploys; it produces the plan a human executes.
zb-release-pipeline
Generate a GitHub Actions pipeline that builds a zb (Zero Dependencies Builder) project and publishes a GitHub Release with the produced JAR. Use whenever the user wants CI/CD, a build pipeline, a release workflow, or GitHub Actions for a zb-based Java project — phrases like "set up GitHub Actions for this zb…
desktop-and-build-footguns
Desktop JVM and build traps: JNA natives, bundling, memory, packaging, code signing, R8, deep links, Gradle and CI releases. Use when a desktop build fails packaged, signed, on another OS or arch, or in CI.
00-bkci-global-architecture
A BK-CI architecture skill for understanding how modules work together across a software delivery pipeline. BK-CI is the project named in the skill description.