devops-build-fix

name	devops:build:fix
description	"This skill should be used when the user mentions "build failed", "pipeline failure", "fix build", "CommonIntegration failing", "entity tests failing", "repository tests failing", or when Azure DevOps build errors are detected. Orchestrates diagnosis and resolution of Azure DevOps build failures with intelligent agent routing and task tracking."
version	2.0.0
tools	["Read","Edit","Write","Bash","Task","TaskCreate","TaskUpdate","TaskGet","TaskList"]
mcp-servers	["devops"]

Build Fix Orchestrator v2.0

Orchestrates Azure DevOps build failure diagnosis and resolution with intelligent agent routing, native Task tracking, and cross-session persistence.

What's New in v2.0

Feature	Description
Task Tools Integration	Native TaskCreate/TaskUpdate/TaskList for progress tracking
Intelligent Routing	Auto-select optimal agent based on failure signals
Team Coordination	Multi-agent teams for complex failures
File Persistence	Cross-session recovery with --resume
Confidence Scoring	Transparent routing decisions with signal analysis

Overview

This skill automates the fix cycle for CI pipeline failures:

1. Diagnose → Fetch build status, identify failing stage/task
2. Route → Detect domain, select optimal agent (NEW)
3. Analyze → Delegate to specialized agents
4. Verify → Run tests locally before committing
5. Apply → Commit and push fixes
6. Monitor → Poll pipeline until success or max attempts

Quick Reference

/devops:build.fix [options]

Options:
  --status        Show current build status without action
  --resume        Resume from previous orchestration state
  --local-test    Run tests locally before triggering pipeline
  --max-attempts  Maximum fix attempts (default: 5)
  --dry-run       Analyze and route without making changes
  --verbose       Show routing signals and confidence scores

Configuration

Setting	Value	Description
Pipeline Definition	3	gsb-ci build definition ID
Target Stage	CommonIntegration	Stage with integration tests
Polling Interval	30s	Build progress check frequency
Max Attempts	5	Maximum fix iterations
Min Confidence	0.40	Minimum for specialized agent
Team Threshold	0.60	When to spawn multi-agent team

Core Workflow

Phase 1: Diagnosis

Fetch recent builds and identify failure:

mcp__devops__get-builds:
  definitionIds: [3]
  top: 5

For failed builds, get timeline details:

mcp__devops__get-pipeline-status:
  buildId: <failed_build_id>
  includeTimeline: true

Create orchestration task:

TaskCreate({
  subject: `Build Fix: #${buildId} - ${errorSummary}`,
  description: `Fix ${failingStage}/${failingTask} failure`,
  activeForm: "Diagnosing build failure...",
  metadata: {
    type: "orchestration",
    buildId,
    pipelineId: 3,
    failingStage,
    failingTask,
    maxAttempts: 5,
    currentAttempt: 1
  }
})

Phase 2: Intelligent Routing (NEW)

Analyze failure signals to select optimal agent:

