AnthropicClaude Certified Architect – Professional2026-107.2 Improve developer workflows using AI-assisted tooling
Separate CI analysis from repository mutations
Completed by the knowledge check
Learning objective
Integrate Claude into CI/CD for non-interactive review, test generation, and automation with controlled scope and side effects.
Core idea
An unattended Claude job is a repository actor with costs and side effects, not merely another static check. Choose separately what it may inspect, what it may generate, and what it may publish. Review findings, proposed tests, a pushed commit, and a deployment are different outputs with different owners.
Claude Code’s -p interface and the anthropics/claude-code-action integration support unattended work. The professional design problem is distributing authority across the workflow: a model investigates or proposes; executable consumers validate results; a separately authorized step performs consequential publication. Use the completion criteria in 7.2.3 for the final revision.
How it works
Define three job profiles
Give each automation a named owner, scoped input, accepted output, and permitted mutations. A team can use these profiles:
| Profile | Claude assignment | Permitted result |
|---|---|---|
| Review | Compare a selected diff with requirements and readable source | Findings for validation; no source edits |
| Test generation | Compare changed behavior with existing tests and fixtures | A proposed patch in a disposable checkout |
| Recurring automation | Inspect a specified commit range or issue set | A report, or an explicitly authorized repository update |
The profiles are application policy, not built-in action modes. They prevent a request to report uncovered behavior from silently becoming permission to edit tests, push a branch, or merge. For test generation, require a meaningful missing assertion rather than a quota of tests. For repeated review, supply prior findings and the selected revision so publishing can update existing allegations rather than create duplicates.
Match triggers to authorized actors
In anthropics/claude-code-action@v1, omitting prompt selects mention-driven behavior using trigger_phrase, whose default is @claude. Supplying prompt runs automation without waiting for a mention. The workflow’s on configuration still determines which events reach the action. For PR updates, explicitly include synchronize when a pushed revision needs another run.
On issue and pull request events, the action checks that the triggering user has write access. allowed_non_write_users creates an exception and requires the github_token input. Bot actors are rejected unless listed in allowed_bots; use a specific trusted list rather than a wildcard. Schedules skip the human write-access check but still undergo the bot-actor check. These controls govern who can start a run, not whether its input content is trustworthy.
Use allowed_bots to admit only intended automation actors; its default rejection of bots prevents feedback loops. Credential choice also controls follow-on verification: commits made with the default GITHUB_TOKEN, including when passed as github_token: ${{ secrets.GITHUB_TOKEN }}, do not trigger workflows. Claude GitHub App or custom App tokens let pushes trigger CI when its on configuration includes the resulting events. Choose the token and actor rules together so generated commits run the checks in 7.2.3 without retriggering generation indefinitely.
Bound tools and credentials independently
The action exposes prompt, settings, and claude_args. Put the assignment in prompt; supply Claude Code settings as JSON or a settings-file path through settings; pass CLI controls through claude_args. These are separate from GitHub workflow permissions and the credential’s repository authority.
Carry the unattended policy through claude_args, using --allowedTools, --tools, --disallowedTools, --permission-mode dontAsk, --permission-prompts none, and --max-turns as required by the assignment and supported CLI version. Define the actual tool set per profile: omit editing tools for reviewers; permit test-generator edits only in a disposable checkout and inspect its patch before publication. File ownership written in a prompt is not a filesystem boundary. Keep a workflow timeout separate from the turn budget, and record denied necessary operations or budget exhaustion as incomplete work rather than a clean review.
The action’s github_token selects a supplied GitHub credential; without it, the action authenticates as the Claude GitHub App. Do not assume that reducing GITHUB_TOKEN permissions reduces a separately issued App credential’s authority. The official App has a shared permission set across Claude features. Anthropic documents a custom App option for organizations that require only the action’s Contents, Issues, and Pull requests permissions.
Treat publication as a separate capability
Automation results appear in the workflow log by default. Posting requires an instruction and a posting tool. The documented review-plugin example combines --comment with --allowedTools "mcp__github_inline_comment__create_inline_comment" in claude_args; that argument also starts the inline-comment MCP server. If the job should only produce a report, leave that publication capability out.
The action can modify files and push commits when configured and authorized. In its default mention workflow, it commits changes to a branch and provides a PR-creation link; the user completes PR creation. Do not infer that a completed response means a PR was created, merged, or deployed. Give each intended side effect its own observable success condition.
Privileged events require particular care. Anthropic’s security guidance says pull_request_target and workflow_run execute with base-repository secrets; do not check out an untrusted head ref into the workspace root before the action. Restoring selected Claude configuration from the base branch does not make PR-authored package scripts safe: package.json, lockfiles, and executable tool configuration can remain supplied by the PR. Review-only access and test execution therefore have materially different trust requirements.
Key distinctions and trade-offs
Trigger permission versus content trust: A trusted maintainer can ask Claude to inspect hostile PR text. Actor checks do not make that text policy.
Tool grant versus repository authority: Claude needs both a usable tool path and credentials for a repository operation. Constrain both.
Generation versus publication: A proposed patch is reviewable without granting the producer authority to push, approve, or deploy it.
Separating these stages adds workflow maintenance and result handling. It also makes failures diagnosable: incomplete analysis, rejected output, and failed publication no longer collapse into one green job.
Architecture / decision scenario
A technology company wants a nightly test-gap report and generated regression patches for internal PRs. Its constraint is that production deployment credentials must never reach either model job. A proposed all-purpose action would inspect changes, edit tests, push them, and merge after a clean model review.
The platform architect rejects that authority bundle. The scheduled job uses an explicit prompt, bounded tools, and log output. The PR job includes synchronize, receives existing tests and fixtures, and proposes a patch in a disposable checkout. A deterministic step checks changed paths, and normal CI verifies the patch before a maintainer publishes it. Deployment remains in a separately authorized workflow.
A review-comment capability is enabled only for the review profile, with the documented posting tool. If that run reaches its turn cap, it reports incomplete work rather than publishing a clean review. The platform owner maintains triggers and grants; the repository maintainer owns acceptance and publication. This costs an additional handoff, but meets the company’s credential and side-effect constraints.
Common exam traps
- Assuming
promptgrants tools or automatically posts the answer. - Treating
--allowedToolsas exclusive availability or a prompt’s file list as enforcement. - Confusing workflow-token permissions with a separate App token’s authority.
- Running PR-controlled scripts with privileged-event secrets because Claude configuration was restored.
- Counting a generated patch as a pushed, approved, or deployed change.
What to remember
Design the actor, trigger, tool policy, credential, result, and side effects separately. Keep unattended failures explicit. Let Claude produce scoped analysis or proposals, and give publication only the authority the workflow actually requires.
Knowledge check
A pull-request workflow runs anthropics/claude-code-action@v1 with github_token: ${{ secrets.GITHUB_TOKEN }} and pushes generated regression tests to the PR branch. The repository’s CI runs on pull_request events including synchronize, and developers’ pushes trigger it, but the generated commits never do. The patch reaches review unverified. What should the team change?
pull_request_targetcontents: write in the workflow’s permissionsallowed_bots for the CI workflowGITHUB_TOKEN . Removing that input lets the action authenticate as the Claude GitHub App, or a custom App token can be supplied, and pushes made with an App token trigger CI as usual. Write permission already exists, since the push succeeds; allowed_bots governs who can start Claude, not whether CI runs; and pull_request_target gives PR code the base repository’s secrets.A team’s automated review workflow supplies a prompt and runs on pull_request with types: [opened]. Reviewers notice that the findings still describe the first revision after authors push fixes. What change gets each pushed revision reviewed?
prompt so the action waits for an @claude mentiontrigger_phrase to a value that matches each pushsynchronize to the workflow’s pull_request typesgithub_token so that pushes start the actionprompt , the action runs without waiting for a mention, but the workflow’s on configuration still decides which events reach it, and opened fires once. Adding synchronize runs the review on each pushed revision. A trigger phrase only matters in mention-driven mode, and a token choice does not add events.A nightly test-gap job should write its report to the workflow log only. The action authenticates as the Claude GitHub App, and the draft workflow’s claude_args, copied from the review profile, include --allowedTools "mcp__github_inline_comment__create_inline_comment". What should change?
claude_argsprompt instruction that tells Claude not to commentGITHUB_TOKEN permissions to read-onlyprompt so that the job cannot post on its ownGITHUB_TOKEN permissions, and without a prompt the job would wait for a mention instead of running nightly.A team wants Claude to review fork pull requests in a pull_request_target workflow, which holds the base repository’s deployment secrets. The proposal checks out the PR head into the workspace root, restores .claude/ from the base branch, and lets Claude run npm test. In this workflow, test subprocesses receive the deployment secrets. Which assessment is correct?
.claude/ keeps PR-authored code away from the secretspermissions keep PR-authored code away from the secretsBash(npm test *) keeps PR-authored code away from the secretspackage.json scripts still run with the deployment secretspackage.json , the lockfile and executable tool configuration, so npm test runs PR-authored scripts with those secrets. Narrowing Claude’s tools to that very command, or reducing the token’s permissions, leaves the scripts and the secrets in place.References
- Anthropic, Claude Code GitHub Actions
- Anthropic, Claude Code Action README
- Anthropic, Claude Code Action inputs
- Anthropic, Claude Code Action security
- Anthropic, Run Claude Code programmatically
- Anthropic, CLI reference