Menu
Use when configuring or optimising GitHub repositories for cost-effective, consistent operations — CI triggers, Actions billing, issue tracking, labelling, branch protection, or release workflow.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Bootstrap or harden a project's operating model for mixed human and AI delivery teams. Use when starting a repository, adopting an agent harness, defining authority and risk tiers, coordinating parallel agents safely, binding evidence and review to an exact candidate, or correcting fragmented rules that prevent coherent, consistent, complete delivery.
Architecture decisions, trade-off analysis, and ADR authoring. Trigger when a significant technical decision needs to be made, documented, and owned — not when an implementation detail needs a choice.
Decompose an epic into atomic parallelizable tasks and route each task to the right skill. Use this as a meta-router when you have more than one skill available and need to decide which applies. Trigger at the start of any multi-track epic or when the skill count in your harness exceeds ~12.
Check proposed stack, data flows, cloud choices, and delivery controls against declared enterprise policies, compliance frameworks, and security controls. Trigger at R2/R3 risk classification, before locking architecture decisions, or when the operating profile names a governance pointer.
Govern the SemVer release process — versioning discipline, tag-based GitHub releases, changelog hygiene, and the ADR that confirms the release strategy is agreed. Trigger when setting up a release process, before a first public release, or when release practice has become inconsistent. Owned by delivery-orchestrator.
Session-start orientation for this team harness. Load first, before any work. Explains the operating contract, when each skill triggers, and how installed companion plugins supply agent-craft capabilities while this harness supplies the team contract. Trigger at the start of every session and whenever unsure which skill applies.
| name | github-manager |
| description | Use when configuring or optimising GitHub repositories for cost-effective, consistent operations — CI triggers, Actions billing, issue tracking, labelling, branch protection, or release workflow. |
CI validates what cannot be cheaply verified locally. It is not a remote test runner for every commit.
This skill enforces disciplined, cost-aware GitHub operations. It turns GitHub from a free-for-all into a governed delivery surface: selective automation, traceable issues, consistent labels, and protected mainlines.
This skill governs the GitHub surfaces that enforce the harness contract at the repository level. It is not general DevOps housekeeping — each procedure below maps to a harness invariant:
Use release-readiness to gate a specific deployment. Use this skill to configure and
audit the repository surfaces that make those gates trustworthy.
cache: 'pnpm', cache: 'npm', pip, etc.).Closes #123 or Refs #123).Adopt a namespaced taxonomy and avoid one-off labels:
| Namespace | Examples | Purpose |
|---|---|---|
kind/ | kind/bug, kind/feature, kind/docs | Type of work |
area/ | area/ci, area/ui, area/security | Component or domain |
priority/ | priority/p0, priority/p1 | Triage urgency |
status/ | status/blocked, status/needs-review | Workflow state |
main.v*) trigger release builds and deployments, not manual uploads.| Excuse | Counter |
|---|---|
| "Run everything on every push to be safe" | Safety is selective gates, not redundant burn. Run full checks on PRs and tags. |
| "It's only a few CI minutes" | At 10× for macOS, "a few minutes" becomes hundreds of dollars per cycle. |
| "We'll clean up labels later" | Label debt compounds fast and breaks automation that depends on them. |
| "Force-push is fine, we're a small team" | Force-push on main destroys recovery options. Protect the branch. |
| "I'll build the release artifact locally" | Local builds are not reproducible or auditable. CI produces release artifacts. |