How to Fully Automate Claude Code: The Ultimate Guide to Autonomous AI Development

01.The Anatomy of a Fully Autonomous Pipeline

Fully automating Claude Code is not about writing a single clever prompt. It is about constructing a system of interlocking components where each stage feeds the next and every transition is guarded by a verification step that cannot be bypassed by the AI's optimism ^[1]. The distinction matters: a prompt can be ignored or misinterpreted, but a hook that blocks completion until tests pass is deterministic. The AI either satisfies the gate or it loops until it does.

The architecture draws from principles that Anthropic themselves have articulated in their best practices documentation ^[1]: give Claude Code explicit rules, use hooks for enforcement, and keep your project context in CLAUDE.md so that instructions survive across sessions and compaction events. What this guide adds is the full integration layer: connecting Jira for work intake, SonarQube for security scanning, Chrome DevTools for frontend verification, and a set of hooks that tie the entire pipeline together into a self-correcting loop ^[3].

Think of it as a factory floor for code. Raw material (a Jira ticket) enters at one end. It passes through multiple stations (implementation, testing, simplification, security scanning, visual verification). At each station, a quality inspector (a hook or MCP tool) checks the output. If the output fails inspection, it gets sent back for rework. Only when every inspector has signed off does the finished product (a Pull Request) leave the factory ^[9].

Pipeline Stages

The key insight is that each gate is enforced by a hook or MCP tool call, not by Claude's good intentions. Claude cannot decide to skip the security scan because it feels confident. The SonarQube MCP server either returns a passing Quality Gate or it does not. This determinism is what makes the pipeline production-grade rather than a clever demo.

02.Phase 1: PRD to Jira via MCP

The pipeline begins with work intake. Rather than manually creating Jira tickets, you feed Claude a PRD (Product Requirements Document) and let the Atlassian Rovo MCP (Model Context Protocol) server handle ticket creation ^[2]. The MCP server gives Claude full CRUD access to your Jira instance, including creating issues, reading ticket details, updating statuses, and transitioning tickets through your workflow.

Setting up the Atlassian MCP server requires adding it to your Claude Code configuration. The configuration lives in your .claude/settings.json file and points to the Atlassian MCP Docker container ^[2]:

{
  "mcpServers": {
    "atlassian": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-e", "JIRA_URL=https://your-org.atlassian.net",
        "-e", "JIRA_EMAIL=your-email@company.com",
        "-e", "JIRA_API_TOKEN=your-api-token",
        "ghcr.io/anthropics/claude-code-atlassian-mcp:latest"
      ]
    }
  }
}

Once the MCP server is running, you can feed Claude a PRD and ask it to decompose the work into tickets. The prompt should be explicit about the structure you want. Here is an example that produces well-formed tickets with acceptance criteria ^[3]:

Read @prd.md and create Jira tickets in project MYAPP.
For each feature:
  - Create an Epic with a clear title
  - Break it into Stories with acceptance criteria
  - Each Story must have:
    - A "Definition of Done" checklist
    - Estimated story points (1, 2, 3, 5, or 8)
    - Labels: "ai-generated", "sprint-backlog"
  - Order Stories by dependency (implement foundations first)

The output of this phase is a backlog of well-structured Jira tickets, each with clear acceptance criteria that can be translated into automated tests. This is the raw material for the rest of the pipeline. The better the acceptance criteria, the more reliably the autonomous implementation phase will succeed.

03.Phase 2: CLAUDE.md and Auto Mode

CLAUDE.md is the AI's rulebook. It is a markdown file that Claude Code reads at the start of every session and re-reads after every context compaction event. Anything you put in CLAUDE.md becomes a persistent instruction that shapes Claude's behaviour across the entire project lifecycle ^[1]. This is where you encode your team's conventions, architecture decisions, and quality standards.

A production CLAUDE.md for an autonomous pipeline should cover branch naming, commit format, quality gates, and architecture rules. Here is an example that demonstrates each category:

# Project Rules

## Branch Naming
- Feature branches: feat/MYAPP-{ticket-number}-{short-description}
- Bug fixes: fix/MYAPP-{ticket-number}-{short-description}
- Always create a new branch from main before starting work

