Autonomous Build-Test-Ship Loop

Pillar: autonomous-build-loop | Date: April 2026
Scope: CC 2026 automation primitives: PostToolUse hooks for format/lint/test, CronCreate for scheduled agents, /loop self-pacing, --print headless mode, Task with isolation:worktree, EnterWorktree, plan mode. Tool comparison for autonomous agents: Aider auto-commit, Cursor Composer, Devin headless, Sweep PR-from-issue, Goose loops, Codex CLI, Cline/RooCode. Continuous quality patterns in agent loops: mutation testing (Mutmut, Stryker), property-based testing (Hypothesis, fast-check), security scanning (Semgrep, Snyk), perf regression watchers. Real public configs.
Sources: 29 gathered, consolidated, synthesized.

Table of Contents

1. CC 2026 Hook System: PostToolUse, PreToolUse, Stop, SessionStart
2. Scheduled Execution: CronCreate, /loop, Self-Pacing
3. Headless Mode: --print / -p / --bare
4. Worktree Isolation: Task tool, EnterWorktree, Parallel Agents
5. Autonomous Agent Tool Comparison
6. Mutation Testing: Mutmut, Stryker, PIT
7. Property-Based Testing: Hypothesis, fast-check
8. Security Scanning: Semgrep, Snyk
9. Integrated Loop Architecture
10. Production Patterns and Real Configurations

Section 1: CC 2026 Hook System — PostToolUse, PreToolUse, Stop, SessionStart

Claude Code hooks are shell commands (or HTTP calls, MCP tool calls, prompt evaluations, or subagent invocations) triggered at specific session lifecycle points, enforcing code standards deterministically without relying on model memory.^[11] "Hooks shift responsibility from the model to the runtime."^[11] Multiple hooks matching the same event all execute — PostToolUse hooks run in parallel; Stop hooks run sequentially.^[10] Hooks run synchronously in the agent loop, meaning slow hooks add latency to every matched tool call.^[10][19]

Key finding: The distinction between PostToolUse and Stop hooks determines autonomous loop behavior. PostToolUse fires after every tool call — correct for per-file lint/format; too expensive for full test suites. Stop fires once per response — ideal for test suites, commit staging, and mutation scoring. Conflating the two is the most common autonomous-loop performance mistake.^[11]

Hook Lifecycle Events

^[1][10][19]

Five Hook Types

^[19]

Exit Code Semantics

^[1] PostToolUse decision: "block" does NOT prevent tool execution (tool already ran); it instructs Claude to fix the flagged issue before its next action.^[10]

Hook Configuration Locations (Precedence Order)

^[1][11] Hooks merge additively across all files — a user-level stop hook fires alongside a project-level stop hook.

Matcher Pattern Rules

^[19]

PostToolUse JSON Input Schema

Every hook receives a JSON payload on stdin. PostToolUse includes:^[1][10]

{
  "session_id": "abc123",
  "transcript_path": "/Users/.../.claude/projects/.../transcript.jsonl",
  "cwd": "/Users/...",
  "permission_mode": "default",
  "hook_event_name": "PostToolUse",
  "tool_name": "Write",
  "tool_input": { "file_path": "/path/to/file.txt", "content": "file content" },
  "tool_response": { "filePath": "/path/to/file.txt", "success": true },
  "tool_use_id": "toolu_01ABC123...",
  "duration_ms": 12
}

Key Hook Fields

^[1]

Critical Anti-Pattern: The Infinite Stop Loop

Stop hooks that exit code 2 trigger a new Claude response. Without a guard, failing tests → remediation pass → Stop fires again → infinite token consumption. The mandatory guard:^[11]

ALREADY_LOOPING=$(echo "$INPUT" | jq -r '.stop_hook_active // false')
if [[ "$ALREADY_LOOPING" == "true" ]]; then exit 0; fi

The stop_hook_active field is injected automatically when a Stop hook is the cause of the current response, giving hooks a reliable re-entrancy check.^[11]

