/setup-github-actions

description: Set up GitHub Actions workflows for this repo
tools:
  - Read
  - Glob
  - Bash
  - Write
  - Edit
  - AskUserQuestion

Setup GitHub Actions

Analyze the project's existing `.github/workflows/` and generate correct, production-ready GitHub Actions workflows using `anthropics/claude-code-action`.

Principles

These govern every workflow generated. Apply them rather than copying templates.

Permission Model — Output-Driven

Grant only the permissions Claude needs to write to. Never over-permission.

| What Claude produces | Permission required | |---|---| | Pushes commits, modifies files | `contents: write` | | Posts PR comments, inline reviews, updates PR description | `pull-requests: write` | | Labels, closes, or comments on issues | `issues: write` | | Reads CI/test failure logs | `actions: read` | | OAuth token auth | `id-token: write` (always required) |

The interactive `@claude` workflow (`claude.yml`) primarily needs `contents: write` and `pull-requests: write`. It does NOT need `issues: write` unless it explicitly labels or comments on issues — it mostly runs in the background making code changes and commits.

For issue workflows that should trigger on issues from non-contributors, add `allowed_non_write_users: "*"` and pass `github_token: ${{ secrets.GITHUB_TOKEN }}` alongside the OAuth token.

Tool Scope — Capability-Driven

Scope `--allowedTools` to exactly the minimum tools needed. Never use broad wildcards unless the workflow legitimately needs broad access.

| Workflow type | Allowed tools | |---|---| | Interactive `@claude` (code changes + commits) | `Edit,Write,Read,Glob,Grep,Bash(git:*),Bash(gh pr:*),Bash(gh issue:*)` | | PR review (read + post comments only) | `Read,Glob,Grep,Bash(gh pr diff:*),Bash(gh pr view:*),Bash(gh pr comment:*),mcp__github_inline_comment__create_inline_comment` | | Issue triage (label + comment) | `mcp__github__get_issue,mcp__github__search_issues,mcp__github__list_issues,mcp__github__create_issue_comment,mcp__github__update_issue,Bash(gh issue view:*),Bash(gh issue edit:*),Bash(gh label:*)` | | Issue deduplication | `mcp__github__get_issue,mcp__github__search_issues,mcp__github__list_issues,mcp__github__create_issue_comment,mcp__github__update_issue,mcp__github__get_issue_comments` | | CI/test failure auto-fix | `Edit,Write,Read,Glob,Grep,Bash(git:*),Bash(gh:*)` | | Manual code analysis | `Read,Glob,Grep,Bash(gh:*)` |

Auth

Always use `claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}`. Do not add, change, or generate auth configuration — it is set up separately by `/install-github-app`.

File Naming — Canonical Names

Use these exact filenames to prevent duplicates across runs:

| Workflow | Filename | |---|---| | Interactive assistant | `claude.yml` | | PR code review | `claude-code-review.yml` | | Issue triage | `claude-issue-triage.yml` | | Issue deduplication | `claude-issue-dedup.yml` | | CI failure auto-fix | `claude-ci-fix.yml` | | Test failure analysis | `claude-test-analysis.yml` | | Manual code analysis | `claude-analysis.yml` |

If a file with the canonical name already exists, **edit it in place** — do not create a parallel file with a different name.

PR Review Prompt — Project-Customized

Never use a generic "review this PR" prompt. Before writing the review workflow YAML, scan the repository to understand its tech stack and conventions, then generate a prompt customized for this specific project.

**Scanning step** (execute before writing the review YAML):

1. Read config files: `package.json`, `pyproject.toml`, `Cargo.toml`, `go.mod`, `pom.xml`, `*.csproj`, or equivalent 2. Read `CLAUDE.md`, `CONTRIBUTING.md`, and linter/formatter configs (`.eslintrc*`, `.prettierrc*`, `rustfmt.toml`, `.golangci.yml`, etc.) 3. Identify the major artifact types in the codebase (e.g., "React components + Express handlers", "Python hooks + SKILL.md files", "Go handlers + protobuf definitions") 4. Note project-specific conventions, security requirements, or architectural constraints

**Prompt structure** — generate a 4-phase review prompt using what you discovered:

**Phase 1 — Context Discovery**: Instruct the reviewer to read config files to confirm the tech stack, read CLAUDE.md/CONTRIBUTING.md for project conventions, then run `gh pr diff` to get the full diff and categorize changed files by type (source, tests, config, docs, CI).

**Phase 2 — Change Comprehension**: Instruct the reviewer to summarize the PR's intent in one sentence, read surrounding code (not just the diff) to understand context, and identify existing patterns the codebase uses. Comprehension before critique is the single biggest lever for reducing false positives.

**Phase 3 — Deep Analysis**: Evaluate the diff across dimensions relevant to the detected stack. Select from this table — include dimensions that apply, skip those that don't:

| Dimension | When to include | Stack-specific examples | |---|---|---| | Correctness & logic | Always | Off-by-one errors, null handling, race conditions | | Security | Always — tailor to stack | SQL injection (DB), XSS (web), memory safety (C/Rust), path traversal (file I/O) | | Performance | Performance-sensitive code present | N+1 queries, unnecessary re-renders, hot-path allocations | | Error handling | Always | Uncaught exceptions, missing error propagation, silent failures | | API & interface design | Changes touch public APIs/types | Breaking changes, naming consistency, backward compatibility | | Testing | Project has tests | Coverage of new code paths, edge cases, test quality | | Documentation | Project has docs | README/API doc accuracy for changed features | | Maintainability | Always | Over-engineering, dead code, naming clarity, DRY violations |

Use the language and framework conventions discovered in Phase 1. If a linter or formatter is configured, explicitly instruct the reviewer to skip formatting and style nits — those are automated.

**Phase 4 — Output**: Instruc