Install
$ agentstack add skill-eabs86-ci-bootstrap-ci-bootstrap ✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
About
CI Bootstrap
You are going to build a quality and delivery pipeline for THIS repository, inspired by a mature polyglot-monorepo reference, but adapted to the real stack and conventions found here. Do NOT copy technologies that don't exist in this project. Detect, confirm, then implement.
Step 1 — Choose the operating mode
If the user passed a mode in the arguments (autopilot, auto, guided, interactive, step-by-step), use it. Otherwise, ask before doing anything else:
> How do you want to run this? > > 1. Autopilot — I run all phases end to end with sensible defaults. I only stop if I hit a > decision that is genuinely ambiguous and risky (e.g., can't tell which branch is production). > 2. Guided — I pause after each phase, show you what I found / what I'm about to write, and > wait for your confirmation before touching anything.
Mode rules:
- Autopilot: run Phases 0→4 without pausing. Resolve ambiguity with the defaults documented in
references/ (and say which default you picked in the final summary). Only stop for the blocking questions listed at the end of Phase 0 — and even then, first try to resolve them from evidence (remote branches, existing configs, commit history).
- Guided: at the end of each phase, present results and the plan for the next phase as a short
summary plus concrete questions (use structured questions when available). Do not write any file before Phase 0 is confirmed.
In both modes, Phase 0 is strictly read-only.
Step 2 — Execute the phases
Each phase has a detailed reference file. Read it when you reach that phase — not before.
| Phase | What | Reference | |-------|------|-----------| | 0 | Discovery (read-only stack & convention detection) | [references/discovery.md](references/discovery.md) | | 1 | Pre-commit hooks (.pre-commit-config.yaml) | [references/pre-commit.md](references/pre-commit.md) | | 2 | CI (.github/workflows/ci.yml + security workflow) | [references/ci.md](references/ci.md) | | 3 | CD (deploy skeletons, only activated with confirmed targets) | [references/cd.md](references/cd.md) | | 4 | Validation & delivery | [references/validation.md](references/validation.md) |
Non-negotiable principles (the "why" behind the reference)
These apply in every mode, every phase. They are not stylistic preferences — each one prevents a concrete failure mode.
- Version parity pre-commit ↔ CI. Pin the SAME version of every tool in both places. A hook
that passes locally and fails in CI (or vice versa) destroys trust in the pipeline.
- Gating by cost.
- On PRs: only fast checks — format check, lint, security scan, light unit tests.
- The heavy suite runs only on
pushto the integration and production branches:
``yaml if: github.event_name == 'push' && (github.ref == 'refs/heads/' || github.ref == 'refs/heads/') `` Make this EXPLICIT in a YAML comment and tell the user that "a green PR does not guarantee the full suite passed".
- Concurrency.
cancel-in-progress: ${{ github.ref != 'refs/heads/' }}—
production runs are never cancelled.
- Path scoping. Each linter only runs on the files of its own package/service
(files: regex in pre-commit; paths: filters and working-directory in CI).
- Cross-platform hooks. For local hooks that call binaries from
node_modules, use a Node
wrapper script (node scripts/precommit-runner.mjs ), never bash -c 'cd ... && npx ...' — bash may be missing from PATH on Windows. Only applies if there is a JS frontend.
- Surgical changes. Do not rewrite CI that works; add the minimum. Do not delete files outside
the task's scope — point at problems, don't erase them.
- No invented credentials. All secrets via
secrets.*. If the deploy target is unclear,
deliver disabled skeletons with documented TODOs instead of guessing.
- Reuse before replace. If the repo already uses flake8, don't silently switch it to Ruff.
Tool swaps are a user decision, never a default.
Step 3 — Deliver
Finish with a single final summary (see references/validation.md for the checklist): what was created, decisions and defaults taken, secrets the user must register, and next steps. In Guided mode this is the last checkpoint; in Autopilot it is the only long report the user sees — make it count.
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: eabs86
- Source: eabs86/ci-bootstrap
- License: MIT
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet — be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.