Signal	Weight	Examples
Task Name	40%	"Run Entity Tests" → java-expert
Error Pattern	35%	PropertyNotFoundException → java-expert
Stack Trace	15%	sense.common.entity.* → java-expert
Recent Changes	10%	Modified **/entity/*.java → java-expert

Routing decision:

# High confidence (>0.75): Direct to single agent
type: agent
primary_agent: java-expert
confidence: 0.87

# Medium confidence (0.40-0.75) with similar scores: Spawn team
type: team
primary_agent: java-expert
secondary_agents: [database-expert]
confidence: 0.62

# Low confidence (<0.40): Use Explore agent first
type: explore
confidence: 0.32

Create attempt task with routing:

TaskCreate({
  subject: `Attempt ${n}: ${category} analysis`,
  description: `Routing: ${primaryAgent} (${confidence})`,
  activeForm: `Analyzing with ${primaryAgent}...`,
  metadata: {
    type: "attempt",
    attemptNumber: n,
    assignedAgent: primaryAgent,
    routingConfidence: confidence
  }
})

See references/agent-routing.yaml and references/failure-detection.yaml

Phase 3: Root Cause Analysis

Spawn specialized agents based on routing decision:

Agent	Domains	Typical Issues
java-expert	Entity, JPA, Hibernate	@Column, @Id, fetch types
database-expert	Repository, SQL, JPQL	Query syntax, transactions
maven-expert	Build, dependencies	POM, plugins, versions
typescript-expert	Frontend build	TS errors, imports
react-expert	Frontend tests	Hooks, component tests

Single agent spawn:

Task({
  subagent_type: "java-expert",
  description: "Analyze entity failures",
  prompt: `
    Build ID: ${buildId}, Stage: CommonIntegration
    Failing task: ${failingTask}
    Error: ${errorSummary}

    Analyze and provide fix with file path and code changes.
  `,
  run_in_background: true
})

Team spawn (for complex failures):

// Primary agent
Task({
  subagent_type: "java-expert",
  description: "Analyze entity failures (lead)",
  prompt: teamPromptForLead,
  run_in_background: true
})

// Secondary agent (in parallel)
Task({
  subagent_type: "database-expert",
  description: "Analyze repository failures",
  prompt: teamPromptForMember,
  run_in_background: true
})

See references/agent-prompts.md and references/team-coordination.md

Phase 4: Local Verification

Run failing tests locally before committing:

# Entity tests
./scripts/run-entity-tests.sh

# Repository tests
./scripts/run-repo-tests.sh

Update task:

TaskUpdate({
  taskId: attemptTaskId,
  metadata: { phase: "verification", localTestsPassed: true }
})

• Tests pass → Proceed to commit
• Tests fail → Return to Phase 3 with new context

Phase 5: Apply Fixes

Stage, commit, and push changes:

git add -A
git commit -m "fix(common): resolve [category] test failures

Fixes: [test classes]
Root cause: [description]
Build: #[build_number]
Agent: [agent_used] (confidence: [score])

Co-Authored-By: Claude Opus 4.5 <[e-mail]>"

git push origin HEAD

Update task:

TaskUpdate({
  taskId: attemptTaskId,
  metadata: {
    phase: "apply",
    commitSha: commitSha,
    fixesApplied: [{ file, line, change }]
  }
})

Phase 6: Monitor Pipeline

Poll build progress every 30 seconds:

mcp__devops__get-pipeline-status:
  buildId: <new_build_id>
  includeTimeline: true

Update task:

TaskUpdate({
  taskId: attemptTaskId,
  metadata: { phase: "monitor", buildTriggered: newBuildId }
})

• SUCCESS → Complete orchestration, save state
• FAILURE → Capture details, increment attempt, return to Phase 1

Phase 7: Completion (NEW)

On success or max attempts:

// Mark complete
TaskUpdate({
  taskId: orchestrationTaskId,
  status: "completed",
  metadata: {
    status: "success", // or "max_attempts_reached"
    totalAttempts: n,
    totalDuration: seconds
  }
})

// Persist to file
./scripts/task-save.sh ${fixId}

Agent Coordination

Phase	Task Operations	Agent Tools
Diagnosis	TaskCreate (orchestration)	mcp__devops__get-builds
Routing	route-agent.sh	(internal analysis)
Analysis	TaskCreate (attempt), Task (spawn)	Read, Grep, Glob
Verification	TaskUpdate	Bash (mvn test)
Apply	TaskUpdate	Edit, Write, Bash (git)
Monitor	TaskUpdate	mcp__devops__get-pipeline-status
Complete	TaskUpdate, task-save.sh	(persistence)

Cross-Session Recovery

Save state automatically:

# On each phase transition
./scripts/task-save.sh ${fixId}

Resume in new session:

# Check for active fix
./scripts/task-load.sh --check-only

# Resume fix workflow
/devops:build.fix --resume

State persistence location:

.claude/tasks/build-fixes/
├── active/           # Current fix attempts
│   └── fix-<id>.yaml
└── history/          # Completed fixes
    └── YYYY-MM-DD/

See references/persistence-schema.md

Token Efficiency

1. Background Agents → Spawn with run_in_background: true
2. Structured Outputs → Parse only relevant MCP fields
3. Progressive Loading → Read files only when needed
4. Task Tracking → Native API instead of TodoWrite
5. Confidence-Based Routing → Skip secondary agents when confident

Error Recovery

Error	Recovery
MCP unavailable	Fall back to az devops CLI
Build timeout	Cancel, increase timeout, retry
Merge conflict	Notify user for manual resolution
Flaky test	Retry 2x locally before investigating
Docker unavailable	Check daemon with docker info
Agent timeout	Escalate to next agent in chain
Low confidence	Use Explore agent for investigation
Session interrupted	Resume with --resume flag

Boundaries

Will:

• Diagnose build failures using Azure DevOps APIs
• Route to optimal agent based on failure analysis
• Spawn teams for complex multi-domain failures
• Run tests locally to verify fixes
• Make code changes to fix test failures
• Commit and push to current branch
• Retry up to max_attempts times
• Persist state for cross-session recovery

Will Not:

• Modify pipeline YAML without approval
• Force push or rewrite git history
• Skip tests to make builds pass
• Exceed max_attempts without consent
• Push to protected branches without PR
• Route to agents without minimum confidence
• Proceed with conflicting team findings without user input

Resources

• references/task-schema.md → Task API integration patterns
• references/agent-routing.yaml → Agent selection configuration
• references/failure-detection.yaml → Signal analysis for routing
• references/team-coordination.md → Multi-agent team patterns
• references/persistence-schema.md → File-based state persistence
• references/failure-patterns.md → Root cause patterns by failure type
• references/agent-prompts.md → Sub-agent delegation templates
• references/pipeline-config.md → Pipeline configuration details
• references/iteration-tracking.md → State tracking schema
• examples/ → Output examples for each mode
• scripts/ → Utility scripts

Scripts

Script	Purpose
diagnose-build.sh	Fetch builds, identify failures
monitor-build.sh	Poll status until completion
run-entity-tests.sh	Run entity tests locally
run-repo-tests.sh	Run repository tests locally
route-agent.sh	Domain detection and agent routing
task-load.sh	Load persisted state on session start
task-save.sh	Save state for cross-session recovery
task-sync.sh	Bidirectional sync between file and API