DEV Community

Nex Tools
Nex Tools

Posted on • Originally published at nextools.hashnode.dev

Claude Code CI/CD Integration: How I Wired My AI Agent Directly Into My Deployment Pipeline

#claudeai #productivity #ai #programming

Most developers treat Claude Code as a coding assistant. You ask it to write a function, review a PR, fix a bug. Then you manually run the tests, check the deploy, and move on.

That's fine. But you're leaving a lot on the table.

What I want to show you is how to wire Claude Code directly into your deployment pipeline - so your AI agent isn't just helping you write code, it's actively participating in your build, test, and deploy process.

Here's how I built a CI/CD-integrated Claude Code setup for a live ecommerce and content publishing operation.

Why This Matters

Think about what happens after you write code with Claude Code:

  1. You run the tests manually
  2. You check if anything broke
  3. You deploy (or wait for your CI pipeline to deploy)
  4. You monitor for errors
  5. You fix what broke

At every step, you're the integration layer. You're the one carrying information from the pipeline back to Claude Code and from Claude Code back to the pipeline.

That's a lot of manual work. And it introduces delays - sometimes a deploy issue sits for hours because you weren't watching.

The goal is to close the loop: Claude Code should know what's happening in your pipeline, and your pipeline should know when Claude Code has made changes.

The Architecture

Before diving into implementation, here's the high-level design:

Code Change (Claude Code)
        ↓
Git Commit + Push (automated via Claude Code hooks)
        ↓
CI Pipeline Triggered (GitHub Actions / Cloudflare / Vercel)
        ↓
Build + Test Results → Logged to a file Claude Code can read
        ↓
Claude Code reads results, flags issues, suggests fixes
        ↓
Fix applied → cycle repeats
Enter fullscreen mode Exit fullscreen mode

The key insight: build results are just data. And Claude Code is great at reading and acting on data - if you put it in the right place.

Step 1: Hook Into Your Commit Workflow

Claude Code's hooks feature (covered in a previous article) is the entry point.

Here's a PostToolUse hook that runs after every file edit:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "bash C:/deploy/scripts/auto-stage.sh"
          }
        ]
      }
    ]
  }
}
Enter fullscreen mode Exit fullscreen mode

auto-stage.sh does three things:

  1. Runs your linter
  2. Stages changed files
  3. Writes lint results to deploy-status.md 
#!/bin/bash
cd /path/to/project

# Run linter
npm run lint 2>&1 > /tmp/lint-results.txt
LINT_EXIT=$?

# Stage files
git add -A

# Write status
echo "# Deploy Status - $(date)" > deploy-status.md
echo "## Lint: $([ $LINT_EXIT -eq 0 ] && echo PASS || echo FAIL)" >> deploy-status.md
cat /tmp/lint-results.txt >> deploy-status.md
Enter fullscreen mode Exit fullscreen mode

Now every time Claude Code edits a file, lint runs automatically and the results are written to a file Claude Code can read.

Looking for a practical example of this in action? The 11 free tools on mynextools.com - from the Angel Number Calculator to the Human Design Type Finder - were all deployed using this pipeline. Built and shipped without a traditional dev team.

Step 2: Connect Your CI Pipeline

Most CI systems (GitHub Actions, Cloudflare Pages, Vercel, Netlify) support webhooks and status badges. We want to pipe that status back somewhere Claude Code can read it.

Here's a GitHub Actions workflow that writes build results to a file in the repo:

name: Build and Deploy

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Build
        run: npm run build

      - name: Write Build Status
        if: always()
        run: |
          echo "build_status=${{ job.status }}" >> build-results.env
          echo "build_time=$(date -u +%Y-%m-%dT%H:%M:%SZ)" >> build-results.env
          echo "commit=${{ github.sha }}" >> build-results.env
          git config user.email "ci@example.com"
          git config user.name "CI Bot"
          git add build-results.env
          git commit -m "ci: update build status" --allow-empty
          git push
Enter fullscreen mode Exit fullscreen mode

Now build-results.env in your repo always has the latest build status. Claude Code can read it.

Step 3: Give Claude Code a "Deploy Monitor" Skill

Now we need Claude Code to actually do something with this information.

Create a file at ~/.claude/commands/deploy-monitor.md:

# Deploy Monitor

You check the current deployment status and report issues.

## Steps:
1. Read `build-results.env` - get latest build status
2. Read `deploy-status.md` - get latest lint results  
3. Read the last 20 lines of `deploy-log.md` if it exists
4. Report:
   - Current build status (pass/fail)
   - Last deploy time
   - Any lint errors
   - Any warnings
5. If build FAILED:
   - Read the error details
   - Suggest the most likely fix
   - Ask: "Want me to attempt the fix?"

## Rules:
- Never deploy automatically without confirmation
- Always show the specific error, not just "build failed"
- If you can't determine the issue from logs, say so clearly
Enter fullscreen mode Exit fullscreen mode

Now you can run /deploy-monitor at any point to get a current status report without manually checking your CI dashboard.

Step 4: Close the Loop With Pre-Deploy Checks

Before Claude Code makes a significant code change, you want it to run a pre-flight check. Here's how to set that up with a Stop hook:

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "bash C:/deploy/scripts/pre-stop-check.sh"
          }
        ]
      }
    ]
  }
}
Enter fullscreen mode Exit fullscreen mode

pre-stop-check.sh:

#!/bin/bash
# Check if there are uncommitted changes that could affect production
CHANGED=$(git diff --name-only HEAD)

if [ -n "$CHANGED" ]; then
  echo "WARNING: Uncommitted changes in:"
  echo "$CHANGED"
  echo "Consider committing before ending session."
fi

