Github Ci Init

GitHub CI Init Workflow

Scope

This skill adds optional, project-specific GitHub Actions CI workflows to a repository. It complements the furedea/template-minimal GitHub template, which already ships the baseline workflows (gha_lint.yml, dependency_review.yml, dependency_review_config.yml, renovate.json).

It does NOT own writing or editing the YAML contents of individual workflow files — that belongs to the gha-style skill (permissions minimization, action version pinning, script injection prevention, etc.).

When to apply vs skip

Not every project benefits from these optional workflows. Applying them to a throwaway repo creates maintenance noise (CodeQL alerts on every PR, release-please commits) that outweighs the payoff.

Apply when

• The project has a plausible long-term lifetime (weeks to years)
• PRs are expected (from others, or from yourself via feature branches)
• The project is public, or likely to become public

Skip when

• It's a throwaway experiment, tutorial follow-along, or one-off script
• The project lives in a single commit and won't be touched again
• It's a scratch space for exploring a library

When in doubt, skip. CI can always be added later by running this skill again on the existing repo — that is exactly the retrofit case it is designed for.

What templates already provide

These files are already in GitHub templates and should NOT be added by this skill:

• gha_lint.yml — actionlint + zizmor (in template-minimal and all derived templates)
• dependency_review.yml + dependency_review_config.yml — dependency vulnerability review (same)
• renovate.json — automated dependency updates (same)
• codeql.yml — CodeQL analysis (in language-specific templates: template-rust, template-python, template-typescript)

Steps

1. Confirm the project passes the "apply" criteria. If it does not, stop and explain why CI would be net-negative for this project.
2. Create .github/workflows/ in the project root if it does not already exist.
3. Copy the relevant workflow files from templates/ (in this skill's directory) into the project's .github/workflows/:

• release_please.yml — opens release PRs from Conventional Commits; ship when the project will have versioned releases. Replace release-type: simple with a repo-specific strategy (e.g. python, node, rust) if needed.
• claude.yml — responds to @claude mentions in issues, PRs, and review comments via Claude Code Action (OAuth). Requires the CLAUDE_CODE_OAUTH_TOKEN repository secret.
• claude_code_review.yml — runs automated Claude Code Review on every PR via the code-review plugin. Requires the same CLAUDE_CODE_OAUTH_TOKEN secret.
• artifact_attestation.yml — generates SLSA build provenance attestations on release via Sigstore. Ship when the project publishes binaries, packages, or container images. Replace the build steps and subject-path to match the project's actual build outputs.

1. Remind the user about the GitHub-side features (Push Protection / Secret Scanning / Rulesets). These live in repo or org settings, not in .github/workflows/, so this skill cannot install them.

Handoff to gha-style

After copying, any edit to the resulting .github/workflows/*.yml — changing triggers, tuning permissions:, adding a job, pinning an action version, fixing an actionlint warning, responding to a zizmor finding — belongs to the gha-style skill.

This split is deliberate:

• github-ci-init owns the "which files exist" decision. It is a one-shot, per-repo scaffolding action.
• gha-style owns the "how each file is written" decision. It is an ongoing code-review loop every time a workflow is touched.

Duplicating either side into the other would let the two drift. Keep them separate and chain them: scaffold with this skill, then edit with gha-style.

Anti-patterns

• Applying the full set to a throwaway experiment. CodeQL/release-please on a 1-commit repo is pure maintenance noise.
• Editing workflow YAML inside this skill's flow. Redirect to gha-style. Even "just tuning one permission" should go through that skill so the conventions stay consistent.
• Deploying Claude Code Action without the CLAUDE_CODE_OAUTH_TOKEN secret configured in the repository. The workflows will fail silently on every trigger.
• Re-adding workflows that templates already provide (ghalint, dependencyreview, renovate, codeql). These are maintained in the GitHub templates — duplicating them here causes drift.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: furedea
• Source: furedea/agent-harness
• License: MIT

Install and usage instructions live in the source repository linked above.