Common Pitfalls

^[11]

Real-world impact: A team with a 40-second TypeScript test suite across 12 monorepo packages eliminated manual cleanup passes using Stop hooks, recovering several hours of developer time weekly.^[11]

Section 2: Scheduled Execution — CronCreate, /loop, Self-Pacing

Claude Code v2.1.72+ supports three scheduling mechanisms: Cloud Routines (Anthropic-hosted, no local machine required), Desktop Scheduled Tasks (machine-local cron), and the in-session /loop command.^[2][20] All three use 5-field cron expressions internally but differ on persistence, local file access, and minimum interval.

Scheduling Options Comparison

^[2][20]

/loop Command: Four Invocation Modes

^[2] Supported interval units: s, m, h, d. Non-standard intervals (e.g., 7m, 90m) round to the nearest valid step; Claude reports the chosen interval.^[2]

Dynamic Self-Pacing

When no interval is specified, Claude selects delay dynamically after each iteration — shorter while a build is finishing or a PR has activity, longer when nothing is pending. It may use the Monitor tool for event-driven triggering instead of polling.^[2] On Bedrock, Vertex AI, and Microsoft Foundry, no-interval loops fall back to a fixed 10-minute schedule.^[2]

Key finding: Dynamic self-pacing reduces unnecessary turns in quiet periods without requiring the user to guess a polling interval. The 7-day automatic expiry bounds forgotten runaway loops — a session that stalls recovers naturally rather than burning tokens indefinitely.^[2]

Built-in Maintenance Prompt (Bare /loop)

Running /loop with no arguments activates a built-in protocol that executes in order:^[2][20]

1. Continue any unfinished work from the conversation
2. Tend to the current branch's PR: review comments, failed CI, merge conflicts
3. Run cleanup passes (bug hunts, simplification) when nothing else pending

Irreversible actions (pushing, deleting) proceed only when continuing already-authorized work. Irreversible new initiatives require human initiation.^[2]

loop.md Customization

Edits take effect on the next iteration. Maximum size: 25,000 bytes. Disable scheduling entirely: CLAUDE_CODE_DISABLE_CRON=1.^[2][20]

Underlying Tools: CronCreate / CronList / CronDelete

Maximum 50 scheduled tasks per session.^[2]

Execution Model and Jitter

• Scheduler checks every second; enqueues at low priority
• Tasks fire between turns, not while Claude is mid-response
• If Claude is busy when a task fires, prompt waits until the current turn ends
• All times use local timezone (not UTC)
• Jitter: Recurring tasks fire up to 10% late, capped at 15 minutes. One-shot top/bottom-of-hour tasks fire up to 90 seconds early. Offset is derived from task ID (deterministic).^[2]

CronCreate Expression Reference

Extended syntax (L, W, ?, name aliases like MON/JAN) not supported.^[2]

Section 3: Headless Mode — --print / -p / --bare

The -p / --print flag runs Claude non-interactively, outputs to stdout, and exits. Previously called "headless mode"; the umbrella term is now "Agent SDK CLI."^[9][12] The --bare flag skips auto-discovery of hooks, skills, plugins, MCP servers, auto memory, and CLAUDE.md — ensuring reproducible behavior in CI. Anthropic has signaled --bare will become the default for -p in a future release.^[9]

Output Formats

^[9][12][28]

Permission Modes

^[9][12][28]

--bare Context Loading Flags

^[9] Authentication in --bare mode must come from ANTHROPIC_API_KEY (OAuth and keychain are skipped).^[9]

Multi-Turn Session Continuation

# First request
claude -p "Review this codebase for performance issues"

# Continue the most recent conversation
claude -p "Now focus on the database queries" --continue
claude -p "Generate a summary of all issues found" --continue

# Capture session ID for precise resume
session_id=$(claude -p "Start a review" --output-format json | jq -r '.session_id')
claude -p "Continue that review" --resume "$session_id"

^[9][12]

Retry Event Handling (stream-json)

