Agent Pipeline Architecture
The devops-plugin is a Claude Code plugin that automates the software development inner loop. It chains specialized agents — each responsible for a single step — so that a YouTrack issue flows from backlog to merged PR with minimal human intervention.
Core pipeline stages
The pipeline proceeds through three repeating stages until the issue reaches Stage=Done or the maximum iteration count (5) is exceeded:
flowchart LR
%% Core pipeline stage loop
IR[issue-resolver\nimplements + opens PR]
PRv[pr-reviewer\nreviews + approves or requests changes]
PRr[pr-resolver\nfixes review feedback]
Done([Stage = Done])
IR --> PRv
PRv -->|approved + merged| Done
PRv -->|Need Changes label| PRr
PRr --> PRv
Stage 1 — issue-resolver
The issue-resolver agent:
- Fetches the YouTrack issue and validates the
Git Repofield. - Checks for an
## Open Questionssection — blocks and exits if unresolved questions are present. - Marks the issue
Stage=In Progressand unassignsClaude_Codeto prevent double-pickup. - Creates a feature branch off
mainusing the convention<type>/<issue-id>-<short-slug>. - Routes implementation to a specialist agent if one is identified (see @ai-development.workflow-conventions).
- Commits the change and opens a PR targeting
main, referencing the YouTrack issue URL. - Labels the PR
Readyto signal the reviewer.
Stage 2 — pr-reviewer
The pr-reviewer agent:
- Finds the open PR with the
Readylabel. - Reviews the diff for correctness, convention adherence, and completeness.
- Ticks verified task-list checkboxes in the PR body.
- Either approves and merges (sets
Stage=Doneon the YouTrack issue), or requests changes (appliesNeed Changeslabel, leaves actionable feedback). - Deletes the source branch after a successful merge.
Stage 3 — pr-resolver (conditional)
The pr-resolver agent activates only when the PR carries the Need Changes label:
- Reads the review comments on the PR.
- Applies the requested fixes in the working tree.
- Commits and pushes to the feature branch.
- Re-labels the PR
Ready.
Planning pipeline (upstream)
Before issues reach the core pipeline, two optional planning agents structure the work:
flowchart TD
%% Planning pipeline
User([User brief])
FD[feature-designer\nmodule breakdown + design doc]
TL[tech-leader\nlane decomposition + interaction contracts]
IC[issue-creater\nfiles YouTrack issues]
User --> FD
FD --> TL
TL --> IC
IC -->|issues ready for pipeline| D[dispatcher]
| Agent | Input | Output |
|---|---|---|
feature-designer |
Project or feature brief | Design doc + module epic issues |
tech-leader |
Module epic issue | Per-lane sub-issues with interaction contracts |
issue-creater |
Structured fields | Filed YouTrack issue |
Dispatcher and pipeline orchestrator
dispatcher— validates repos on Gitea, creates per-task git worktrees, and fans out issues to concurrentpipelinesubagents (max 5 at a time).pipeline— drives a single issue through the resolver → reviewer → resolver loop untilStage=Doneor iteration budget is exhausted.
State machine
YouTrack custom fields track pipeline state:
| Field | Values | Set by |
|---|---|---|
Stage |
To Do → In Progress → Done |
issue-resolver sets In Progress; pr-reviewer sets Done |
Assignee |
Claude_Code or unset |
Set to Claude_Code by planner / dispatcher; unset by issue-resolver when work begins |
Git Repo |
repo name (e.g. doc) |
Set by issue author; read by issue-resolver to determine the target repo |