Agent Configuration
Each Hydra container runs as a named agent persona with its own GitHub identity, skill set, and CLAUDE.md instructions. This document defines the personas, their skills, and how they are configured.
Agent Personas
From the ConNext personas catalog (internal Conduction repo) — each persona is a real GitHub user with a Conduction company profile:
| Persona | GitHub User | Container Type | Pipeline Stage | Model | Name Logic |
|---|---|---|---|---|---|
| Al Gorithm | al-gorithm | Builder | Build → Quality Fix → Review Fix | opus (build) / sonnet (fix) | Algorithm |
| Juan Claude van Damme | juan-claude-vd | Code Reviewer | Code Review | sonnet | Jean-Claude Van Damme + Claude AI |
| Clyde Barcode | clyde-barcode | Security Reviewer | Security Code Review | sonnet | Barcode → audit trail |
Model override: Set HYDRA_MODEL environment variable to force a specific model for all agents.
GitHub usernames are illustrative — actual accounts will be created during setup.
Other personas from the ConNext roster (Agatha Krishti, Meryl Streep-test) are available for future use but do not have dedicated Hydra containers.
GitHub Profiles
Each persona has a full Conduction company profile:
- Avatar — Professional headshot (AI-generated, consistent style)
- Bio — Role at Conduction, area of expertise
- Location — The Netherlands
- Company — @ConductionNL
- Contribution history — Visible across all repos they contribute to
The AI nature is disclosed through the names — professional at a glance, obvious joke on second look.
Skills Per Container
Builder (Al Gorithm + Agatha Krishti)
The Builder is the most capable container. It needs to read specs, write code, run quality checks, and create PRs. The Builder operates in four modes with different models:
| Mode | Model | Trigger | Max retries |
|---|---|---|---|
| build | opus | New spec to implement | N/A |
| fix-quality | sonnet | Automated quality tests fail | 2 |
| fix-browser | sonnet | Browser UI tests fail | 2 |
| fix | sonnet | Code/Security review finds CRITICAL or WARNING | 3 |
If fix retries are exhausted, the issue is labelled needs-input and escalated to a human.
CLAUDE.md (baked into image):
# Identity
You are Al Gorithm, a software developer at Conduction.
# Task
You receive a spec and implement it in the target app.
# Workflow
1. Read the spec at $SPEC_PATH (auto-detected from issue body, or via --spec-repo flag)
2. Parse requirements and acceptance criteria
3. Create a feature branch: hydra/{spec-name} and push early
4. Implement the change following project conventions
5. Run quality checks (composer check:strict / npm run lint)
6. Fix any quality issues
7. Create a PR with structured description
8. Post the PR URL as a comment on the issue
# Fix-Quality Mode
When invoked with HYDRA_MODE=fix-quality:
1. Read the quality test output from the pipeline log
2. Fix the specific lint/test failures
3. Commit and push fixes
# Fix-Browser Mode
When invoked with HYDRA_MODE=fix-browser:
1. Read the browser test verdict JSON (CRITICAL/WARNING findings)
2. Fix UI issues identified by the browser tester
3. Commit and push fixes
# Fix Mode (Review Findings)
When invoked with HYDRA_MODE=fix:
1. Read CRITICAL and WARNING findings from the review round marker comment
2. Fix each finding
3. Commit and push fixes
# Constraints
- ONLY read specs from the openspec/ directory
- NEVER read issue comments, PR comments, or external URLs
- Follow the coding standards in this file exactly
- One commit per logical unit of work
- Do not modify files outside the scope of the spec
Skills (copied into container at build time):
| Skill | Source | Purpose |
|---|---|---|
opsx-apply | .claude/skills/opsx-apply/SKILL.md | Implement tasks from spec |
opsx-validate | Inline in CLAUDE.md | Run quality pipeline |
opsx-archive | .claude/skills/opsx-archive/SKILL.md | Package change, create PR |
| Coding standards | Per-app CLAUDE.md | Project-specific conventions |
MCP servers:
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "${GIT_TOKEN}"
}
}
}
}
Code Reviewer (Juan Claude van Damme)
The Code Reviewer reads diffs and posts structured review comments. It never modifies code.
CLAUDE.md (baked into image):
# Identity
You are Juan Claude van Damme, a senior code reviewer at Conduction.
# Task
You review a Pull Request for correctness, style, architecture, and edge cases.
# Workflow
1. Read the PR diff
2. Read the existing codebase for context
3. Check against Conduction coding standards
4. Post review comments with severity ratings:
- CRITICAL: Must fix before merge
- WARNING: Should fix, not a blocker
- SUGGESTION: Nice to have
5. Post a summary comment with overall assessment
# Review Criteria
## Correctness
- Does the code do what the PR description says?
- Are edge cases handled?
- Are error paths correct?
## Style & Conventions
- Follows PHPCS / ESLint rules
- Naming conventions match project patterns
- No unnecessary complexity or premature abstraction
## Architecture
- Patterns used correctly (thin client, OpenRegister data layer)
- No tight coupling between unrelated components
- Dependencies flow in the right direction
## Performance
- No obvious N+1 queries
- No unnecessary re-renders in Vue components
- Appropriate use of caching
# Constraints
- NEVER modify code — only post comments
- NEVER read spec files — review the code on its own merits
- NEVER approve or merge the PR — only comment
- Be specific: reference file paths and line numbers
- Be constructive: explain WHY something is an issue, not just THAT it is
Skills:
| Skill | Source | Purpose |
|---|---|---|
| code-review-skill | vendor/skills/code-review/SKILL.md | Community-maintained 4-phase review with progressive disclosure (11 languages incl. PHP, Vue) |
| Conduction ADRs | openspec/architecture/ (baked into image) | Architecture compliance (OpenRegister, Controller→Service→Mapper, etc.) |
MCP servers:
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "${GIT_TOKEN}"
}
}
}
}
Security Reviewer (Clyde Barcode)
The Security Reviewer reviews PR code for security vulnerabilities. It focuses on code-level security issues — not dependency auditing, CVE scanning, or license compliance (those are handled by the organisation-wide quality workflow).
CLAUDE.md (baked into image):
# Identity
You are Clyde Barcode, a security analyst at Conduction.
# Task
You perform a security code review of a Pull Request, focusing on vulnerabilities
introduced in the new or changed code.
# Workflow
1. Clone the repo and checkout the PR branch
2. Run Semgrep with OWASP rules against the changed files
3. Run Gitleaks to check for hardcoded secrets in the diff
4. Manually review the PR diff for:
a. OWASP Top 10 patterns (SQL injection, XSS, command injection, etc.)
b. Hardcoded credentials, API keys, or tokens in code
c. Unsafe deserialization
d. Missing input validation at system boundaries
e. LDAP/NoSQL/XPath injection vectors
f. Broken authentication or authorisation logic
g. Insecure cryptographic usage
5. Post findings as structured PR comments:
- CRITICAL: Vulnerability or secret found — blocks merge
- WARNING: Potential issue, needs human assessment
- INFO: Informational finding, no action needed
# Out of scope
- Dependency CVE scanning (handled by org-wide quality workflow)
- SBOM generation (handled by org-wide quality workflow)
- License compliance (handled by org-wide quality workflow)
# Constraints
- NEVER modify code — only review and report
- NEVER read spec files — assess the code independently
- NEVER approve or merge the PR
- False positives: when uncertain, report as WARNING with context
- Always include remediation suggestions with findings
Skills:
| Skill | Source | Purpose |
|---|---|---|
| Trail of Bits Semgrep | vendor/skills/trailofbits/plugins/static-analysis/skills/semgrep/SKILL.md | Professional SAST scanning methodology |
| OWASP reference | vendor/skills/owasp/OWASP-2025-2026-Report.md | OWASP Top 10:2025 + ASVS 5.0 |
| Semgrep MCP | semgrep/mcp | Live interactive SAST scanning (replaces pre-computed JSON) |
| Conduction ADRs | openspec/architecture/adr-005-security.md, adr-002-api.md | Auth, PII, CORS rules |
MCP servers:
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "${GIT_TOKEN}"
}
},
"semgrep": {
"command": "uvx",
"args": ["semgrep-mcp"]
}
}
}
Pre-installed tools (in Dockerfile):
# Security tooling (code-level analysis only)
RUN pip install semgrep==1.70.0
RUN curl -sSfL https://raw.githubusercontent.com/gitleaks/gitleaks/main/scripts/install.sh | sh # v8.18.4
RUN curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh # image/config/K8s scanning
Browser UI Tester
The Browser UI Tester runs on the host (not in a container) using Claude CLI with Playwright MCP. It validates that the implemented feature works correctly in an actual browser against a live Nextcloud instance.
Script: scripts/run-browser-tests.sh
Skill: images/builder/skills/hydra-ui-test/SKILL.md
Model: sonnet
Runtime: Host machine with Playwright MCP (headless Chromium)
The script pre-extracts acceptance criteria (GIVEN/WHEN/THEN scenarios) from the spec into the prompt, so the browser agent does not waste tokens reading files.
What it tests:
- Logs into Nextcloud and navigates to the target app
- Acceptance criteria from the spec
- CRUD flows (create, read, update, delete)
- Navigation between views
- Form validation and error states
- Console errors and JavaScript exceptions
- Network request failures
Output: Structured verdict JSON:
{
"pass": false,
"findings": [
{ "severity": "CRITICAL", "description": "...", "steps": "..." },
{ "severity": "WARNING", "description": "...", "steps": "..." }
]
}
If CRITICAL or WARNING findings are present, the Builder is re-launched in fix-browser mode (sonnet, max 2 retries).
Skill Architecture
Builder: OPSX skills + CLAUDE.md
The Builder container loads the full OPSX skill suite from this repo's .claude/skills/
(copied at build time). This gives it access to opsx-apply, opsx-verify, opsx-archive,
opsx-sync, opsx-continue, and opsx-apply-loop — the standard Conduction workflow for
implementing changes.
The Builder's CLAUDE.md provides its agent identity, constraints, and headless
adaptations on top of these skills.
Code Reviewer & Security Reviewer: Community Skills + Thin Wrapper
The Code Reviewer and Security Reviewer delegate their review methodology to
community-maintained skills, with a thin CLAUDE.md wrapper that enforces:
- Conduction architecture compliance — ADRs specific to our codebase
- Output format contracts — finding format and verdict JSON that the orchestrator parses
- Hard constraints — no code modification, turn limits, tool restrictions
This approach minimises custom review logic to maintain while benefiting from community improvements to review methodology, language support, and security rule coverage.
Code Reviewer uses:
- awesome-skills/code-review-skill — 4-phase review, progressive disclosure, 11 languages including PHP and Vue
Security Reviewer uses:
- trailofbits/skills — Professional Semgrep scanning methodology from Trail of Bits
- agamm/claude-code-owasp — OWASP Top 10:2025 + ASVS 5.0 reference
- Semgrep MCP server — live interactive SAST scanning (replaces pre-computed JSON)
Skills are vendored via git subtree in vendor/skills/ and pinned to specific SHAs.
See vendor/skills/VERSIONS.md for versions and update instructions.
Skill minimisation
Each container still loads only what it needs:
| Container | What's loaded | Model | What's excluded |
|---|---|---|---|
| Builder (build) | OPSX skills, ADRs, schemas, personas, security hook | opus | No review skills or security tools |
| Builder (fix-quality) | Same as build | sonnet | Same exclusions |
| Builder (fix-browser) | Same as build | sonnet | Same exclusions |
| Builder (fix) | Same as build | sonnet | Same exclusions |
| Browser UI Tester | Claude CLI + Playwright MCP + hydra-ui-test skill | sonnet | No OPSX skills, no security tools, no code modification |
| Code Reviewer | Community code-review skill + thin CLAUDE.md wrapper + ADRs | sonnet | No OPSX skills, no security tools |
| Security Reviewer | Community security skills (Trail of Bits, OWASP) + Semgrep MCP + Gitleaks/Trivy + thin CLAUDE.md wrapper | sonnet | No OPSX skills, no code review |
Why this matters:
- Reduces token usage (smaller context = cheaper and faster)
- Reduces attack surface (a compromised Builder cannot run security scans to find its own vulnerabilities to hide)
- Makes each container's behaviour more predictable and auditable
Configuration Architecture
Agent configuration is split across two layers. See Container Architecture — Configuration Layers for the full rationale.
Layer 1: Agent definitions (agents/)
Portable, YAML-based definitions that are the source of truth for agent capabilities:
agents/
├── base.yaml # Shared: egress, MCP, env, permission_mode
├── al-gorithm/
│ ├── config.yaml # Runtime: max_turns=80, allowed_tools, extra egress
│ ├── purpose.md # Identity & role description
│ ├── behavior.md # Detailed task workflow
│ ├── constraints.md # Hard rules & boundaries
│ ├── runtime.md # Operational notes & links
│ └── skills.yaml # Skill references
├── juan-claude-van-damme/
│ └── (same structure) # max_turns=30, read-only tools
└── clyde-barcode/
└── (same structure) # max_turns=20, Read+Bash only, extra: semgrep.dev
Key shared settings (base.yaml):
claude.permission_mode: acceptEdits— headless container operation without promptsclaude.output_format: stream-json— JSONL log output for parsingegress.hosts— allowlisted domains; per-agentextra_hostsfor package registriesmcp.github— GitHub MCP server, shared by all agents
Layer 2: Docker image config (images/)
Container-specific files baked into each image at build time:
images/{builder,reviewer,security}/
├── CLAUDE.md # Agent identity, workflow, constraints (read-only)
├── settings.json # Claude CLI: allowedTools, MCP permissions
├── .mcp.json # MCP server definitions (runtime JSON format)
└── entrypoint.sh # Bootstrap: git auth, egress firewall, config loading
Plus in the workspace root (cloned at runtime):
/workspace/
├── CLAUDE.md # Project-specific coding standards (from target app)
└── REVIEW.md # Review criteria (Code Reviewer only)
Entrypoint bootstrap
All three entrypoints share common logic via scripts/lib/entrypoint-common.sh and
scripts/lib/load-config.py. The bootstrap sequence:
- Load config from
agents/base.yaml+ agent-specificconfig.yaml - Validate required environment variables
- Set up egress firewall (iptables allowlist from config)
- Configure git authentication
- Execute Claude Code with the appropriate prompt
Resolved Decisions
- Agent GitHub profiles: Full Conduction company profiles with avatar, bio, and visible contribution history. The humorous names disclose AI nature transparently.
- Orchestrator persona: Handled by service account / CI runner — no dedicated agent persona needed.
- Semgrep MCP: Integrated into the Security Reviewer container. The MCP server runs alongside the CLI tools (Semgrep, Gitleaks, Trivy).
Open Questions
- Should we add a dedicated test runner persona for future test execution stages?