/deploy — CI/CD Management

Bundled command: if kg is not found, run it as ${CLAUDE_PLUGIN_ROOT}/tools/kg and give subagents that full path. If that is missing too (Claude chat ships no plugin tools), skip the kg steps and search the code directly.

Create and manage CI/CD pipelines.

Detect Existing Pipeline

ls .github/workflows/ 2>/dev/null
ls .gitlab-ci.yml 2>/dev/null
ls .circleci/config.yml 2>/dev/null

Process

Creating a New Pipeline

Gather requirements via a single AskUserQuestion call (three questions in one questions array — not plain prose) so the user picks structured options instead of free-typing:

• CI provider — GitHub Actions · GitLab CI · CircleCI · Other
• Stages (multi-select) — lint · test · build · deploy · security scan
• Environments — staging · production · both

End your turn at the AskUserQuestion call. Wait for the answers before generating any pipeline template. If provider is "Other", follow up for the specific tool.

Once answered, present the one-shot plan — provider, stages, environments, and the exact file(s) to be written (e.g. .github/workflows/ci.yml) — and gate it with AskUserQuestion (not a bare sentence). Frame it "Pipeline plan ready — write it?" with options:

• Approve — write the workflow file(s) as planned
• Revise — adjust stages / environments (they describe the change)
• Change scope — different provider or file layout

End your turn at the AskUserQuestion call. Act on the selection; treat any free-form "looks good / approved / yes" as Approve. Write the workflow file only on Approve — this is the write gate; do not weaken it.

GitHub Actions Template

# .github/workflows/ci.yml
name: CI

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup runtime
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run lint
      - run: npm test
      - run: npm run build

  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Security scan
        # magician-scan is provided by the magician plugin (on PATH when the
        # plugin is enabled). Make it optional so the job degrades gracefully
        # in repos where the binary is not installed.
        run: command -v magician-scan >/dev/null 2>&1 && magician-scan . || echo "magician-scan not present, skipping"

GitLab CI Template

# .gitlab-ci.yml
stages: [lint, test, build, security]

lint:
  stage: lint
  script: [npm run lint]

test:
  stage: test
  script: [npm test]

build:
  stage: build
  script: [npm run build]
  artifacts:
    paths: [dist/]

security:
  stage: security
  # magician-scan is provided by the magician plugin (on PATH when the plugin
  # is enabled). Optional — degrades gracefully if the binary is not present.
  script:
    - command -v magician-scan >/dev/null 2>&1 && magician-scan . || echo "magician-scan not present, skipping"

Monitoring a Pipeline

Run gh run watch with the Bash tool's background option so it does not hold the turn; you are notified when it exits, and its exit status tells you whether the run passed.

# GitHub Actions
gh run list --limit 5
gh run view <run-id>
gh run watch <run-id> --exit-status   # Bash background option; non-zero exit = the run failed

For an unattended "until green" wait, pair with /goal, or schedule with /loop (self-paces when the interval is omitted).

Background CI watcher. Running /deploy also starts magician's ci-watch monitor for the session. Every 90 s it asks gh for the newest failed GitHub Actions run on the current branch; the first check only records a baseline, and each later new failure is reported as a single line with the run ID only (the number in the run's Actions URL). It prints nothing without gh, a git repository, an origin remote or a branch, and stops after about 3 hours or when the session ends. The watcher keeps its own baseline as its bookmark. A /loop or /goal you start on top of it follows lore/unattended.md: a bookmark of the last run ID, a "could not read" line for a failed gh call, and a live re-check before any push.

Scheduled maintenance. For a /loop that watches a pipeline or service metric, use the 1σ/2σ/3σ bands in references/control-bands.md: 1σ logs only, 2σ investigates read-only, 3σ opens a PR or a runbook. No band acts in production.

Fixing a Failed Pipeline (loop until green)

1. Read the failure: gh run view <id> --log-failed
2. Fix the underlying issue
3. Push the fix
4. Watch the new run: gh run watch <id> --exit-status with the Bash tool's background option — on failure, repeat from step 1 until the run is green.

Autonomy — approve the plan, then run

After the requirements answers (the three questions — provider, stages, environments — plus the one-shot create plan), execute the remaining phases autonomously: detecting existing pipelines, generating the template, and monitoring (gh run list/view/watch, --log-failed), plus kg query and read-only git need no confirmation question. Re-gate only on this skill's real side effects: edits to the workflow file, git add/commit/push, and PR create. Do not weaken the write gate above. Commands outside the pre-approved list above (git writes, gh pr create) still show Claude Code's normal permission prompt. Doctrine: lore/autonomy.md.

Tiered autonomy by environment

Act up to the production gate. Never act past it.

• Rehearse the rollback in staging before you prepare a production change. Record the rollback command and its result in the plan.
• A workflow job that targets production must keep a required human approval (environment: with protection rules on GitHub Actions, when: manual on GitLab CI). Never remove one.
• When you cannot tell which environment a job targets, treat it as production.

Obstacles

If this skill runs as a dispatched unit and hits something that blocks or degrades the work, do not wait for a human who is not there and do not silently ship a degraded result — return the Obstacles block from lore/obstacles.md (fields: STATUS, OBSTACLE, BLOCKER, SEVERITY, WORKAROUND, RECURRENCE, SCOPE, NEXT) to the caller alongside whatever you completed; interactively, say the same in prose.

Completion Signal

"Deploy pipeline configured. Monitor at: <CI URL>."