# Check build status
BUILD_STATUS=$(grep "build_status=" build-results.env | cut -d= -f2)
if [ "$BUILD_STATUS" = "failure" ]; then
  echo "ALERT: Last build FAILED. Check before deploying."
fi
Enter fullscreen mode Exit fullscreen mode

Now when you're about to end a Claude Code session, it automatically checks whether there's anything that needs attention before you stop.

Step 5: Automated Rollback Detection

This one is more advanced, but worth building. The idea: Claude Code monitors your production error rate and suggests rollbacks when things go wrong.

You need two pieces:

A. Error monitoring script (runs every 5 minutes via scheduled task):

// check-errors.js
const fs = require('fs');

async function checkErrors() {
  // Replace with your actual monitoring API (Sentry, Datadog, etc.)
  // For simple setups, parse your server logs
  const errorCount = await getRecentErrorCount();
  const baseline = getBaseline();

  const status = {
    timestamp: new Date().toISOString(),
    errorCount,
    baseline,
    elevated: errorCount > baseline * 2,
    critical: errorCount > baseline * 10
  };

  fs.writeFileSync('error-monitor.json', JSON.stringify(status, null, 2));

  if (status.critical) {
    // Append to escalation file for Claude Code to read
    fs.appendFileSync('escalation-log.md', 
      `\n## CRITICAL ERROR SPIKE - ${status.timestamp}\nErrors: ${errorCount} (baseline: ${baseline})\n`
    );
  }
}
Enter fullscreen mode Exit fullscreen mode

B. Add error monitoring to the deploy monitor skill:

## Step 2.5 (add after reading deploy-status.md):
- Read `error-monitor.json`
- If `elevated: true` - warn user and ask if they want to investigate
- If `critical: true` - immediately show details and suggest rollback steps
Enter fullscreen mode Exit fullscreen mode

Now Claude Code has a continuous feedback loop with your production environment.

This is the kind of infrastructure that makes solo operation possible. I run the content site at mynextools.com, the ecommerce store, and this blog series - all with a single person and this kind of automated pipeline. If you're curious about the end result, explore the Breathing Exercise Timer or Daily Affirmation Generator built with this workflow.

A Real Example: My Cloudflare Pages Setup

My content site (mynextools.com) runs on Cloudflare Pages. Here's the actual integration I use:

The repo: GitHub nextoolshub333-web/nex-tools

Deploy trigger: Push to main branch

Build command: npm run build

Build output: dist/

The loop:

  1. Claude Code runs /deploy-new-tool skill when publishing a new calculator or page
  2. Skill writes the new files, updates sitemap.xml, runs the pre-deploy check
  3. Git commit and push happen automatically (via a Stop hook)
  4. Cloudflare Pages detects the push, rebuilds the site (usually 2-3 minutes)
  5. Next Claude Code session: /deploy-monitor checks build status and confirms new page is live
  6. If build failed: error shown in Claude Code, fix applied in same session

The entire cycle from "add a new tool" to "live on production" takes about 10 minutes, most of which is Cloudflare Pages building. My active involvement: running two slash commands.

Handling Failed Deploys

This is where the integration really pays off. When a deploy fails in a traditional workflow, you:

  1. Get an email from your CI system
  2. Open the CI dashboard
  3. Read the logs
  4. Switch back to your editor
  5. Look at the code
  6. Fix it
  7. Re-run

With Claude Code integration, the workflow is:

  1. Claude Code sees the failure (via build-results.env)
  2. Reads the error log
  3. Identifies the likely cause
  4. Presents a fix option
  5. You approve
  6. Fixed, committed, re-deployed

The cognitive load drops dramatically. You're not context-switching between dashboard and editor - you're just reviewing Claude Code's analysis and clicking approve.

FAQ

Q: Does this work with any CI system?
Yes, with minor modifications. The key is getting your CI system to write build status to a file that Claude Code can read. GitHub Actions, Cloudflare Pages, Vercel, Netlify, CircleCI, Jenkins - they all support this pattern. The specific implementation varies, but the concept is the same.

Q: Is it safe to have Claude Code interact with production systems?
With appropriate guards, yes. The key is to never allow Claude Code to trigger production deploys automatically. Always require human approval for deploy actions. Claude Code's role is monitoring, analysis, and code fixes - not unilateral deployment.

Q: What if my project is too simple for this?
If you're working on a personal project with no CI/CD, the most valuable piece here is still the pre-deploy check (Step 4) and the deploy monitor skill (Step 3). Even a simple git status check and lint runner adds value.

Q: How do I handle secrets in this setup?
Never write secrets to files that Claude Code reads. For API keys, environment variables, or credentials - keep them in your system environment or a secrets manager. The status files (build-results.env, deploy-status.md) should only contain non-sensitive operational data.

Q: What about testing - can Claude Code run my test suite?
Yes. Add a test run to your PostToolUse hook (alongside the linter), and write test results to a test-results.md file. The deploy monitor skill can then include test pass/fail in its status report. For long-running test suites, you might want a separate "test runner" skill that runs tests on demand rather than on every file save.

The Bigger Picture

What I've described here is the beginning of a larger pattern: treating your infrastructure as data that Claude Code can read and act on.

Once you have build status, error rates, and deployment state flowing into files, you can extend this to anything:

  • Traffic spikes (write to traffic-monitor.json)
  • Revenue anomalies (write to revenue-alerts.json)
  • Customer service escalations (write to cs-escalation-log.md)
  • Inventory alerts (write to inventory-status.json)

Your AI agent isn't just coding anymore. It's operating your business.

That's the real promise of Claude Code integration - not faster code, but closed feedback loops that let you run more with less.

This is part of an ongoing series on using Claude Code to run a real business. Previous posts covered team workflows, memory files, worktrees, and sub-agents.

See live examples of tools built with this pipeline at mynextools.com.

Top comments (0)