When an API request fails with a retryable error, a system/api_retry event is emitted containing:^[9][12]

Multi-Agent Output Chaining Pattern

# Agent A analyzes → Agent B fixes
claude -p "Analyze failing tests and output JSON findings" --output-format json \
  | jq '.findings' \
  | claude -p "Fix the failing tests based on these findings" --stdin

^[28]

Cron Integration Requirements

When integrating claude -p into system cron:^[28]

• Use absolute paths (cron lacks shell profile access)
• Explicitly source env vars containing API keys
• Redirect output to log files for audit trails
• Test commands manually before scheduling

Key finding: Interactive-mode skills (e.g., /commit) are unavailable in -p mode. For CI/CD pipelines, use --bare with explicit tool allowlists and describe the task directly rather than referencing slash commands.^[9]

Section 4: Worktree Isolation — Task Tool, EnterWorktree, Parallel Agents

Without isolation, concurrent agents writing to the same repository produce uncommitted change collisions — Agent A's edits to config.py become mixed with Agent B's edits, making clean rollbacks impossible.^[28] Git worktrees solve this by giving each agent its own working directory with an independent branch, while sharing the same object store.

Task Tool with isolation: "worktree"

Agent frontmatter supports:^[28]

isolation: worktree  # each invocation gets its own git copy
maxTurns: 50         # caps autonomous execution depth

Each subagent gets its own context window, its own tool set, and its own git worktree with no shared file state. The worktree is automatically cleaned up if the agent makes no changes; otherwise the path and branch are returned to the caller.^[28]

Worktree Architecture (MindStudio Pattern, 2026)

^[28] File-based state in .tasks/ and .worktrees/index.json provides durability across crashes. Conversation memory remains volatile — worktree state does not.

Worktree Lifecycle Operations

^[28]

Parallel Agent Pattern (Production 2026)

# Spawn parallel feature agents
claude -p "Refactor authentication module" -w auth-refactor &
claude -p "Build payment API endpoints" -w payment-api &
claude -p "Fix all TypeScript type errors" -w ts-fixes &

# Wait for all to complete
wait

# Each produces a separate, mergeable PR
gh pr list

"One agent refactoring authentication while another builds the payment API, both producing separate, mergeable PRs by morning."^[28]

Key finding: EnterWorktree (mid-session tool) migrates the current CLI into a git worktree when hooks block main-tree operations, eliminating the need to restart a session for branch isolation. Task with isolation: "worktree" handles isolation for subagents; EnterWorktree handles it for the parent session itself.

Internal Agentic Behavior Loop

Claude Code's internal execution cycle within a worktree:^[28]

1. Observe — Available context (file tree, git history, test results)
2. Reason — Form plan spanning multiple file edits and shell commands
3. Act — Invoke tools
4. Verify — Check for errors or test failures
5. Iterate — Loop if needed

Section 5: Autonomous Agent Tool Comparison

5.1 Aider: Scripting and Autonomous Loop

Aider supports non-interactive operation via --message / --yes flags. Git integration is on by default: auto-commits each edit set with Conventional Commits format using a weak model, prepending "(aider)" to author/committer names. Pre-existing uncommitted changes are committed first (user/AI separation).^[3][13]

Key Automation Flags

^[3][13][21]

Production Autonomous Loop Patterns (2026)

1. Run with --no-auto-commits when the prompt handles commits (avoids conflict)
2. Use --yes for fully unattended operation
3. Each iteration runs with a fresh instance to prevent context window bloat
4. Memory persists through git history and progress files (progress.txt, prd.json)
5. Use --timeout as a safety net for unexpected interactive prompts^[21]

Aider limitations: No built-in loop/cron mechanism (must wrap in external shell/cron). No native retry logic on LLM failures. Python API may break between releases.^[21]

5.2 Devin (Cognition AI): Fully Autonomous Cloud Agent

