New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Cb Build Test

by BlkLeg in BlkLeg/CircuitBreaker

How Circuit Breaker is built, tested, packaged, and kept secret-safe — the make dev/verify/test targets, the PostgreSQL integration test database and its fixtures, the mono Docker image and native…

MITAuto-check passedDevOps & Cloud

Install Cb Build Test

skills CLI
$ npx skills add BlkLeg/CircuitBreaker --skill cb-build-test -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install BlkLeg/CircuitBreaker cb-build-test --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/BlkLeg/CircuitBreaker.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/cb-build-test .claude/skills/cb-build-test && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
cb-build-test
GitHub stars
201
Token cost
~1.9k tokens
SKILL.md length
789 words
Files
1
Skills in repo
6
Repo updated
First seen
Licence
MIT

At a glance

How Circuit Breaker is built, tested, packaged, and kept secret-safe — the make dev/verify/test targets, the PostgreSQL integration test database and its fixtures, the mono Docker image and native…

  • Tasks that involve Containers
  • SKILL.md covers Dev environment, Testing, Packaging and Secrets, vault, and air-gap
  • Calls make; needs CB_VAULT_KEY and CB_DB_PASSWORD
  • Tasks that involve Integration testing

What it does

Cb Build Test is an agent skill from BlkLeg/CircuitBreaker. How Circuit Breaker is built, tested, packaged, and kept secret-safe — the make dev/verify/test targets, the PostgreSQL integration test database and its fixtures, the mono Docker image and native deb/rpm/apk/AppImage packages, and the Fernet vault plus air-gap handling for credentials. Use this whenever running or writing tests, setting up or debugging the dev environment, working on Dockerfile.mono or the entrypoint/supervisord config, building or releasing packages, adding an integration that stores…

Its SKILL.md is about 1.9k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in DevOps & Cloud, covering Containers and Integration testing. It works with Docker and PostgreSQL. The repository describes itself as: Bring your homelab to life. A self-hosted IPAM and service mapper that visualizes complex hardware, compute, and network relationships in real-time. The licence is MIT.

When your agent uses it

  • Tasks that involve Containers
  • Tasks that involve Integration testing

Example prompts

  • “/cb-build-test”

Requirements

  • Docker
  • A credential in CB_VAULT_KEY
  • A credential in CB_JWT_SECRET

What it can do on your machine

Read from SKILL.md and the folder at commit fc44f2e. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • make

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names these keys or tokens, usually read from environment variables:

    • CB_VAULT_KEY
    • CB_DB_PASSWORD
    • CB_JWT_SECRET
    • NATS_AUTH_TOKEN
    • GPG_KEY_ID

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Cb Build Test loads about 1.9k tokens when it runs. Until then it costs about 153 tokens; SKILL.md has 789 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~153
When it runs · the whole SKILL.md, loaded when a task matches
~1.9k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from BlkLeg/CircuitBreaker at commit fc44f2e, republished under its MIT licence (© BlkLeg). 789 words, ~1,906 tokens.