## Commit Format
- Use Conventional Commits: feat:, fix:, refactor:, test:, docs:
- Include the Jira ticket number: feat(MYAPP-42): add user auth endpoint
- Keep the first line under 72 characters

## Quality Gates (Non-Negotiable)
- ALL tests must pass before marking work complete
- Run: npm test -- --coverage
- Minimum coverage: 80% on new code
- No lint errors: npm run lint must exit 0
- No TypeScript errors: npx tsc --noEmit must exit 0

## Architecture Rules
- Use the repository pattern for data access
- All API endpoints must have input validation with Zod
- Error responses follow RFC 7807 (Problem Details)
- No direct database queries in route handlers
- Environment variables accessed only through config.ts

The power of CLAUDE.md is that these rules are injected into every session automatically. You do not need to remind Claude about your commit format or branch naming convention. It reads CLAUDE.md, internalises the rules, and follows them. When compaction occurs (the context window fills up and Claude summarises the conversation to free space), CLAUDE.md is re-read, ensuring rules survive even long sessions ^[13].

Auto Mode: Safe Autonomous Execution

To run Claude Code autonomously, you need to address the permissions problem. By default, Claude asks for confirmation before writing files, running commands, or making commits. In a fully automated pipeline, there is nobody to click "approve." The --auto flag solves this with a clever approach: it uses a secondary model (Sonnet) as a classifier that evaluates each proposed action before execution ^[5].

Auto Mode approves routine development actions (writing files, running test suites, making git commits) while blocking potentially dangerous actions (accessing credentials, modifying infrastructure configuration, running destructive commands). This is fundamentally different from --dangerously-skip-permissions, which bypasses all safety checks entirely. Auto Mode retains the safety layer while eliminating the human bottleneck ^[5].

# Start Claude Code in Auto Mode for autonomous execution
claude --auto

# Or with a specific prompt for headless operation
claude --auto -p "Read Jira ticket MYAPP-42 and implement it following CLAUDE.md rules"

The combination of CLAUDE.md (persistent rules) and Auto Mode (safe autonomous execution) forms the foundation for everything that follows. CLAUDE.md tells Claude what to do; Auto Mode lets it do so without human approval at every step. The hooks we cover in the next section ensure it does so correctly.

04.Phase 3: Claude Code Hooks

Hooks are the enforcement mechanism of the entire pipeline. They are shell commands, HTTP endpoints, or LLM prompts that execute automatically at specific points in Claude Code's lifecycle ^[6]. Unlike CLAUDE.md rules (which Claude can theoretically ignore), hooks are deterministic: they run outside Claude's decision-making process and can block, modify, or redirect Claude's behaviour programmatically.

There are ten hook events in the Claude Code lifecycle. Understanding when each fires and what it can do is essential for building a robust autonomous pipeline ^{[6] [7]}:

Hook Configuration Structure

Hooks are configured in .claude/settings.json under the hooks key. Each hook event maps to an array of hook definitions. Here is the general structure ^[6]:

{
  "hooks": {
    "Stop": [
      {
        "type": "command",
        "command": "bash .claude/hooks/enforce-tests.sh",
        "matcher": "",
        "blocking": true
      }
    ],
    "PreToolUse": [
      {
        "type": "command",
        "command": "bash .claude/hooks/block-dangerous.sh",
        "matcher": "Bash",
        "blocking": true
      }
    ]
  }
}

Three Hook Types

Claude Code supports three hook types, each suited to different use cases. Command hooks run a shell command and use the exit code and stdout to determine the result. Prompt hooks send a text prompt to a lightweight model for classification. Agent hooks spawn a full Claude subagent that can reason about the situation and produce a structured decision ^{[6] [7]}.

Command hooks are the most common because they are deterministic and fast. The hook receives context as JSON on stdin and must return a JSON result on stdout. Here is what the input looks like for a Stop hook:

// Stop hook input (received on stdin)
{
  "session_id": "abc123",
  "transcript_summary": "Implemented user authentication endpoint...",
  "stop_reason": "end_turn"
}

And here is a blocking response that forces Claude to continue working:

// Stop hook output (returned on stdout)
{
  "decision": "block",
  "reason": "3 tests failed. Fix the failing tests before completing."
}

When the hook returns "decision": "block", Claude does not stop. Instead, it receives the reason as a new message and continues working to address the issue. This creates a self-correcting loop: Claude implements, the hook checks, Claude fixes, the hook re-checks, until the gate passes or a maximum iteration count is exceeded ^[9].

05.Phase 4: Autonomous Ticket Execution

With Jira integration, CLAUDE.md rules, Auto Mode, and hooks in place, you can now wire them together for autonomous ticket execution. The SessionStart hook is the entry point: it fires when Claude begins a session and can inject the current sprint context so Claude knows exactly which ticket to work on ^[3].

{
  "hooks": {
    "SessionStart": [
      {
        "type": "command",
        "command": "bash .claude/hooks/load-sprint-context.sh",
        "matcher": "startup",
        "blocking": false
      }
    ]
  }
}

The load-sprint-context.sh script reads a sprint-context.md file that you maintain (or that a previous session generated). This file contains the current sprint goal, the active ticket, and any relevant context that Claude needs to pick up work immediately:

# sprint-context.md

## Current Sprint: Sprint 14 (1-15 April 2026)
## Sprint Goal: Complete user authentication module

## Active Ticket: MYAPP-42
- Title: Implement JWT authentication middleware
- Status: In Progress
- Branch: feat/MYAPP-42-jwt-auth
- Acceptance Criteria:
  1. POST /api/auth/login returns JWT token for valid credentials
  2. Middleware rejects requests with expired or invalid tokens
  3. Refresh token rotation implemented
  4. Rate limiting: max 5 failed attempts per minute per IP

## Completed This Sprint:
- MYAPP-40: Database schema for users table
- MYAPP-41: User registration endpoint

## Dependencies:
- MYAPP-40 must be complete before starting (DONE)
- Uses bcrypt for password hashing (already in package.json)

Subagents for Parallel Implementation

For larger tickets or epics with multiple independent stories, Claude can spawn subagents to work in parallel. Each subagent operates in its own context, working on a separate branch, and reports back to the main agent when complete. This is particularly effective for epics where stories have minimal interdependencies ^[9].

The main agent acts as an orchestrator: it reads the Jira epic, identifies which stories can be parallelised, spawns a subagent for each, monitors their progress, and merges the results. The SubagentStop hook (covered in Phase 6) fires when each subagent completes, allowing the pipeline to trigger code simplification automatically on the subagent's output.

Git Worktrees: Isolated Parallel Development

The biggest risk of running subagents in parallel is file conflicts. If two subagents edit the same file simultaneously, one will overwrite the other's changes. Git worktrees solve this problem entirely by giving each subagent its own isolated copy of the repository.

A worktree is a lightweight, separate checkout of the same Git repository. Each worktree has its own working directory and its own branch, but they all share the same .git history. When you spawn a subagent with isolation: "worktree", Claude Code automatically:

In practice, the orchestration prompt looks like this:

"For each independent Jira story in this epic, spawn a subagent
with isolation: 'worktree'. Each subagent should:
  1. Create a branch named feature/PROJ-{ticket}/{description}
  2. Implement the ticket requirements
  3. Run the full test suite
  4. Commit with the correct message format

After all subagents complete, merge each branch into the
main feature branch and resolve any conflicts."

06.Phase 5: Stop Hook and Test Runner

The Stop hook is the most important hook in the autonomous pipeline. It fires every time Claude attempts to finish responding and has the power to block that completion, forcing Claude back into a work loop ^[6]. By attaching a test runner to the Stop hook, you create a system where Claude literally cannot mark a ticket as done until every test passes.

{
  "hooks": {
    "Stop": [
      {
        "type": "command",
        "command": "bash .claude/hooks/enforce-tests.sh",
        "matcher": "",
        "blocking": true
      }
    ]
  }
}

The enforce-tests.sh script runs the test suite and returns a blocking decision if any tests fail ^{[7] [9]}:

#!/bin/bash
# .claude/hooks/enforce-tests.sh

# Run the test suite and capture output
TEST_OUTPUT=$(npm test 2>&1)
TEST_EXIT=$?