Devin operates in a sandboxed cloud environment with a code editor, terminal, web browser, and planning tools. Users describe tasks; Devin executes without constant oversight and submits PRs when complete. Cost: $500/month — break-even requires saving 12-20 developer hours monthly at $75/hour.^[4]

Performance Data: 5 Real-World Codebases

^[4]

18-Month Production Improvements (Cognition Review, 2025)

^[22]

Documented Weaknesses

• Last 30% Problem: Frequently delivers 70% with core logic working but missing edge cases, error handling, UI polish, integration^[4]
• Architectural judgment failures (superficial organization without improving testability)^[4]
• Rabbit hole problem (compounds issues instead of reconsidering approach)^[4]
• Security blindness (does not reliably identify SQL injection, XSS risks)^[4]
• No long-term memory across sessions^[4]
• Does not surface uncertainty or flag dangerous actions^[4]

Data conflict: raw_4.md states a real-world fail rate of approximately 85% on tasks outside SWE-bench conditions; raw_22.md shows a 67% PR merge rate (implying 33% fail rate). Discrepancy likely reflects different task difficulty distributions and measurement methodologies.^[4][22]

5.3 Goose (Block/AAIF): Open-Source Local Agent

Goose is a Rust-based autonomous agent under the Agentic AI Foundation (AAIF) at the Linux Foundation (formerly block/goose). Apache 2.0 license. 29,400+ GitHub stars, 368 contributors, 2,600+ forks.^[5][14][24]

Goose Architecture (Three Layers)

1. Central agent loop — plan-execute-evaluate cycle runs until complete or unresolvable blocker
2. Provider abstraction layer — 25+ LLM providers (Anthropic, OpenAI, Google, Mistral, xAI Grok, AWS Bedrock, GCP Vertex, Azure, Databricks, Ollama, Docker Model Runner, Ramalama)
3. Extension system — built on MCP; 3,000+ available MCP servers^[24]

"At its core, goose is very much about pushing autonomy, so we let the agent loop run as far as it can, so if it stumbles, if it hits obstacles, it'll back up and it'll try another approach."^[14]

Recipes: Portable YAML Workflow Units

Recipes support composable sub-recipes for multi-stage pipelines. Real-world reported: 45-minute status prep reduced to under 5 minutes using a recipe combining GitHub, Linear, and Notion extensions.^[5][24]

Local/Privacy-First Operation

^[5][24]

5.4 OpenAI Codex CLI: Agent Loop Architecture

Codex CLI sends HTTP requests to OpenAI's Responses API in a continuous cycle: user input → API request → model generates output or requests tool calls → Codex executes tools locally → resubmits expanded context → loops until model stops emitting tool calls.^[17]

Prompt caching: Cache hits occur when the new prompt contains an exact prefix match with the previous inference call, enabling linear-time sampling despite growing context sizes. Critical for long-horizon coding tasks.^[17]

Approval Modes

^[17]

Model timeline: GPT-5.2-Codex (December 2025) described as "the moment that people began to believe that using autonomous coding agents could be reliable." GPT-5.3-Codex and GPT-5.4 added in 2026.^[17]

5.5 Cursor Composer 2: IDE-Native Autonomous Agent

Cursor Composer 2 executes multi-file coding tasks autonomously across entire codebases. Shifts from isolated function generation to complete feature implementation. As of 2026, 50%+ of Fortune 500 companies use Cursor; SOC 2 Type II, GDPR, HIPAA compliant.^[29]

Three-Phase Execution Model

^[29] Real-time RL training: Cursor deploys improved model checkpoints as often as every 5 hours using real user interaction data.^[29]

Five Production Patterns (Cursor Composer 2)

1. Spec-first: Provide detailed task specifications before execution (reduces hallucination significantly)
2. Sandbox-Review-Merge (mandatory for production): Always use feature branches; review diff before merging; run tests + typecheck before PR
3. Context management: Use .cursorignore and @file references; don't flood context with irrelevant code
4. Verification loops (non-negotiable): tsc --noEmit + eslint + tests + build + semgrep after every Composer session
5. Open-source alternative: MiroThinker 72B + Continue.dev for data residency requirements

