write-github-actionslisted

# Writing GitHub Actions CI is written across two surfaces. The shared building blocks are **composite actions** in `a-novel-kit/workflows`, each at `<group>/<name>/action.yaml` under `build-actions`, `generic-actions`, `github-pages-actions`, `go-actions`, `node-actions`, or `publish-actions`. Every repo's `.github/workflows/*.yaml` then calls them, pinned to a release tag. Read the neighbours before writing either — the patterns below are already in every file. **Scope.** This skill owns authoring: workflow files, action manifests, and the repo CI config that turns a job into a required check. `monitor-ci` owns watching a run and diagnosing a failure. `coordinate-landing` owns the cross-repo landing saga and merge-queue semantics. `manage-versions` owns releasing the workflows repo and re-pinning consumers. Point at them; do not restate them. --- ## Choosing a surface A **composite action** packages a step sequence that runs inside someone else's job. It cannot declare `permissions`, cannot fan out across jobs, and has no early return — a guard that must stop the work sets an output and every later step carries an `if:` on it (`generic-actions/derive-status` threads a `halted` output that way). A **reusable workflow** (`.github/workflows/<name>-run.yaml`, triggered by `workflow_call`) packages whole jobs with their own `permissions` and `secrets:` block. `merge-gate-run.yaml` is one: each governed repo ships a thin caller so the engine lives in one place. Inside a reu