# Run linter
LINT_OUTPUT=$(npm run lint 2>&1)
LINT_EXIT=$?

# Run type checker
TSC_OUTPUT=$(npx tsc --noEmit 2>&1)
TSC_EXIT=$?

# If everything passes, allow Claude to stop
if [ $TEST_EXIT -eq 0 ] && [ $LINT_EXIT -eq 0 ] && [ $TSC_EXIT -eq 0 ]; then
  echo '{"decision": "allow"}'
  exit 0
fi

# Build a failure message
FAILURES=""
if [ $TEST_EXIT -ne 0 ]; then
  FAILURES="$FAILURES\nTest failures:\n$TEST_OUTPUT"
fi
if [ $LINT_EXIT -ne 0 ]; then
  FAILURES="$FAILURES\nLint errors:\n$LINT_OUTPUT"
fi
if [ $TSC_EXIT -ne 0 ]; then
  FAILURES="$FAILURES\nTypeScript errors:\n$TSC_OUTPUT"
fi

# Block completion and send failures back to Claude
echo "{\"decision\": \"block\", \"reason\": \"Quality gate failed. Fix these issues:\n$FAILURES\"}"
exit 0

PreToolUse Hook: Dangerous Command Prevention

While the Stop hook enforces quality on output, the PreToolUse hook prevents dangerous actions on input. This hook fires before Claude executes any tool (file writes, bash commands, git operations) and can block the action entirely ^[6]. For an autonomous pipeline, you want to prevent commands that could damage your environment:

#!/bin/bash
# .claude/hooks/block-dangerous.sh

# Read the tool input from stdin
INPUT=$(cat)

# Extract the command being run
COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command // empty')

# Block dangerous patterns
if echo "$COMMAND" | grep -qE '(rm -rf /|DROP TABLE|force push|--force|main.*delete)'; then
  echo '{"decision": "block", "reason": "Blocked: this command matches a dangerous pattern."}'
  exit 0
fi

# Block access to sensitive files
if echo "$COMMAND" | grep -qE '(.env|credentials|secrets|private.key)'; then
  echo '{"decision": "block", "reason": "Blocked: access to sensitive files is not permitted."}'
  exit 0
fi

# Allow everything else
echo '{"decision": "allow"}'
exit 0

Together, the Stop hook (enforcing quality on completion) and the PreToolUse hook (preventing dangerous actions) create a safety corridor. Claude can work autonomously within this corridor, writing code, running tests, and iterating on failures, but it cannot escape the boundaries you have defined.

07.Phase 6: Code Simplification

Once code passes the test suite and lint checks, the next pipeline stage is simplification. Anthropic's official code-simplifier plugin runs on Opus and focuses on recently modified code. It preserves functionality while enhancing clarity ^[12]. This is not a cosmetic step. Simpler code consumes fewer tokens in subsequent sessions, which means Claude can hold more context and make better decisions downstream.

Installing the code-simplifier is straightforward:

# The code-simplifier is a built-in plugin
# Enable it in your Claude Code settings or run:
/simplify

Five Principles of Simplification

The code-simplifier operates according to five principles ^[12]:

To trigger simplification automatically after subagent work, use the SubagentStop hook:

{
  "hooks": {
    "SubagentStop": [
      {
        "type": "prompt",
        "prompt": "Review the code changes made by the subagent. Run /simplify on all modified files. Ensure tests still pass after simplification.",
        "matcher": "",
        "blocking": true
      }
    ]
  }
}

The practical impact of this step is significant. Simplified code can reduce token consumption in subsequent sessions by 20 to 30 percent ^[12]. Over an entire sprint of autonomous development, this compounding reduction means Claude can process more complex tasks without hitting context limits.

08.Phase 7: SonarQube Security Scanning

Security scanning is a critical gate in any production pipeline. The SonarQube MCP server creates a closed-loop workflow where Claude writes code, scans it for vulnerabilities, reads the results, fixes any issues, and re-scans until the Quality Gate passes ^[8]. This is not a one-shot scan. It is an iterative process that mirrors how a human security reviewer would work: find an issue, understand it, fix it, verify the fix.

SonarQube MCP Setup