^[29]

Key finding: "Success depends on workflow discipline — writing clear specifications, maintaining review gates, and implementing verification systems — rather than tool selection alone."^[29]

5.6 GitHub Agentic Workflows + Sweep: Issue-to-PR Automation

GitHub Agentic Workflows (Technical Preview, 2026): Markdown files combining YAML config with natural language task descriptions, built on GitHub Actions infrastructure. Safety-first design: isolated sandboxes, read-only by default, write actions require review approval.^[23]

Sweep AI (open-source): Triggered by adding a sweep label to any GitHub issue or prefixing the title with "Sweep:". Automated flow: reads codebase → posts comment outlining plan → developer replies to adjust → creates branch → makes incremental commits (test-first) → submits PR.^[23]

Sweep: Effective vs. Failure Use Cases

^[23]

Tool Comparison Matrix

^{[3][4][5][13][14][17][22][29]}

Section 6: Mutation Testing — Mutmut, Stryker, PIT

Mutation testing introduces deliberate code modifications and verifies whether tests detect them. Score formula: killed mutants / total mutants. "Code coverage tells you what ran. Mutation testing tells you what your tests would actually catch if the code were wrong."^[6]

Why AI Code Specifically Needs Mutation Testing

Survival rates on AI-generated code are 15-25% higher than on human-written code at equivalent coverage levels.^[6] AI produces "structurally correct but semantically drifted" code lacking domain understanding. Documented incident: 92% coverage + passing tests failed to catch a deduplication bug using reference equality instead of business key comparison.^[6]

Key finding: "An agent that writes code and tests can achieve 100% coverage with tests that don't actually verify behavior." Mutation testing is the only quality signal that detects this class of failure — coverage metrics are insufficient for autonomous agent output.^[15]

Tool Landscape by Language

^[6][15][25]

Stryker (JavaScript/TypeScript) Performance

Per-test coverage analysis runs only relevant tests per mutant. With incremental mode and parallel execution: "Run mutation testing on every PR in 1-5 minutes for most codebases." In generative AI pipelines, parallel execution cut CI time from 45 to 18 minutes.^[25]

Critical Stryker limitation: Does NOT support Vitest's browser mode because "their instrumentation assumes Node.js execution, but browser mode runs tests in actual Chromium via Playwright." Agent-based manual mutation testing is the fallback for browser-mode stacks.^[15]

Stryker .NET Performance Benchmark (2025 IEEE Software)

^[15]

PIT (Java) Configuration

<plugin>
  <groupId>org.pitest</groupId>
  <artifactId>pitest-maven</artifactId>
  <version>1.15.3</version>
  <configuration>
    <mutators>
      <mutator>DEFAULTS</mutator>
      <mutator>REMOVE_CONDITIONALS</mutator>
      <mutator>RETURN_VALS</mutator>
    </mutators>
    <outputFormats><param>HTML</param><param>XML</param></outputFormats>
  </configuration>
</plugin>

Differential mutation testing (changed files only): 2-5 minutes runtime.^[6]

Agent Skill Tool Detection Logic

An autonomous agent can select the right mutation tool by inspecting project files:^[25]

Quality gate: 100% kill rate required (all mutants must be killed) in the agent skill pattern — below 100% blocks the PR and lists survivors with specific test recommendations. Scope: changed files only (not entire codebase).^[25]

Recommended CI Thresholds

^[6]

Autonomous Mutation-Testing Loop Vision

"A living mutant will spawn a secondary 'Test Generator' agent to create a test case to kill it, before a PR is even reviewed by a human."^[6]

1. AI generates code
2. Mutation testing identifies surviving mutants
3. Secondary agent generates tests to kill them
4. Loop continues until score threshold met
5. Human reviewer only concerned with intent, not coverage

