Automating Development Workflows with Claude Code

Claude Code workflow automation is not about letting an agent merge code while nobody is watching. The practical version is smaller and safer: let Claude Code summarize issues, prepare focused changes, review pull requests, run maintenance checks, and stop at the points where a human needs to decide.

This guide shows copy-paste examples that work with the gh, git, node, npm, and claude commands. The same pattern scales from a solo project to a team repository because it treats automation as a harness: a controlled set of inputs, allowed actions, logs, retries, rollback notes, and approval gates.

The Automation Boundary

Before writing scripts, decide what the agent may do and where it must stop.

Stage	Let Claude Code do	Keep human control over
Triage	Summarize issues, diffs, and failing logs	Priority and product decisions
Change	Small fixes, tests, docs updates	Scope changes and release decisions
Review	Bugs, security risks, missing tests	Which suggestions to accept
Operations	Scheduled checks, stale TODOs, dependency notes	Merge, deletion, release, billing impact

flowchart LR
  A["Issue / PR"] --> B["Small prompt"]
  B --> C["Claude Code"]
  C --> D["Diff and logs"]
  D --> E["Tests"]
  E --> F["Human approval"]
  F --> G["PR / release"]

For a wider pipeline view, pair this article with the Claude Code CI/CD setup guide and the Claude Code hooks guide.

Use Case 1: Turn an Issue into a Safe Work Branch

This script reads a GitHub issue, creates or reuses a deterministic branch, asks Claude Code for the smallest implementation, runs tests, and leaves the commit to you.

Save it as scripts/claude-issue-work.sh.

#!/usr/bin/env bash
set -euo pipefail

ISSUE_NUMBER="${1:-}"
if [ -z "$ISSUE_NUMBER" ]; then
  echo "Usage: ./scripts/claude-issue-work.sh <issue-number>"
  exit 1
fi

for command_name in git gh claude npm; do
  if ! command -v "$command_name" >/dev/null 2>&1; then
    echo "Missing command: $command_name"
    exit 1
  fi
done

: "${ANTHROPIC_API_KEY:?Set ANTHROPIC_API_KEY before running this script}"

mkdir -p .claude-logs
ISSUE_FILE=".claude-logs/issue-${ISSUE_NUMBER}.md"
LOG_FILE=".claude-logs/issue-${ISSUE_NUMBER}-$(date +%Y%m%d-%H%M%S).log"
BRANCH="claude/issue-${ISSUE_NUMBER}"

