Wire CI

SkillMonitoring & ops

Sets up CI pipelines for your project by detecting its code host and writing ready-made workflow files.

Available today. Use it from your connected AI after setup.

Add ahel to your AI once: Claude, ChatGPT, Cursor, Claude Code or Codex. Then ask it to use this.

Then ask your AI: use the Wire CI skill

About this skill

CI pipeline setup with bundled, forge-neutral templates and local validation. Detects the forge from the git remote, generates workflows for supported forges, and skips honestly for the rest. The CI equivalent of wire-observability.

What this skill tells your AI

The instructions your AI receives, as published by danielvm-git/bigpowers in skills/wire-ci/SKILL.md and read by ahel’s review.

HARD GATE (supported forges only) — Do not ship a project without CI. Run this skill before first merge to main.

On a forge bigpowers ships no templates for, this skill is not a gate: it reports the forge, explains what it cannot do, and exits 3. A gate that cannot run must not claim it did. See § Unsupported forges.

HARD GATE — CI that is untestable locally will break every cycle. Always run --validate after generating workflows and --dry-run before pushing.

Generate, validate, and test CI workflows. Detects the forge and project type, copies a bundled template, and verifies locally before anything reaches CI.

Forge resolution

scripts/lib/detect-forge.sh resolves the forge, first match wins: BIGPOWERS_FORGE env var → forge: in specs/forge.yaml → the origin remote URL → unknown.

bash scripts/wire-ci.sh --detect     # report forge + stack, write nothing
bash scripts/wire-ci.sh --plan       # show the template that would be used
bash scripts/wire-ci.sh --apply      # write the workflow

GitHub ships templates (.github/workflows/). GitLab, Bitbucket, Codeberg, and Gitea are detected but unsupported — --apply writes nothing and exits 3.

Template source — configurable, bundled by default

Templates live in docs/templates/ci/<forge>/ inside the bigpowers package, so there is no network dependency on any third party's repository. Override with BIGPOWERS_CI_TEMPLATES=/path/to/your/templates, laid out as <root>/<forge>/test-build-release-<stack>.yml.

What this sets up

  1. Test Build Release workflow — lint → test → build → release in one needs: chain
  2. --validate mode — YAML syntax, workflow permissions, required secrets, common pitfalls
  3. --dry-run mode — runs workflows locally via act before push
  4. Failure pattern documentation — see the table below

Deploy workflows are not bundled: they are platform-specific. See REFERENCE.md for a worked example.

Process

1. Detect forge and stack

bash scripts/wire-ci.sh --detect

Stack detection reads the project root:

ManifestStackBundled template
Cargo.tomlRusttest-build-release-rust.yml
package.jsonNodetest-build-release-node.yml
pyproject.toml / setup.pyPythontest-build-release-python.yml
go.modGotest-build-release-go.yml

No recognized manifest → exit 3 with the list of manifests it looked for. Do not guess.

2. Apply the template

bash scripts/wire-ci.sh --apply

Do not rename the workflow name: field — deploy listens for "Test Build Release".

Edit placeholders after copying: language versions, APP_TYPE, SITE_URL.

3. Unsupported forges

--apply writes nothing and exits 3. Your options, in the order the runner prints them:

  • point BIGPOWERS_CI_TEMPLATES at templates for your forge
  • pin forge: github in specs/forge.yaml if the remote is misdetected
  • write the CI config by hand

Contributing a docs/templates/ci/gitlab/ set and adding gitlab to FORGE_SUPPORTED_LIST is the natural next slice — per-forge command mapping (gh pr checks → glab ci status) is not implemented yet.

4. Validate workflows (--validate)

See REFERENCE.md. Exit codes: 0 clean, 1 YAML syntax errors, 2 warnings only.

5. Dry-run workflows (--dry-run)

See REFERENCE.md.

act runs workflows in a local Docker environment — the most accurate pre-push validation. gh workflow run sends the workflow to GitHub but does not execute locally.

6. Document common CI failure patterns

FailureCauseFix
npm publish failsNPM_TOKEN not set as repo secretAdd NPM_TOKEN to repo secrets
semantic-release fails on pushMissing permissions: contents: writeAdd it to the release job
cargo publish auth failCARGO_REGISTRY_TOKEN not setAdd token to env or ~/.cargo/config.toml
go vet failsGo version mismatchUse go-version-file: go.mod
cargo clippy errorsNew nightly lintsPin the toolchain; cargo clippy --fix
act not foundDocker not running or act missingbrew install act; docker ps
Hardcoded Node version stale.nvmrc exists but workflow hardcodesUse node-version-file: .nvmrc
Deploy never runsTBR workflow renamedKeep name: Test Build Release
Release rebuilds binaryArtifact not downloadedrelease must download-artifact from build

Verify

→ verify: bash scripts/wire-ci.sh --self-test → verify: test -f docs/templates/ci/github/test-build-release-node.yml && test -f scripts/lib/detect-forge.sh → verify: grep -q wire-ci SKILL-INDEX.md

Signals

GitHub stars
248
Forks
19
Last commit
Sep 2026

ahel review

  • K1binfo
    installs-packages

Automated review, not a security audit. Ruleset v1+k2.

Advanced
Item type
skill
Key
wire-ci
Source
github.com/danielvm-git/bigpowers