AI Agent Manual Mutation Testing (When Tools Don't Work)

Claude Code can execute mutation testing manually when automated tools don't support the stack:^[15][25]

1. Read source code
2. Apply one mutation at a time (boundaries, boolean logic, return values, statement removal)
3. Run test suite
4. Record pass/fail results
5. Restore original code
6. Report surviving mutants with fix suggestions

Real result: 38% mutation score (8 surviving mutants of 13 total) on a settings feature. Gaps found: volume boundary constraints, DOM class assignments, error handling paths.^[15]

Section 7: Property-Based Testing — Hypothesis, fast-check

Property-based testing specifies a general invariant and relies on the framework to generate thousands of inputs that might violate it, instead of verifying specific hand-picked examples. The framework shrinks failures to the smallest reproducing input.^[7][16][26]

Anthropic Research: Autonomous Property-Based Testing Agent

Published paper: "Agentic Property-Based Testing: Finding Bugs Across the Python Ecosystem" (NeurIPS 2025 Deep Learning for Code Workshop). arXiv reference: 2510.09907.^[7][16]

Agent Workflow (5 Steps)

^[7][16][26] Agent uses a to-do list for long-range reasoning across multiple files. Self-reflection loop minimizes false positives.^[7]

Large-Scale Evaluation Results (100 Popular Python Packages)

^[7][16][26]

Confirmed Bugs Merged into Production Codebases

^[16]

Key finding: Model improvements are measurable in PBT performance: "Opus 4.1 and Sonnet 4.5, compared to Sonnet 4" showed significantly better self-reflection capabilities — directly reducing the false positive rate that would otherwise block autonomous PR flows.^[16]

Hypothesis CI Profile Configuration

Hypothesis is safe to run in parallel with pytest-xdist; each worker gets an independent random seed.^[7]

fast-check (TypeScript/JavaScript)

CI integration with FC_NUM_RUNS=1000 increases iteration count for CI runs:^[16][26]

Hegel (2026): Cross-Language Property Testing

A new family of PBT libraries bringing Hypothesis-quality property testing to every language. Hegel for Rust released 2026, designed for autonomous CI integration.^[26]

Combining with Mutation Testing

Properties that survive mutations are vacuous — they don't actually detect real bugs. Running mutation testing after property-based test generation identifies which properties are checking real invariants vs. which are effectively no-ops.^[26]

Known Limitations

• Agent struggles with code containing "subtle or complex semantics" — implicit assumptions require domain expertise only maintainers possess^[7]
• False positives remain unavoidable for code with domain-specific invariants (example: python-dateutil reported bug reflected intended behavior)^[16]
• Self-reflection loop required to prevent false positives from blocking legitimate work^[16]

Section 8: Security Scanning — Semgrep, Snyk

Security scanning in autonomous agent loops operates at "Level 2 Continuous AI" — AI handles routine security work (detection, triage, PR generation) while developers focus on complex problems.^[8] Common vulnerabilities in AI-generated code include exposed API keys, missing input validation, insecure default configurations, overly permissive CORS headers, SQL injection, and XSS risks.^[8][4]

Snyk vs. Semgrep: Technical Comparison (2026)

^[27][8]

Critical Semgrep Architectural Limitation

"Semgrep's cross-file analysis does NOT run on diff-aware PR scans. It only runs on full repository scans." Vulnerabilities requiring multi-file taint tracking won't be detected until a subsequent full scan — an autonomous loop that runs only PR-triggered scans will miss cross-file injection chains.^[27]

Snyk Mission Control: Autonomous Vulnerability Loop

1. Snyk detects vulnerability
2. AI agent automatically generates fix
3. Agent creates PR
4. Agent validates solution
5. No manual intervention required^[8][27]

Semgrep Multimodal (Announced March 2026)

Combines AI reasoning with deterministic rule-based analysis. Claimed performance improvements: 8× more true positives with 50% fewer false positives compared to rule-only Semgrep.^[8]

Semgrep Scaling Constraints

^[27]

Semgrep Managed Scans

Used by 40%+ of Semgrep customers — Semgrep clones and scans repos on their own infrastructure, with no CI runner required. Eliminates the overhead of maintaining CI scan jobs for each repository.^[27]

Key finding: Production-grade security-mature teams combine both tools: "Snyk for SCA, container scanning, and IaC, paired with Semgrep for custom SAST rules and fast CI scanning." This combination covers Semgrep's cross-file gap (Snyk's server-side processing handles cross-file analysis) while using Semgrep's speed advantage for every PR.^[27]