Download SKILL.mdSave it as .claude/skills/cb-build-test/SKILL.md (or your agent's skills folder).
name
cb-build-test
description
How Circuit Breaker is built, tested, packaged, and kept secret-safe — the make dev/verify/test targets, the PostgreSQL integration test database and its fixtures, the mono Docker image and native deb/rpm/apk/AppImage packages, and the Fernet vault plus air-gap handling for credentials. Use this whenever running or writing tests, setting up or debugging the dev environment, working on Dockerfile.mono or the entrypoint/supervisord config, building or releasing packages, adding an integration that stores credentials, or touching anything involving CB_VAULT_KEY, CB_AIRGAP, or secret material.

Circuit Breaker — Build, Test & Packaging

Dev environment

bash
make install     # bootstrap once
make dev         # deps + migrations + backend + frontend + monitor workers
make deps-up     # Postgres / Redis / NATS in Docker, nothing else
make migrate     # alembic
make reset-oobe  # rewind to the first-run wizard

make dev runs the app natively against Dockerized dependencies. The Makefile calls this "ZERO DOCKER DRIFT" for make backend — the point is that the thing you debug is the thing that ships. Reach for make deps-native-up when you need prod parity, since it uses the same systemd units install.sh installs on a user's box.

Note make backend has no reload; make backend-watch does. The comment marks watch mode as post-fix only, because auto-reload masks import-time failures that a real start would surface.

Testing

bash
make test-backend         # tests/integration — provisions the test DB first
make test-frontend        # vitest
make test                 # both
make verify               # the pre-push gate
make verify-composed      # Tier 2: the browser suite, the composed journey and the mono smoke
make verify-composed-mono # Tier 2: build Dockerfile.mono and run the compose smoke CI runs

CB_COMPOSED_QUARANTINED=0 lifts QUAR-001 locally: the suite runs, minus the tests that have live register rows, which are deselected exactly as CI deselects them. Add CB_E2E_NO_DESELECT=1 to run those too; it is local only, and no workflow may set it. In CI, the composed journey will not re-run on the same inputs after a failure until each failed test is fixed or has a register row (scripts/ci/composed_rerun_guard.py). Local runs are not guarded, since they are how a fix gets made.

Test code lives in four places, and putting a test in the wrong one is how it silently never runs:

apps/backend/tests/           unit + service tests, own pyproject config
tests/integration/            backend-scoped, needs live PostgreSQL
tests/unit/                   repo-root scoped
tests/build/                  repo-policy / governance suites
apps/frontend/src/__tests__/  vitest, *.test.jsx

tests/build/ is a real enforcement suite — tracked-file policy, governance files, CLI parity, restart probes, version parity. It once collected zero tests because pytest's default norecursedirs contains "build"; pytest.ini at the repo root exists specifically to override that. Read the comments in that file before changing collection settings, because the failure mode is a suite that looks green and enforces nothing.

The integration database

make test-db runs scripts/ensure_test_db.py against CB_TEST_DB_URL and never drops the database. Integration tests run with:

CB_ALLOW_DEGRADED_DEPENDENCIES=true    # Redis/NATS optional
CB_ALLOW_DIRECT_EGRESS=true

These tests hit real PostgreSQL on purpose. Don't mock the database in tests/integration/ — assert against real persisted state, because the bugs worth catching there are constraint, migration, and transaction bugs that a mock cannot express. Fixtures and factories are in apps/backend/tests/conftest.py and factories.py.

When a test fails, decide explicitly whether the test is wrong (fixture drifted from the schema) or the code is wrong (missing field, bad query), and say which. Batch fixes by category instead of re-running the full suite after each one — the backend suite is minutes, not seconds.

Coverage is gated at --cov-fail-under=56, ratcheted to measured reality. Raise it only after coverage genuinely clears a higher number; never lower it to turn a build green.

Show full SKILL.md (404 more words)Show less

Packaging

Two distribution paths, both real:

Native packages are the primary install route:

bash
make build           # tarball + deb + rpm + apk + AppImage + .pkg.tar.zst
make build-release   # toolchain + build
make sign            # GPG-sign artifacts + SHA256SUMS (needs GPG_KEY_ID)
make sbom            # syft

Driven by scripts/build_native_release.py and nfpm.yaml (arch from GOARCH).

Publishing a version is not a packaging task: it goes through release.yml (make release-candidate, one approval, the promote creates the tag). Never push a v* tag by hand — cb-release has the flow and its failure modes.

The mono Docker image packs Postgres, NATS, Redis, backend, workers, and nginx into one container:

bash
make docker-build    # Dockerfile.mono -> $(DOCKER_REGISTRY):$(cat VERSION)

Facts about Dockerfile.mono that are easy to get wrong:

  • The runtime base is python:3.12-slim-bookworm — Debian, not Alpine. Only the frontend builder stage uses Alpine. Use apt-get, not apk.
  • The container intentionally starts as root so the entrypoint can fix volume ownership and wire the embedded services; supervisord then drops application processes to breaker:1000 (uid/gid 1000, no home, nologin). There is a checkov:skip=CKV_DOCKER_3 on that line explaining it. Do not "fix" this by adding a top-level USER breaker — the bootstrap breaks.
  • VOLUME ["/data"] is the only persistent path.
  • HEALTHCHECK targets /livez, deliberately not /health or /readyz: a failing healthcheck restarts the container, and readiness failing during a slow dependency start must not become a restart loop.
  • Multi-arch is amd64 + arm64, built as separate per-platform jobs joined with buildx imagetools create in release.yml — not one --platform invocation. The combined build was OOM-killed; the comment there records why. Preserve that split.

Secrets, vault, and air-gap

Credentials for integrations are Fernet-encrypted at rest under CB_VAULT_KEY via services/vault_service.py, with the API surface in api/vault.py. The key auto-rotates on a daily APScheduler job that re-encrypts stored credentials and hot-swaps the in-memory vault; cb-security-hardening covers the rotation contract in detail.

Rules that keep this safe:

  • Encrypt before the value reaches the database. Never log a credential, and never echo one back in an API response.
  • Secrets come from env, never from the image or a default in compose. CB_DB_PASSWORD, CB_VAULT_KEY, CB_JWT_SECRET, and NATS_AUTH_TOKEN all use ${VAR:?...} so a missing one fails the container at start rather than booting something insecure.
  • CB_AIRGAP=true must block outbound network calls. Any new integration that reaches the internet needs to honor it, plus the CIDR allowlist in core/network_acl.py. Air-gapped homelabs are a first-class deployment here, not an edge case.
  • Credential changes belong in the audit log.

gitleaks runs as a pre-commit hook. If it blocks a commit, remove the secret and rotate it — the value is already in your working tree's history if you staged it, so bypassing the hook is never the fix.

bash
make security-check    # gate mode — fails on HIGH/CRIT
make security-report   # full report, non-blocking

© BlkLeg, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .claude/skills/cb-build-test of BlkLeg/CircuitBreaker.

Open the folder on GitHubat commit fc44f2e

Compare with similar skills

Cb Build Test next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Cb Build Test compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Cb Build Test this skillBlkLeg/CircuitBreaker201—~1.9kAutomated safety check: PassMIT
Code PatternsAedelon/claude-code-blueprint120—~1.2kAutomated safety check: PassCustom licence
Run Testsansible-collections/community.postgresql144—~1kAutomated safety check: PassCustom licence
Monstermq Broker Configvogler75/monster-mq143—~2.2kAutomated safety check: PassGPL-3.0
Docker Deploymentfossasia/eventyay1.7k—~574Automated safety check: NotesApache-2.0
Mg Local DB Restoremodelguide/modelguide108—~645Automated safety check: PassMIT

Similar skills

  • Code Patterns

    Aedelon/claude-code-blueprint

    Reference patterns for REST APIs, pytest/vitest testing, Docker multi-stage builds, GitHub Actions CI/CD, PostgreSQL, TypeScript generics, Python async, and React Server Components.

    120 GitHub stars~1.2k tokensUpdated 7 mo ago
    DevOps & CloudAuto-check passed

  • Run Tests

    ansible-collections/community.postgresql

    Runs and writes tests (sanity, unit, integration) for the community.postgresql Ansible collection using ansible-test.

    144 GitHub stars~1k tokensUpdated 15 days ago
    DevOps & CloudAuto-check passed

  • Monstermq Broker Config

    vogler75/monster-mq

    Guide for configuring, deploying, and operating the MonsterMQ broker.

    143 GitHub stars~2.2k tokensUpdated 2 days ago
    DevOps & CloudAuto-check passed

  • Docker Deployment

    fossasia/eventyay

    Docker Compose, container services, deployment. An agent skill from fossasia/eventyay.

    1.7k GitHub stars~574 tokensUpdated yesterday
    DevOps & CloudAuto-check: notes

  • Mg Local DB Restore

    modelguide/modelguide

    Trigger phrases - "reset local db", "recreate local postgres", "restore dump to local", "reset local database", "load backup locally"

    108 GitHub stars~645 tokensUpdated 3 mo ago
    DevOps & CloudAuto-check passed

  • Cloud Test

    FreakStudioCN/mpy-hardware-extension

    用本地前端插件连云端后端做端到端测试 / test the local VS Code extension against the deployed cloud backend.

    132 GitHub stars~1.7k tokensUpdated 10 days ago
    DevOps & CloudAuto-check passed

More from BlkLeg/CircuitBreaker

  • Cb Code Quality

    BlkLeg/CircuitBreaker

    Circuit Breaker code conventions and the quality gates that actually block a push — ruff, mypy, eslint, the pytest coverage ratchet, and the make verify tiers.

    201 GitHub stars~1.9k tokensUpdated 3 days ago
    Auto-check passed

  • Cb Realtime API

    BlkLeg/CircuitBreaker

    How Circuit Breaker moves data between backend and frontend — the NATS internal bus, Redis pub/sub, the WebSocket stream endpoints and their first-message JWT handshake, SSE log/event streams, and…

    201 GitHub stars~1.7k tokensUpdated 3 days ago
    Auto-check passed

  • Cb Release

    BlkLeg/CircuitBreaker

    How a Circuit Breaker release is cut, approved, published and followed up — the candidate→approval→promote flow in release.yml, the release environment gate, the make release- targets, the…

    201 GitHub stars~1.8k tokensUpdated 3 days ago
    Auto-check passed

  • Cb Security Hardening

    BlkLeg/CircuitBreaker

    Enforces Circuit Breaker security hardening conventions across backend, frontend, Docker, and nginx.

    201 GitHub stars~2.1k tokensUpdated 3 days ago
    Auto-check passed

  • Cb Automation

    BlkLeg/CircuitBreaker

    The maintenance automation around Circuit Breaker — which bots and scheduled workflows exist (Discord notifications, ledger watch, branch cleanup, Dependabot lockfile sync, the required-checks…

    201 GitHub stars~2.4k tokensUpdated 3 days ago
    Auto-check passed

Works with

Categories

Questions about Cb Build Test

What does Cb Build Test do?

How Circuit Breaker is built, tested, packaged, and kept secret-safe — the make dev/verify/test targets, the PostgreSQL integration test database and its fixtures, the mono Docker image and native…. Cb Build Test is an agent skill from BlkLeg/CircuitBreaker. How Circuit Breaker is built, tested, packaged, and kept secret-safe — the make dev/verify/test targets, the PostgreSQL integration test database and its fixtures, the mono Docker image and native deb/rpm/apk/AppImage packages, and the Fernet vault plus air-gap handling for credentials.

When should I use Cb Build Test?

Cb Build Test fits situations like: tasks that involve Containers; tasks that involve Integration testing.

How do I install Cb Build Test in Claude Code?

Run `npx skills add BlkLeg/CircuitBreaker --skill cb-build-test -a claude-code`. Or copy the skill folder (.claude/skills/cb-build-test in BlkLeg/CircuitBreaker) into .claude/skills/cb-build-test in your project. Claude Code loads it when a task matches its description.

How do I install Cb Build Test in Codex?

Run `npx skills add BlkLeg/CircuitBreaker --skill cb-build-test -a codex`. Or copy the skill folder (.claude/skills/cb-build-test in BlkLeg/CircuitBreaker) into .agents/skills/cb-build-test in your project. Codex loads it when a task matches its description.

Can I use Cb Build Test in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add BlkLeg/CircuitBreaker --skill cb-build-test -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/cb-build-test, .gemini/skills/cb-build-test, .github/skills/cb-build-test and .opencode/skills/cb-build-test in your project.

What does Cb Build Test need to run?

Going by SKILL.md and its folder, Cb Build Test needs the command-line tools its instructions call (make) and credentials named CB_VAULT_KEY, CB_DB_PASSWORD, CB_JWT_SECRET and NATS_AUTH_TOKEN. Our summary lists: Docker; A credential in CB_VAULT_KEY; A credential in CB_JWT_SECRET.

Does Cb Build Test access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Cb Build Test safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Cb Build Test use?

Cb Build Test is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Cb Build Test use?

About 1.9k tokens (SKILL.md is roughly 7.6k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Cb Build Test?

Skills that share tags, products or a category with Cb Build Test: Code Patterns (Aedelon/claude-code-blueprint, 120 stars), Run Tests (ansible-collections/community.postgresql, 144 stars), Monstermq Broker Config (vogler75/monster-mq, 143 stars) and Docker Deployment (fossasia/eventyay, 1.7k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Cb Build Test?

BlkLeg (a GitHub user) maintains it in BlkLeg/CircuitBreaker, which has 201 GitHub stars. The repository holds 6 skills in this directory. The repository was last updated on October 5, 2026.

Source: BlkLeg/CircuitBreaker on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.