---
name: autonomous-coding-agents
description: "Umbrella for delegating coding work to external autonomous agent CLIs and lanes: Claude Code, Codex, OpenCode, and Codex-backed Kanban workers."
version: 1.0.0
author: Hermes Agent
license: MIT
metadata:
  hermes:
    tags: [autonomous-agents, coding-agents, claude-code, codex, opencode, delegation, kanban]
    related_skills: [subagent-driven-development, hermes-agent]
---

# Autonomous Coding Agents

Use this class-level skill when a task should be delegated to an external coding agent process rather than handled only in the current Hermes turn.

## Choose the lane

- **Claude Code** — strong for feature implementation, broad codebase edits, and PR-level reasoning when the Claude Code CLI is installed and authenticated.
- **Codex CLI** — good for OpenAI/Codex-authenticated coding tasks, iterative fixes, and worktree-isolated implementation.
- **OpenCode** — use when the OpenCode CLI is the user's configured agent or when an OpenCode-specific review/implementation workflow is requested.
- **Kanban Codex lane** — use inside Hermes Kanban worker/orchestrator flows where Codex is the execution engine for a durable board task.

## Default workflow

1. Inspect repository state first: branch, dirty files, tests, and relevant docs.
2. Give the external agent a narrow, self-contained prompt: goal, constraints, files, acceptance tests, and what not to touch.
3. Prefer isolated worktrees/branches for multi-agent or risky work.
4. Poll/log the agent output; do not trust a self-report of success without verifying diffs/tests yourself.
5. Run the relevant test/build/lint commands in Hermes after the agent exits.
6. Summarize only verified changes and remaining blockers.

## Delegation vs spawning

- Use Hermes `delegate_task` for bounded subtasks that can finish in the current turn.
- Spawn external CLIs when the user explicitly wants that agent, the workflow is long-running, or the agent needs its own repo/worktree/process lifecycle.
- Use Kanban for durable, multi-worker coordination.

## Hermes profile lanes for model-specific workers

When the user wants different GPT/Codex models for different agent roles, prefer a separate Hermes profile lane over native `delegate_task`: current native subagents generally inherit the parent model, while profiles can carry their own `model.provider`, `model.default`, memory settings, SOUL.md, and tool-output limits.

Pattern for a read-only code-review lane:

1. Create a profile cloned from default when credentials/config should carry over:
   ```bash
   hermes profile create code-review --clone --description "Read-only coding review worker..."
   ```
2. Set the lane model/provider and reduce context/memory overhead:
   ```bash
   hermes --profile code-review config set model.provider openai-codex
   hermes --profile code-review config set model.default <review-model>
   hermes --profile code-review config set memory.memory_enabled false
   hermes --profile code-review config set memory.user_profile_enabled false
   hermes --profile code-review config set agent.max_turns 80
   hermes --profile code-review config set tool_output.max_bytes 18000
   hermes --profile code-review config set tool_output.max_lines 500
   hermes --profile code-review config set compression.threshold 0.5
   ```
3. Give the worker a role-specific `SOUL.md`: read-only, no commits/push/deploy, no secrets, compact review, no final health/finance/trading/architecture decisions.
4. Add a small wrapper such as `jarvis-code-review <repo-path> [task]` that collects bounded `git status`, `git diff --stat`, and a capped full diff, then runs:
   ```bash
   hermes --profile code-review chat --toolsets terminal,file --max-turns 40 -q "$PROMPT"
   ```
5. Treat worker output as advice. The main JARVIS/profile must verify diffs/tests and make the final decision.

Pitfall: `hermes profile create --no-skills` is mutually exclusive with `--clone`; if cloning credentials/config, clone first and then reduce the worker's prompt/memory/tool footprint via config/SOUL.md rather than trying to create a clone without skills.

## Preserved source details

Full absorbed source skills are preserved in `references/absorbed-*.md` for CLI-specific flags, prompt examples, and pitfalls.