gh issue view "$ISSUE_NUMBER" --json title,body,labels --jq '
  "# " + .title + "\n\n" + (.body // "") + "\n\nLabels: " + ([.labels[].name] | join(", "))
' > "$ISSUE_FILE"

if git show-ref --verify --quiet "refs/heads/$BRANCH"; then
  git switch "$BRANCH"
else
  git switch -c "$BRANCH"
fi

PROMPT=$(cat <<PROMPT
You are the development assistant for this repository.
Read the issue below and make the smallest useful change.

Constraints:
- Inspect the related files before editing.
- Prefer existing architecture, naming, and test style.
- If requirements are unclear, leave a TODO or question instead of inventing a large design.
- Do not touch secrets, environment files, or unrelated articles.
- Leave the repository ready for npm test.
- Do not commit, push, create a PR, or merge.

Issue:
$(cat "$ISSUE_FILE")
PROMPT
)

claude -p "$PROMPT" \
  --max-turns 8 \
  --permission-mode acceptEdits \
  --output-format text 2>&1 | tee "$LOG_FILE"

npm test 2>&1 | tee -a "$LOG_FILE"
git diff --stat | tee -a "$LOG_FILE"

echo "Review the diff, then commit manually if it is correct."
echo "Log: $LOG_FILE"

The guardrails are simple but important. Missing credentials fail fast. The branch name is idempotent, so reruns return to the same branch instead of creating duplicates. Logs stay in .claude-logs, which makes next-day debugging much easier.

Use Case 2: Add a PR Review Gate in GitHub Actions

The official Claude Code GitHub Action can run on PR events. This workflow asks for review comments only; it does not allow edits, pushes, or merges.

Save it as .github/workflows/claude-review.yml.

name: Claude Review Gate

on:
  pull_request:
    types: [opened, synchronize, reopened]

permissions:
  contents: read
  pull-requests: write
  issues: write

concurrency:
  group: claude-review-${{ github.event.pull_request.number }}
  cancel-in-progress: true

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: |
            Review this pull request.
            Focus on bugs, security, missing tests, backward compatibility, and operational logs.
            Mark findings as high, medium, or low severity and make every fix suggestion concrete.
            Do not edit code, push, or merge.
          claude_args: |
            --max-turns 6
            --permission-mode plan

Keep permissions narrow. For review-only automation, contents: read and pull-requests: write are usually the core permissions. Add issues: write only if your workflow comments on issues too.

Check the current Claude Code CLI reference, Claude Code GitHub Actions docs, and GitHub Actions workflow syntax before copying old examples. Older beta snippets that use @beta or direct_prompt should be updated to the current @v1 and prompt shape.

Use Case 3: Run a Maintenance Report with Node.js

Daily or weekly maintenance does not have to modify files. A report that highlights stale tests, large diffs, TODOs, missing logs, or rollback risk is often enough.

Save this as scripts/claude-maintenance.mjs.

#!/usr/bin/env node
import { spawnSync } from "node:child_process";
import { existsSync, mkdirSync, rmSync, writeFileSync } from "node:fs";
import { join } from "node:path";

const logDir = ".claude-logs";
const lockFile = join(logDir, "maintenance.lock");
const stamp = new Date().toISOString().replace(/[:.]/g, "-");
const logFile = join(logDir, `maintenance-${stamp}.log`);

function fail(message) {
  console.error(message);
  process.exit(1);
}

function run(command, args, options = {}) {
  const result = spawnSync(command, args, {
    encoding: "utf8",
    shell: process.platform === "win32",
    ...options,
  });

  const output = `${result.stdout || ""}${result.stderr || ""}`;
  if (result.status !== 0) {
    writeFileSync(logFile, output);
    fail(`Command failed: ${command} ${args.join(" ")}. See ${logFile}`);
  }
  return output;
}

if (!process.env.ANTHROPIC_API_KEY) {
  fail("Set ANTHROPIC_API_KEY before running this script.");
}

mkdirSync(logDir, { recursive: true });
if (existsSync(lockFile)) {
  fail(`Another maintenance run is active: ${lockFile}`);
}

writeFileSync(lockFile, String(process.pid));

try {
  const status = run("git", ["status", "--short"]);
  const tests = run("npm", ["test", "--", "--runInBand"]);
  const prompt = [
    "You are the maintenance reviewer for this repository.",
    "Read the git status and test output, then summarize today's risks.",
    "Do not edit, delete, commit, or push anything.",
    "Group the report by credentials / idempotency / retry / rollback / logs / human approval.",
    "",
    "git status:",
    status || "(clean)",
    "",
    "test output:",
    tests.slice(-12000),
  ].join("\n");

  const review = run("claude", [
    "-p",
    prompt,
    "--max-turns",
    "5",
    "--permission-mode",
    "plan",
    "--output-format",
    "text",
  ]);

  writeFileSync(logFile, review);
  console.log(`Maintenance report written to ${logFile}`);
} finally {
  rmSync(lockFile, { force: true });
}

If your test runner is not Jest, replace npm test -- --runInBand with your normal test command. The script intentionally sends only the last 12000 characters of test output to avoid an oversized prompt that hides the useful failure line.

Use Case 4: Schedule It with Cron or Task Scheduler

Use cron for Linux or macOS. Use Windows Task Scheduler on Windows. GitHub Actions schedule also works, but local scheduling is often better when the task needs a local database, VPN, or internal credentials.

# Run at 08:15 on weekdays
15 8 * * 1-5 cd /path/to/repo && /usr/bin/node scripts/claude-maintenance.mjs >> .claude-logs/cron.log 2>&1

# Register a daily Windows task
schtasks /Create /TN "ClaudeMaintenance" /SC DAILY /ST 08:15 /F /TR "powershell -NoProfile -ExecutionPolicy Bypass -Command \"cd C:\path\to\repo; node scripts\claude-maintenance.mjs\""

Scheduled automation must be idempotent. That means running the same task twice should not create duplicate PRs, duplicate comments, or a second branch for the same issue. Use lock files, stable branch names, existing-PR checks, and log files.

Use Case 5: Make Human Approval Explicit

Short prompts are not automatically safer. A good workflow prompt says what is allowed, what is forbidden, and which decisions require a human.

claude -p "
Goal:
  Apply the review feedback on PR #123.

Allowed:
  - Edit related implementation and test files.
  - Run npm test.
  - Summarize failing logs.

Forbidden:
  - git push
  - gh pr merge
  - Showing .env or secrets
  - Unrelated refactors

Human approval required:
  - API response compatibility changes
  - Database migrations
  - Deleting existing tests

Final report:
  - Changed files
  - Tests run
  - Remaining risks
  - Rollback steps
" --max-turns 6 --permission-mode acceptEdits

For review structure, see the Claude Code review checklist and the verification receipt workflow.

Failure Modes to Design For

Failure mode	What happens	Practical fix
Prompt too long	Constraints get buried and runs become slower	Pass only relevant files and the tail of logs
Missing credentials	CI fails on ANTHROPIC_API_KEY or GH_TOKEN	Validate env vars at the start
No idempotency	Duplicate PRs, comments, or branches appear	Use stable names, locks, and existing-state checks
No logs	Nobody knows what the agent tried	Save .claude-logs or GitHub artifacts
Naive retry	Temporary failures become duplicate writes	Retry reads, then re-check state before writes
No rollback	One large commit is hard to revert	Keep PRs small and require rollback notes
No approval gate	The agent makes product or release decisions	Require human approval for compatibility, data, billing, deletion, and merge steps

For adjacent safety topics, read Claude Code security audit, Claude Code testing strategies, and Git workflow automation.

Monetization CTA

The natural conversion path for this topic is practical help, not hype. Solo developers can start with the free Claude Code cheatsheet. Teams that want repository-specific prompts, review gates, approval policy, and rollout training can use the Claude Code training and consultation page. If you want ready-to-use setup material, the Claude Code setup guide is the paid shortcut.

Keep ads and CTAs away from the middle of command sequences. For AdSense quality, this type of article should include working examples, real failure modes, official links, internal links, and a concrete result from trying the workflow.

Conclusion

Claude Code workflow automation becomes reliable when you design the stop points first. Start with issue triage and PR review. Then add small edits. Finally move to scheduled maintenance and CI gates with explicit human approval.

The most useful result from Masa’s hands-on test was not fully automated PR creation. It was repeatable issue logs and a fixed PR review prompt. Missing ANTHROPIC_API_KEY, oversized test output, and branch reruns each caused one failure, but env checks, log tailing, and deterministic branch names made the next run easy to diagnose.