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 arcasilesgroup/ai-engineering --skill build-checkgit clone --depth 1 https://github.com/arcasilesgroup/ai-engineeringWrote 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/arcasilesgroup/ai-engineering/build-check)<a href="https://agentmods.dev/skills/arcasilesgroup/ai-engineering/build-check"><img src="https://agentmods.dev/badge/skills/arcasilesgroup/ai-engineering/build-check/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/arcasilesgroup/ai-engineering/build-check"><img src="https://agentmods.dev/badge/skills/arcasilesgroup/ai-engineering/build-check.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.00073 | $0.01665 |
| Opus 5.5 | $0.00029 | $0.00666 |
| Sonnet 5.5 | $0.00015 | $0.00333 |
| Haiku 4.5 | $0.00007 | $0.00167 |
Grade A, and why
build-check 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 1mo 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 — 138 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Build check
The machine's verdict, not an opinion. Everything here either passes or fails, and a failure is never a judgment call. Run this before the reasoning-based reviews — reviewing code that does not compile wastes effort on a file that is about to change.
Fast, deterministic, and the highest-value-per-token check in the set.
Read .claude/review/CONVENTIONS.md first — §1 for stack detection, §3 for scope
(you need it to tell a pre-existing failure from one this change introduced), and
§6 for where the report goes. Your report format differs from the other skills'
by design: this one reports gates and failures, not severity-ranked findings.
1. Discover the gates — never assume them
Do not run commands from memory or from a template. A guessed command that does not exist wastes a minute and produces a scary error that is not a finding.
Read the project's own definition of its gates, in this order:
CLAUDE.md/AGENTS.md— if the commands are written down, use exactly those and skip the rest of this discovery.- The manifest's script block —
package.jsonscripts,Makefiletargets,pyproject.toml[tool.*]sections,Cargo.toml,composer.jsonscripts,Taskfile.yml,justfile. - CI config —
.github/workflows/*.yml,.gitlab-ci.yml,Jenkinsfile. This is the most reliable source there is: it is the exact set of gates the project already enforces on every push, in the order it enforces them. - Config files as evidence a tool is configured — a
tsconfig.json, an eslint config,.ruff.toml,.golangci.yml,pytest.ini.
Use the project's package manager, detected from its lockfile — pnpm-lock.yaml
→ pnpm, yarn.lock → yarn, bun.lockb → bun, otherwise npm. Running
npm in a pnpm workspace produces failures that belong to you, not the code.
Typical shapes, as a reference for what to look for — not a list to run:
| Ecosystem | Types | Lint | Test | Build |
|---|---|---|---|---|
| Node/TS | tsc --noEmit |
eslint . / biome check |
vitest run, jest |
framework build script |
| Python | mypy, pyright |
ruff check |
pytest |
python -m build |
| Go | go vet |
golangci-lint run |
go test ./... |
go build ./... |
| Rust | — | cargo clippy |
cargo test |
cargo build --release |
| JVM | compiler | spotbugs, checkstyle |
mvn test |
mvn package |
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.
- 1mo ago First seen · 138 lines · 73 tokens per session scan A 5a618a48fadf
build-check is a skill published in the GitHub repository arcasilesgroup/ai-engineering (61 stars, last pushed 2d ago), licensed Apache-2.0. It adds 73 tokens to every session and 1,665 once invoked, about $0.0003 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-09-12.
Other skills, from other repositories
ai-agents-empirical-probe-toolkit
Prove-it methods for this repo. Six recipes for runtime-contract probes, guard and threshold calibration, eval A/B, docs-vs-reality audits, reproduce-on-main CI triage, and negative-control test design, each with a worked example from repo history. Use when you say probe the runtime contract, calibrate this guard…
megalinter-check
Collect MegaLinter lint errors for the current repository. Use when the user wants to know if the code passes linting, why the MegaLinter CI job fails, or before/after fixing lint errors. Two modes - watch a CI job (GitHub Actions, GitLab CI, Azure Pipelines, Bitbucket Pipelines) and parse its logs, or run MegaLinter…
hotfix
Fixes an observed defect with reproducible evidence in one call: writes a short trace doc before touching code, implements the fix, and backs it with a regression test written before the fix. Production incidents are the motivating case, not a gate. When blocked, it halts by name and saves the doc for a later call to…
megalinter-fix
Fix the errors reported by MegaLinter. Use after megalinter-check found errors, or when the user pastes MegaLinter/CI lint errors and wants them fixed. Applies safe fixes automatically (auto-fix linters first, then guided manual fixes using per-linter fix guides), asks the user when fixing is ambiguous, and can…
analyze-failures
Triage Katalon True Platform/TestOps test failures and file defects. Use when you need to investigate failed test results, classify each failure as product defect vs automation defect vs environment/data issue, cluster failures by common signature, find likely root cause from execution data, and optionally create…
GitHub Copilot Testing Patterns
Effective patterns for using GitHub Copilot to generate, refactor, and maintain test code including prompt engineering for test generation, Copilot Chat for debugging, inline suggestions for assertions, and workspace context optimization.