{
  "mcpServers": {
    "sonarqube": {
      "command": "npx",
      "args": [
        "-y",
        "@anthropic/sonarqube-mcp-server"
      ],
      "env": {
        "SONARQUBE_URL": "http://localhost:9000",
        "SONARQUBE_TOKEN": "your-sonarqube-token",
        "SONARQUBE_ORGANIZATION": "your-org"
      }
    }
  }
}

You also need a sonar-project.properties file in your project root:

# sonar-project.properties
sonar.projectKey=myapp
sonar.projectName=My Application
sonar.sources=src
sonar.tests=src/__tests__
sonar.javascript.lcov.reportPaths=coverage/lcov.info
sonar.exclusions=**/node_modules/**,**/dist/**
sonar.qualitygate.wait=true

CLAUDE.md Quality Gate Instructions

Add these instructions to your CLAUDE.md to direct Claude through the SonarQube workflow ^[8]:

## Security Scanning (Non-Negotiable)
After all tests pass, run the SonarQube scan:
1. Run: npx sonar-scanner
2. Use MCP tool: sonarqube_check_quality_gate
3. If the gate FAILS:
   a. Use MCP tool: sonarqube_get_issues to list violations
   b. Fix each violation in the source code
   c. Re-run: npx sonar-scanner
   d. Re-check the quality gate
4. Repeat until the gate passes
5. Maximum 5 scan iterations (prevent infinite loops)

The Autonomous Fix Loop

The SonarQube integration creates a seven-step autonomous fix loop ^[8]:

## Loop Limits
- SonarQube scan: max 5 iterations
- If the gate still fails after 5 attempts, commit what you have,
  add a TODO comment on each unresolved violation, and flag the
  ticket for human review in Jira.

09.Phase 8: Frontend Verification with Chrome DevTools

Tests verify logic. Linters verify syntax. But neither verifies what the user actually sees. The Chrome DevTools MCP server bridges this gap by giving Claude direct access to a running browser, allowing it to inspect rendered pages, check console errors, analyse network requests, and take screenshots for visual verification ^{[10] [11]}.

Chrome DevTools MCP Tools

Installation

# Install Chrome DevTools MCP
npx @anthropic/chrome-devtools-mcp@latest

CLAUDE.md Verification Workflow

Add a visual verification workflow to your CLAUDE.md that Claude follows after passing all other quality gates ^[10]:

## Frontend Verification (after tests pass)
1. Start the dev server: npm run dev
2. Wait for the server to be ready
3. Use Chrome DevTools MCP to:
   a. Navigate to the affected pages
   b. Check for console errors (zero tolerance)
   c. Verify no failed network requests
   d. Take a screenshot and describe what you see
   e. Check accessibility tree for missing labels
4. If any issues found, fix them and re-verify
5. Stop the dev server when done

Practical Example: Debugging a Form Submission

Consider a scenario where Claude has implemented a user registration form. Tests pass (the API endpoint works, validation logic is correct), but the form does not actually work in the browser because a CSRF (Cross-Site Request Forgery) token is missing from the request headers. Here is how Chrome DevTools catches what tests miss:

Claude navigates to the registration page using the Page tools. It fills in the form fields using the evaluate tool to set input values. It clicks the submit button. The Network tools reveal a 403 response on the POST request. Claude reads the response body and finds a "CSRF token missing" error. It traces the issue back to the form component, adds the CSRF token to the request headers, rebuilds, re-navigates, re-submits, and this time sees a 201 response. The Console tools confirm zero errors. The form works ^[11].

This kind of integration-level bug is invisible to unit tests. Chrome DevTools MCP makes it visible to Claude, closing a gap that previously required human verification.

10.Phase 9: Session-Per-Ticket with the Agent SDK

Long autonomous sessions inevitably hit context compaction. When the context window fills up, Claude summarises the conversation to free space, and that summarisation is lossy. It can drop project conventions, active ticket details, and pipeline state ^[13]. You can mitigate this with PreCompact and PostCompact hooks, but the better architectural decision is to avoid the problem entirely: give every Jira ticket its own fresh Claude Code session.

The Claude Agent SDK (@anthropic-ai/claude-code) makes this possible by giving you programmatic control over Claude Code sessions from TypeScript or Node.js. Instead of one marathon session that accumulates context and eventually compacts, your orchestrator spawns a clean session per ticket. Each session starts fresh with CLAUDE.md fully loaded, zero accumulated drift, and a focused scope.

Installing the Agent SDK

The Agent SDK is a TypeScript/JavaScript package that wraps Claude Code's CLI into a programmatic interface. Install it as a dependency in your orchestrator project:

npm install @anthropic-ai/claude-code

The Orchestrator Script

The orchestrator is a Node.js script that sits above Claude Code and manages the pipeline. It queries Jira for the sprint backlog, then processes each ticket in a fresh session. Here is a production-ready example:

import { claude } from "@anthropic-ai/claude-code";

interface JiraTicket {
  key: string;
  summary: string;
  acceptanceCriteria: string;
}

async function processTicket(ticket: JiraTicket): Promise<void> {
  console.log(`Processing ${ticket.key}: ${ticket.summary}`);

  const result = await claude({
    prompt: `
      You are working on Jira ticket ${ticket.key}: ${ticket.summary}.

      Acceptance criteria:
      ${ticket.acceptanceCriteria}

      Instructions:
      1. Create branch feature/${ticket.key}/${ticket.summary.toLowerCase().replace(/\s+/g, "-")}
      2. Implement the requirements
      3. Run all quality gates (tests, lint, SonarQube, Chrome DevTools)
      4. Create a PR with a description referencing ${ticket.key}
    `,
    options: {
      maxTurns: 200,
      allowedTools: ["Bash", "Read", "Write", "Edit", "Glob", "Grep"],
    },
  });

  console.log(`Completed ${ticket.key}: ${result.exitCode === 0 ? "SUCCESS" : "FAILED"}`);
}

async function runPipeline(tickets: JiraTicket[]): Promise<void> {
  for (const ticket of tickets) {
    try {
      await processTicket(ticket);
    } catch (error) {
      console.error(`Failed on ${ticket.key}:`, error);
      // Continue to next ticket rather than stopping the pipeline
    }
  }
}

Each call to claude() spawns a completely fresh session. CLAUDE.md is loaded from scratch. The hooks defined in .claude/settings.json fire normally. There is zero context bleed between tickets. If ticket PROJ-42 fails spectacularly and burns through its entire context window, ticket PROJ-43 starts with a clean slate.

Parallel Ticket Processing

For tickets with no interdependencies, you can process them in parallel. Combined with git worktrees (covered in Phase 4), this means multiple tickets are being implemented simultaneously, each in its own session and its own isolated checkout:

async function runParallelPipeline(tickets: JiraTicket[]): Promise<void> {
  const concurrency = 3; // Run 3 tickets at a time

  for (let i = 0; i < tickets.length; i += concurrency) {
    const batch = tickets.slice(i, i + concurrency);
    await Promise.allSettled(
      batch.map((ticket) => processTicket(ticket))
    );
  }
}

Quality Gates as Separate Sessions

The Agent SDK also lets you run quality gates as their own sessions. If the implementation session creates a PR but you want an independent review pass, you can spawn a second session focused purely on verification:

async function reviewTicket(branch: string, ticketKey: string) {
  return claude({
    prompt: `
      Review the code on branch ${branch} for ticket ${ticketKey}.
      1. Run the full test suite
      2. Run SonarQube scan and check the Quality Gate
      3. Use Chrome DevTools to verify all UI changes
      4. If any issues found, fix them and push
      5. If the PR description is incomplete, update it
    `,
    options: {
      maxTurns: 100,
      allowedTools: ["Bash", "Read", "Write", "Edit", "Glob", "Grep"],
    },
  });
}

This pattern gives you defence in depth: the implementation session writes the code with hooks enforcing quality gates, and a separate review session verifies the result with fresh eyes and a full context window. The review session has no memory of the implementation decisions, so it evaluates the code on its own merits rather than confirming the implementation agent's assumptions.

11.Phase 10: Automated PR Creation

The final phase of the pipeline is delivery. Once all quality gates have passed (tests, lint, TypeScript, code simplification, SonarQube, Chrome DevTools), Claude creates a Pull Request with comprehensive documentation ^[3]. The PR is not just a code diff. It includes a summary of what was done, which Jira ticket it addresses, the test results, and the SonarQube scan outcome.

The Six-Step Delivery Process

The Jira integration is what closes the loop. The ticket that entered the pipeline as a backlog item now sits in "In Review" with a linked Pull Request, ready for a human reviewer to approve. The entire journey, from ticket to PR, happened without human intervention ^[3].

You can add instructions to CLAUDE.md that define the PR template Claude should use, ensuring consistent documentation across all autonomously created Pull Requests. Include sections for a summary, the Jira ticket link, test results, SonarQube status, and a list of modified files with brief descriptions of the changes.

12.Common Failure Modes

No autonomous system is perfect. Understanding the most common failure modes helps you build resilience into your pipeline before problems occur ^{[4] [9]}.

13.Complete Configuration Reference

Here is a production-ready .claude/settings.json that combines all the hooks and MCP servers described in this guide. You can use this as a starting template and customise it for your project ^{[6] [7]}:

{
  "mcpServers": {
    "atlassian": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-e", "JIRA_URL=https://your-org.atlassian.net",
        "-e", "JIRA_EMAIL=your-email@company.com",
        "-e", "JIRA_API_TOKEN",
        "ghcr.io/anthropics/claude-code-atlassian-mcp:latest"
      ]
    },
    "sonarqube": {
      "command": "npx",
      "args": ["-y", "@anthropic/sonarqube-mcp-server"],
      "env": {
        "SONARQUBE_URL": "http://localhost:9000",
        "SONARQUBE_TOKEN": "your-sonarqube-token"
      }
    }
  },
  "hooks": {
    "SessionStart": [
      {
        "type": "command",
        "command": "cat .claude/sprint-context.md 2>/dev/null || echo 'No sprint context found.'",
        "matcher": "startup",
        "blocking": false
      }
    ],
    "PostToolUse": [
      {
        "type": "command",
        "command": "npx prettier --write $CLAUDE_FILE_PATH 2>/dev/null || true",
        "matcher": "Edit|Write",
        "blocking": false
      }
    ],
    "PreToolUse": [
      {
        "type": "command",
        "command": "bash .claude/hooks/block-dangerous.sh",
        "matcher": "Bash",
        "blocking": true
      }
    ],
    "Stop": [
      {
        "type": "command",
        "command": "bash .claude/hooks/enforce-tests.sh",
        "matcher": "",
        "blocking": true
      }
    ],
    "SubagentStop": [
      {
        "type": "prompt",
        "prompt": "Run /simplify on all files modified by the subagent. Verify tests still pass.",
        "matcher": "",
        "blocking": true
      }
    ],
    "Notification": [
      {
        "type": "command",
        "command": "bash .claude/hooks/notify-slack.sh",
        "matcher": "",
        "blocking": false
      }
    ]
  }
}

This configuration gives you the full autonomous pipeline: sprint context injection on startup, automatic formatting after edits, dangerous command blocking, test enforcement on completion, code simplification after subagent work, and Slack notifications for monitoring. Pair this with an Agent SDK orchestrator script (covered in Phase 9) that spawns a fresh session per Jira ticket, and you have a system that processes an entire sprint backlog without human intervention. Customise the paths, matchers, and MCP server credentials for your specific environment.

Conclusion

The pipeline described in this guide is not theoretical. Teams are running variations of this architecture today, shipping features overnight while developers sleep ^{[4] [9]}. The technology has matured to the point where the limiting factor is no longer the AI's coding ability. It is the quality of the orchestration around it.

Building an autonomous development pipeline is itself an exercise in systems thinking. You are not writing code; you are designing a system of constraints, feedback loops, and safety boundaries within which an AI agent operates. The hooks are your quality inspectors. CLAUDE.md is your operations manual. MCP servers are your supply chain. And the result, when assembled correctly, is a factory that turns Jira tickets into Pull Requests while you focus on the work that requires human judgment: architecture decisions, product strategy, and the creative problems that machines have not yet learned to solve.

14.Frequently Asked Questions

15.References