brewtools:deploy
GitHub Actions deployment — workflows, releases, GHCR, CI/CD with safety gates.
What this skill does
# GitHub Actions Deployment
> **Manage GitHub Actions** — workflows, releases, GHCR, CI/CD with safety gates and persistent config.
<instructions>
## Robustness Rules (MANDATORY — apply to ALL phases)
### Fail-Fast
| Rule | Applies to |
|------|-----------|
| Every Bash call MUST end with `&& echo "OK ..." \|\| echo "FAILED ..."` | ALL scripts |
| On `FAILED` — stop current phase, report error to user, DO NOT retry same command blindly | ALL phases |
| Max **2 retries** per failed operation. After 2nd failure — report and stop | ALL phases |
| If a script exits non-zero — read its stderr, diagnose, fix root cause, then retry ONCE | Scripts |
### Loop Protection
| Rule | Limit |
|------|-------|
| `gh auth` attempts — max **2**, then ask user | 2 auth |
| `gh` commands per phase — max **5** | 5 per phase |
| AskUserQuestion — max **3 questions per phase** | 3 per phase |
| update-agent mode — max **5 workflows** per run | 5 workflows |
### Timeouts
| Operation | Timeout | Action on timeout |
|-----------|---------|-------------------|
| `gh` CLI commands | 30s (`timeout 30 gh ...`) | Report "gh timed out", stop |
| `gh run watch` | 5min (`timeout 300 gh run watch ...`) | Report "Watch timed out", switch to polling |
| Entire skill invocation | Do not exceed **15 gh calls total** | Stop, report progress, suggest manual |
### Fallback Strategy
**If a script fails and cannot be fixed:**
1. Report the exact error to user: script name, exit code, stderr
2. Attempt the same operation manually (inline Bash) — scripts are helpers, not gatekeepers
3. If manual fallback also fails — report both attempts and ask user what to do
4. NEVER silently swallow errors or continue with stale/missing data
**Manual fallback examples:**
| Failed script | Manual alternative |
|---------------|--------------------|
| detect-mode.sh | Parse `$ARGUMENTS` yourself — keyword matching is simple |
| gh-env-check.sh | Run `gh auth status`, `gh repo view --json name`, `gh secret list` |
| workflow-discover.sh | Run `ls .github/workflows/`, `gh workflow list`, `gh run list -L 5` |
| deploy-local-ops.sh | Read/write CLAUDE.local.md directly with Read/Edit tools |
### Error Reporting (MANDATORY)
On ANY failure — before stopping or asking user — output:
```
SCRIPT_ERROR: <script-name>
EXIT_CODE: <code>
STDERR: <error message>
PHASE: <current phase>
ACTION: <what was attempted>
FALLBACK: <what will be tried next OR "asking user">
```
This is non-negotiable. Silent failures are bugs.
---
## Phase 0: Mode Detection (MANDATORY FIRST STEP)
**EXECUTE** using Bash tool:
```bash
bash "${CLAUDE_SKILL_DIR}/scripts/detect-mode.sh" "$ARGUMENTS"
```
Output format:
```
ARGS: [arguments received]
MODE: [detected mode]
```
**Use the MODE value and GOTO that mode section below.**
### Mode Reference
| Keyword in args | MODE |
|-----------------|------|
| setup, check, prerequisites, init | setup |
| create, new workflow, add workflow | create |
| release, bump, version, tag, publish | release |
| deploy, trigger, dispatch, run workflow | deploy |
| monitor, watch, status, check runs, logs | monitor |
| update agent, refresh, rescan | update-agent |
| (empty, no GitHub config) | setup |
| (empty, GitHub config exists) | monitor |
---
## Phase 1: Environment & Config Check
> Runs for ALL modes before branching.
**EXECUTE** using Bash tool:
```bash
bash "${CLAUDE_SKILL_DIR}/scripts/gh-env-check.sh" && echo "OK env-check" || echo "FAILED env-check"
```
> **STOP if FAILED** -- fix GitHub environment before continuing.
Parse output key=value pairs. Note gh CLI version, auth status, repo info, secrets count.
### Load Existing Config
**EXECUTE** using Bash tool:
```bash
bash "${CLAUDE_SKILL_DIR}/scripts/deploy-local-ops.sh" list 2>/dev/null || echo "NO_CONFIG"
```
Read CLAUDE.local.md if it exists — check for `## GitHub Config` and `## Workflows:` sections.
**Branching logic:**
| Condition | Action |
|-----------|--------|
| `NO_CONFIG` AND mode=`setup` | GOTO Phase 2: Setup |
| `NO_CONFIG` AND mode=`create`/`release`/`deploy` | GOTO Phase 2 (need config first) |
| Config exists AND mode=`setup` | Report existing config, ask if re-setup |
| Config exists AND mode=`create` | GOTO Phase 3: Create Workflow |
| Config exists AND mode=`release` | GOTO Phase 4: Release |
| Config exists AND mode=`deploy` | GOTO Phase 5: Deploy |
| Config exists AND mode=`monitor` | GOTO Phase 6: Monitor |
| mode=`update-agent` | GOTO Mode: update-agent |
---
## Phase 2: Setup
### Step 1: Verify gh Auth
**EXECUTE** using Bash tool:
```bash
gh auth status 2>&1 && echo "OK auth" || echo "FAILED auth"
```
If FAILED — instruct user: `gh auth login`
### Step 2: Detect Repo
**EXECUTE** using Bash tool:
```bash
gh repo view --json owner,name,url,defaultBranchRef,visibility 2>/dev/null && echo "OK repo" || echo "FAILED repo"
```
### Step 3: Check Secrets
**EXECUTE** using Bash tool:
```bash
gh secret list 2>/dev/null && echo "OK secrets" || echo "FAILED secrets"
```
### Step 4: Check SSH Integration
Check if CLAUDE.local.md has SSH server config (for deploy workflows):
**EXECUTE** using Bash tool:
```bash
grep -q "^## SSH Servers" CLAUDE.local.md 2>/dev/null && echo "SSH_SERVERS=exists" || echo "SSH_SERVERS=missing"
```
### Step 5: Discover Workflows
**EXECUTE** using Bash tool:
```bash
bash "${CLAUDE_SKILL_DIR}/scripts/workflow-discover.sh" && echo "OK discovery" || echo "FAILED discovery"
```
### Step 6: Persist Config
**EXECUTE** using Bash tool:
```bash
bash "${CLAUDE_SKILL_DIR}/scripts/deploy-local-ops.sh" add-github "OWNER" "REPO" "ghcr.io" && echo "OK add-github" || echo "FAILED add-github"
```
Replace OWNER and REPO with detected values from Step 2.
**EXECUTE** using Bash tool:
```bash
bash "${CLAUDE_SKILL_DIR}/scripts/deploy-local-ops.sh" add-workflows && echo "OK add-workflows" || echo "FAILED add-workflows"
```
### Step 7: Gitignore
**EXECUTE** using Bash tool:
```bash
grep -q "CLAUDE.local.md" .gitignore 2>/dev/null && echo "EXISTS" || (echo "CLAUDE.local.md" >> .gitignore && echo "ADDED")
```
### Step 8: Generate deploy-admin Agent
Read the agent template:
**EXECUTE** using Bash tool:
```bash
cat "${CLAUDE_SKILL_DIR}/templates/deploy-admin-agent.md.template"
```
Replace placeholders in template:
- `{{GITHUB_CONFIG}}` -- GitHub Config table from CLAUDE.local.md
- `{{WORKFLOW_INVENTORY}}` -- Workflows table from CLAUDE.local.md
- `{{SERVER_TARGETS}}` -- SSH Servers table from CLAUDE.local.md (if exists) or "No SSH servers configured"
- `{{SECRETS_LIST}}` -- secret names from `gh secret list`
- `{{LAST_UPDATED}}` -- current ISO timestamp
Write result to `.claude/agents/deploy-admin.md` in the project using Write tool.
---
## Phase 3: Create Workflow
### Step 1: Load Templates
Read `references/workflow-templates.md` from skill directory for workflow patterns.
### Step 2: Determine Type
Use AskUserQuestion:
```
header: "Workflow Type"
question: "What type of GitHub Actions workflow do you need?"
options:
- label: "Build + Push to GHCR"
description: "Build Docker image and push to GitHub Container Registry"
- label: "Deploy to VPS"
description: "Deploy via SSH to a remote server"
- label: "Release"
description: "Create GitHub Release from tag push"
- label: "Security Scan"
description: "Dependency/code scanning with SARIF"
- label: "Custom"
description: "Describe your workflow needs"
```
### Step 3: Generate YAML
Based on selected template and user input:
1. Generate workflow YAML with project-specific values
2. Write to `.github/workflows/<name>.yml`
3. Validate YAML structure
**EXECUTE** using Bash tool:
```bash
mkdir -p .github/workflows && echo "OK dir" || echo "FAILED dir"
```
Write workflow file using Write tool.
### Step 4: Update Config
**EXECUTE** using Bash tool:
```bash
bash "${CLAUDE_SKILL_DIR}/scripts/deploy-local-ops.sh" update-workflows && echo "OK update" || echo "FAILED update"
```
---
## Phase 4: Release (CRITICALRelated in Cloud & DevOps
appbuilder-action-scaffolder
IncludedCreate, implement, deploy, and debug Adobe Runtime actions with consistent layout, validation, and error handling. Use this skill whenever the user needs to add actions to an App Builder project, understand action structure (params, response format, web/raw actions), configure actions in the manifest, use App Builder SDKs (State, Files, Events, database), deploy and invoke actions via CLI, debug action issues, or implement patterns such as webhook receivers, custom event providers, journaling consumers, large payload redirects, action sequence pipelines, and Asset Compute workers. Also trigger when users mention serverless functions in Adobe context, action logging, IMS authentication for actions, or cron-style scheduled actions.
orchestrating-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. Use this skill when the user needs a multi-step Data Cloud pipeline, cross-phase troubleshooting, or data space and data kit management. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase sf data360 workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching phase-specific skill), the task is STDM/session tracing/parquet telemetry (use observing-agentforce), standard CRM SOQL (use querying-soql), or Apex implementation (use generating-apex).
github-project-automation
IncludedAutomate GitHub repository setup with CI/CD workflows, issue templates, Dependabot, and CodeQL security scanning. Includes 12 production-tested workflows and prevents 18 errors: YAML syntax, action pinning, and configuration. Use when: setting up GitHub Actions CI/CD, creating issue/PR templates, enabling Dependabot or CodeQL scanning, deploying to Cloudflare Workers, implementing matrix testing, or troubleshooting YAML indentation, action version pinning, secrets syntax, runner versions, or CodeQL configuration. Keywords: github actions, github workflow, ci/cd, issue templates, pull request templates, dependabot, codeql, security scanning, yaml syntax, github automation, repository setup, workflow templates, github actions matrix, secrets management, branch protection, codeowners, github projects, continuous integration, continuous deployment, workflow syntax error, action version pinning, runner version, github context, yaml indentation error
sf-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase `sf data360` workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching sf-datacloud-* skill), the task is STDM/session tracing/parquet telemetry (use sf-ai-agentforce-observability), standard CRM SOQL (use sf-soql), or Apex implementation (use sf-apex).
fabric-cli
IncludedUse this skill for Fabric.so CLI workflows with the `fabric` terminal command: diagnose/install/login, search or browse a Fabric library, save notes/links/files, create folders, ask the Fabric AI assistant, manage tasks/workspaces, generate shell completion, check subscription usage, produce JSON output, and use Fabric as persistent agent memory. Do not use for Microsoft Fabric/Azure/Power BI `fab`, Daniel Miessler's Fabric framework, Python Fabric SSH, Fabric.js, or textile/fashion fabric.
lark
IncludedLark/Feishu CLI skills: lark-cli operations for docs, markdown, sheets, base, calendar, im, mail, task, okr, drive, wiki, slides, whiteboard, apps, approval, attendance, contact, vc, minutes, event. Use when the user needs to operate Lark/Feishu resources via lark-cli, send messages, manage documents, spreadsheets, calendars, tasks, OKRs, deploy web pages, or any Feishu/Lark workspace operations.