Pre-Commit Security Gate Policies

• Block commits with high-severity findings
• Enforce lowest-risk dependency upgrades with re-testing
• Scan container base images before builds
• Validate Terraform changes for compliance^[8]

Section 9: Integrated Loop Architecture

A production autonomous build-test-ship loop combines CC hooks, scheduled execution, headless invocations, and quality signal layers into a single pipeline. The key design principle: each quality layer fires at the appropriate loop frequency to maximize signal without burning tokens.

Quality Signal Firing Frequency

Autonomous Commit Workflow Pattern

Stage files on edit (PostToolUse), commit at Stop — stages incrementally (reversible) and commits only post-validation. Pattern sequence:^[11]

1. PostToolUse (Edit/Write) → lint + format + stage file (git add)
2. Stop hook → run tests → if pass: git commit with descriptive message; if fail: exit 2 → Claude fixes
3. Next Stop (after fix) → check stop_hook_active → skip re-commit if already in remediation pass

Iterative Orchestration: Python Control Loop Pattern

while not done:
    result = run_claude_headless(prompt)
    errors = run_tests_and_lint()
    if not errors:
        done = True
    else:
        prompt = f"Fix these errors: {errors}"

^[28]

Agentic Testing Architecture Trends (QualiZeal Research, 2025)

• "Smart agent" features being built into CI tools
• Plan-Act-Verify reasoning loops for autonomous test generation
• Self-healing test suites that update when UI/API changes
• Agent-generated tests outperform human-written tests for edge cases^[16]

Section 10: Production Patterns and Real Configurations

PostToolUse: Per-File Lint and Format Hook

#!/usr/bin/env bash
set -euo pipefail
INPUT=$(cat)
FILE_PATH=$(echo "$INPUT" | jq -r '.tool_input.file_path // empty')
[[ -z "$FILE_PATH" ]] && exit 0
cd "$CLAUDE_PROJECT_DIR"
case "$FILE_PATH" in
  *.ts|*.tsx|*.js|*.jsx)
    npx --no-install prettier --write "$FILE_PATH" 2>&1 || true
    npx --no-install eslint --fix "$FILE_PATH" 2>&1 || true
    ;;
  *.py)
    ruff format "$FILE_PATH" 2>&1 || true
    ruff check --fix "$FILE_PATH" 2>&1 || true
    ;;
esac

^[11] Use || true guards to prevent linter errors from blocking; --no-install fails fast if deps are missing; $CLAUDE_PROJECT_DIR ensures portability. Production note: Hooks run in non-login shells — runtimes like nvm (Node.js) and pyenv (Python) are not automatically loaded. Add explicit sourcing before the case block, e.g. [ -s "$HOME/.nvm/nvm.sh" ] && source "$HOME/.nvm/nvm.sh", otherwise tools resolve to system-default versions rather than the project's pinned runtime.^[11]

Stop Hook: Test Suite with Anti-Loop Guard

#!/usr/bin/env bash
set -euo pipefail
INPUT=$(cat)
ALREADY_LOOPING=$(echo "$INPUT" | jq -r '.stop_hook_active // false')
if [[ "$ALREADY_LOOPING" == "true" ]]; then exit 0; fi
cd "$CLAUDE_PROJECT_DIR"
if git diff --quiet --name-only -- '*.ts' '*.tsx' '*.js' '*.py' 2>/dev/null; then
  exit 0
fi
if ! npm test --silent; then
  echo "Tests failed. Review output and fix before ending." >&2
  exit 2
