autonomic-bot
49854472b8
One operator interface for both toolkits (operator decision 2026-08-04): - vendor/autonomic-recipe-maintainer: ARM pinned as a submodule at acd5cfb (latest). - scripts/gen-cctest-skills.py: generates a cctest-<name> wrapper pair (.opencode canonical + .claude thin) for every ARM skill — frontmatter carries ARM's own description tagged [recipe-maintainer/cctest]; body points at the canonical submodule SKILL.md, sets cwd/sandbox context, and states the policy overrides (auto-merge-style ARM flows need per-run operator opt-in; never touch cc-ci infra from an ARM skill; submodule is read-only here). Re-run after every submodule bump. - 30 cctest-* wrappers generated. - /help: cctest family section + situation-table rows + the cc-ci-vs-cctest rule of thumb. cctest = the recipe-maintainer test server; these skills run against it + the ARM sandbox, never against the cc-ci CI server/swarm.
5.4 KiB
name, description
| name | description |
|---|---|
| help | Operator orientation - lists every skill available on this orchestrator with what it does and when to reach for it, grouped by purpose (status, weekly maintenance, host updates, tests, enrollment, recovery, reporting), plus a "what do you want to do?" guide for common situations. Read-only. Invoke as /help. |
help
Orient the operator: what this orchestrator can do, via which skill, and what's sensible next.
First, enumerate the live roster (skills get added — don't trust this file's list blindly):
ls /srv/cc-ci-orch/.opencode/skills/ # canonical definitions (one dir per skill)
For any skill not described below, read its SKILL.md frontmatter description and include it.
Then present the roster grouped as follows, and close with the situation guide.
The roster (curated descriptions — merge with the live listing)
Status & orientation
- /cc-ci-status — the comprehensive read-only health/status check: weekly-run outcomes,
report publishing, stale tests, CVE-PR aging, host update recency, service health, bridge
!testmepath. EndsALL HEALTHYor prioritized findings each mapped to a skill. Start here when unsure. - /help — this orientation.
Weekly maintenance (recipes)
- /upgrade-all — the weekly sweep: survey every
weeklyrecipe, open verified upgrade PRs, write the summary + report. Runs on a timer (cc-ci-upgrade-all.timer, Fri 02:00 UTC); invoke manually to run it now. - /recipe-upgrade — the same pipeline for ONE recipe (plan → bump → verify green →
PR).
--with-testsalso fixes that recipe's stale test. - /recipe-report — (re)generate the weekly report page for report.ci.commoninternet.net.
Tests
- /cc-ci-tests-update — fleet-wide stale-test cleanup: find tests broken by legitimate upstream changes, fix without weakening, verify, merge the test PRs.
- /ci-test-review — diagnose a specific red CI run: classify recipe bug vs stale test vs CI-server bug, then fix on the right side.
cc-ci itself
- /cc-ci-server-update — bump the CI server host's nixpkgs/sops-nix, deploy with
build →
nixos-rebuild test→ switch + health gate, PR merged on green. - /cc-ci-orchestrator-update — same for this orchestrator host (self-update caveats).
- /cc-ci-update — both of the above plus /cc-ci-tests-update in one pass.
- /ci-dev-workflow — harness/CI-server development discipline (changing cc-ci itself).
Enrollment
- /recipe-enroll — add a NEW recipe to the maintained set end-to-end: mirror, test suite, bridge + inventory enrollment, full-suite-green verification, bridge deploy.
Recovery
- hetzner-server-recovery — when a Hetzner host is unreachable over SSH/tailscale: API
reboot, rescue mode, GRUB generation selection (submenu ids are
1>N), console access.
Recipe-maintainer toolkit (/cctest-* — the ARM sandbox + cctest test server, NOT cc-ci)
The full autonomic-recipe-maintainer skill set, vendored as a pinned submodule
(vendor/autonomic-recipe-maintainer) and exposed with the cctest- prefix — ~30 skills for
hands-on recipe work against the recipe-maintainer cctest test server and local abra
sandbox: /cctest-intro (start here), /cctest-recipe-overview, /cctest-recipe-init,
/cctest-recipe-deploy, /cctest-recipe-test*, /cctest-recipe-upgrade-plan|apply|full,
/cctest-new-recipe-guide, sandbox/instance management (/cctest-setup-sandbox,
/cctest-t1cc-start|stop), and more — enumerate with ls .opencode/skills | grep ^cctest-.
Rule of thumb: verifying/shipping against the CI pipeline → the cc-ci skills above;
exploratory or hands-on recipe development on a test instance → /cctest-*. cc-ci policy
overrides apply (auto-merge-style ARM flows need per-run operator opt-in; never touch cc-ci
infra from an ARM skill). After a submodule bump run scripts/gen-cctest-skills.py.
"What do you want to do?"
| Situation | Do this |
|---|---|
| "How is everything?" | /cc-ci-status |
| "Run the weekly upgrades now" | /upgrade-all (or systemctl start cc-ci-upgrade-all.service) |
| "Upgrade just " | /recipe-upgrade <recipe> |
| "The report site is stale/missing a week" | /recipe-report |
| "Tests are red because upstream changed" | /cc-ci-tests-update (fleet) or /recipe-upgrade <r> --with-tests |
| "A CI run failed and I don't know why" | /ci-test-review |
| "Update the CI server OS/deps" | /cc-ci-server-update |
| "Update this orchestrator's OS/deps" | /cc-ci-orchestrator-update |
| "Add to what we maintain" | /recipe-enroll <recipe> |
| "A host is unreachable" | hetzner-server-recovery |
| "Hack on / bootstrap a recipe in a sandbox" | /cctest-recipe-init, /cctest-recipe-deploy, /cctest-recipe-test |
| "New to recipe work, where do I start?" | /cctest-intro |
| "What needs my review?" | /cc-ci-status → its open-PR section lists CVE-urgent + ready-to-merge PRs |
Standing conventions (all skills follow these): PRs are opened for visibility and merged
directly once verified (invocation = authorization) — except recipe upgrade PRs, which stay
operator-merged; nixos-rebuild test before any switch; never weaken a test; single-writer
branches; serialize deploy-heavy work on the shared swarm.
If several things need doing, run /cc-ci-status first — its findings come pre-prioritized
with the skill to invoke for each.