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/harmont-dev/harmont-cli/validate-cinpx skills add harmont-dev/harmont-cli --skill validate-cigit clone --depth 1 https://github.com/harmont-dev/harmont-cliWhat 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 | $0.00060 | $0.00545 |
| Opus 5 | $0.00030 | $0.00272 |
| Sonnet 5 | $0.00012 | $0.00109 |
| Haiku 4.5 | $0.00006 | $0.00055 |
Grade A, and why
validate-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 yesterday.
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 — 39 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Validate that the project's CI pipeline passes. Run the pipeline locally with hm run, diagnose and fix any failures, and only push to remote once local CI is green.
When to use
- The user asks you to "make CI green", "run CI", "validate the pipeline", or similar
- A feature or bugfix is complete and ready to push
- Before creating a pull request
- The user explicitly requests local validation before pushing
When NOT to use
- In the middle of active development across multiple commits — wait until the logical unit of work is done
- On every individual commit in a multi-commit feature — run once at the end
- When the user only asks you to commit (committing does not imply CI validation)
- When the user explicitly says to skip local validation
What this does
hm run executes the project's CI pipeline locally inside Docker containers. It runs the same steps that would run on Harmont Cloud, but on your machine. This catches failures before they reach remote CI.
Procedure
- Run
hm run -k --logsfrom the project root (-kcontinues past failures so you see every broken step in one run;--logsstreams full build logs for easier diagnosis) - If it exits 0 — pipeline passed. Inform the user and proceed with push if requested.
- If it exits non-zero — pipeline failed. Read the output, diagnose ALL failures (not just the first), fix every issue, and re-run
hm run -k --logsuntil it passes. - Only after local CI is green: push to remote. If the user wants cloud validation too, they can run
hm run --backend cloud --logsor wait for the remote CI triggered by the push.
Important
hm runis the ONLY correct way to run this project's CI locally. Do NOT try to reverse-engineer pipeline steps by reading.hm/files and running commands manually.- Do NOT commit, push, and wait for remote CI results as a way to "test" — always validate locally first.
- Exit code 0 = pass, non-zero = fail. Exit code 130 = user cancelled (Ctrl-C).
- If Docker is not running,
hm runwill fail. Tell the user to start Docker.
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.
- yesterday First seen · 39 lines · 60 tokens per session scan A 63aa0057dc35
validate-ci is a skill published in the GitHub repository harmont-dev/harmont-cli (21 stars, last pushed 1mo ago), licensed Apache-2.0. It adds 60 tokens to every session and 545 once invoked, about $0.0003 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
zuke-write-build
Write or edit a Zuke build (zuke.ts) — the code-first, strongly-typed build system for Deno/TypeScript. Use when adding or changing targets, wiring dependencies, calling a tool wrapper (DenoTasks, NpmTasks, DockerTasks, ...), generating CI, or authoring/refactoring a zuke.ts build file. For first-time project…
zuke-setup
Set up Zuke — a code-first, strongly-typed build automation system for Deno/TypeScript — in a project. Use when the user wants to add Zuke to a repo, scaffold a zuke.ts build file, install the Zuke CLI, or bootstrap the ./zuke launcher. After scaffolding, switch to the zuke-write-build skill to author targets.
ci-secure
Scans a repo's GitHub Actions workflows for the ten critical CI/CD attack vectors — template injection, fork code executed with privileges (pwn requests), cache poisoning, impostor action SHAs, secrets dumps, GITHUBENV hijack, write-token untrusted triggers, credentials in caches/artifacts, unverified remote code…
skills-registry-security
Checks the third-party security audit status of a skill published to a skills registry (skills.sh) across every cached surface, decides whether a failing finding is real or points at content already removed, and drives a stale badge to green unattended. Runs a real install to capture what users see, reads the…
sling
Diagnoses GitHub Actions failures and attributes CI time and cost using StarSling's sling CLI. Invoke this BEFORE using gh or fetching any logs whenever the user asks why a job or run failed, what made a run slow, about runner minutes or CI cost, asks to re-run or cancel a run, or pastes a GitHub Actions URL — sling…
ci-score
Grades a repository's GitHub Actions configuration against CI best practices (the CI Score: eleven pass/fail configuration facts computed from the repo's own workflow YAML) and hands back concrete fixes for every gap, ranked by impact and risk, each with an apply-now option and a paste-able agent prompt. Use when: (1)…