fi

^[11]

PreToolUse: Block Dangerous Commands

COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command // empty')
if echo "$COMMAND" | grep -qE 'rm[[:space:]]+-rf[[:space:]]+/|git[[:space:]]+push.*--force|chmod[[:space:]]+777'; then
  echo '{"decision": "block", "reason": "Blocked: contains unsafe pattern. Request manual execution."}'
  exit 0
fi

^[11]

MCP Security Scan Hook (PostToolUse on Write)

{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Write|Edit",
      "hooks": [{
        "type": "mcp_tool",
        "server": "my_server",
        "tool": "security_scan",
        "input": { "file_path": "${tool_input.file_path}" }
      }]
    }]
  }
}

^[1][19]

Stryker GitHub Actions CI Gate

name: Mutation Testing
on:
  pull_request:
    branches: [main]
jobs:
  mutation:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Stryker
        run: npx stryker run --incremental
      - name: Check mutation score
        run: |
          score=$(cat reports/mutation/mutation.json | jq '.metrics.mutationScore')
          if (( $(echo "$score < 80" | bc -l) )); then
            echo "Mutation score $score% below threshold"
            exit 1
          fi

^[25]

Mutmut Configuration (pyproject.toml)

[tool.mutmut]
paths_to_mutate = "src/"
backup = false
runner = "python -m pytest"
tests_dir = "tests/"

^[15][25]

Hypothesis CI Configuration (GitHub Actions)

- name: Property-based tests
  env:
    HYPOTHESIS_PROFILE: ci
  run: pytest --hypothesis-seed=0 tests/

^[7]

Semgrep PR Gate (GitHub Actions)

name: Semgrep
on:
  pull_request: {}
jobs:
  semgrep:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Semgrep
        run: semgrep --config=auto --json --output=results.json
        env:
          SEMGREP_APP_TOKEN: ${{ secrets.SEMGREP_APP_TOKEN }}
      - name: Block on high-severity findings
        run: |
          high=$(jq '[.results[] | select(.extra.severity == "ERROR")] | length' results.json)
          if [ "$high" -gt 0 ]; then exit 1; fi

^[27]

Snyk CI/CD Integration (GitHub Actions)

name: Security Scan
on: [pull_request]
jobs:
  snyk-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Snyk
        uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          command: code test
      - name: Generate AI fix
        if: failure()
        run: |
          snyk code test --json | ai-fix-agent --post-as-pr-comment

^[27]

Headless CI Test-Fix Loop Pattern

claude --bare -p "Run the test suite. If tests fail, identify the root cause and fix it.
Then re-run tests to verify. Repeat until all tests pass or you've attempted 3 fixes." \
  --allowedTools "Bash,Read,Edit" \
  --output-format json

^[9]

Goose SRE Agent Recipe

goal: Monitor system health and respond to alerts
extensions: [datadog-mcp, github-mcp, slack-mcp]
steps:
  - Check active alerts in Datadog
  - For each critical alert: diagnose root cause from logs
  - Create GitHub issue with diagnosis
  - Notify on-call via Slack
  - If fixable: create PR with remediation

^[24]

Aider YAML Config for Autonomous Loops

auto-commits: true
dirty-commits: true
yes-always: true
model: claude-sonnet-4-5
git-commit-verify: false

^[13]

Codex CLI Non-Interactive Configuration

[agent]
model = "gpt-5.3-codex"
approval_mode = "full-auto"

[system]
instructions = "You are a TypeScript expert. Always write tests."

[sandbox]
max_file_size = 10485760
allow_paths = ["./src", "./tests"]
deny_paths = [".env", "~/.ssh"]

^[17]

Cursor Composer 2 Post-Session Verification Script

#!/bin/bash
set -e
npx tsc --noEmit
npx eslint src/ --max-warnings=0
npm test -- --passWithNoTests
npm run build
semgrep --config=auto --error
echo "All checks passed"

^[29]

Home