---
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.

## Named Codex-Spark worker verification and bounded red-test routing

When the user explicitly names a lightweight worker/model, prove the requested lane exists before describing it as used. For the established JARVIS lane, use this sequence:

1. Inspect `command -v jarvis-code-worker` and `hermes profile list`; verify the chosen profile actually reports the requested model (for example `gpt-5.3-codex-spark`).
2. Read the wrapper before invocation. Confirm it forbids commits, pushes, deploys, credential reads, and production actions.
3. Give the worker a disjoint, bounded task such as creating **red synthetic contract tests only**. State exact paths it may edit, runtime files it must not touch, and the expected failing assertions.
4. Start the worker as a tracked background process and wait for its real exit report. Do not call an inherited native delegation a named model-worker.
5. Inspect the changed files and rerun the worker's focused test command yourself before implementing against the new contract.

This is especially useful for health-dashboard work: use Spark for a narrow synthetic test slice; retain API contract choices, security semantics, implementation, final review, commit, push, and deployment with JARVIS.

## Iteration-capped worker closure discipline

When a named worker reaches an iteration/tool ceiling during a release sprint, treat that as an execution outcome — never as a reason to reopen architecture, API contracts, or broad discovery.

1. Freeze the accepted contract surface before resuming a worker; state the exact files and behaviors it must not alter.
2. Resume a prior worker session at most once when the user explicitly authorizes it. Give it one vertical, observable acceptance slice and a small test cap.
3. Require an early implementation checkpoint: changed paths plus one focused test. If no code/test progress occurs, stop it; do not repeatedly prompt or re-dispatch the same investigation loop.
4. Earlier-layer green tests do not approve a requested browser E2E slice. The requested E2E evidence remains a release blocker until actually exercised.
5. If the slice cannot complete without changing frozen contracts, report the concrete blocker (file, test, assertion) rather than expanding scope.
6. Keep release permissions independently scoped: a later “do not deploy” overrides any earlier deployment approval. A prior push approval remains usable only if the current user direction does not withdraw it and every requested gate is actually green.
7. Syntax checks, static diffs, and API contracts are not substitutes for a requested controlled browser E2E run; do not call a sprint ready, commit, push, or deploy on that basis.
8. Do not turn an internal worker failure, partial green result, review finding, or identified follow-up into a terminal user response. Continue the authorized sprint in the main agent until the explicit acceptance checklist is satisfied. Use a final response only for verified completion or a genuine external authorization/domain-decision blocker; in the latter case, ask exactly one concrete question.
9. Preserve passing gates: do not rerun an already-green test slice unless a modified file directly affects it. Run new/directly affected tests first; reserve each requested complete suite for its one final release-gate execution.

## Synthetic-server environment isolation at release gates

Browser acceptance often needs a synthetic local server with test-only environment variables. Keep those variables process-local to the server command; never export them into the parent shell or reuse them for the Python suite. Before a Python release gate, stop every synthetic server and run pytest in a scrubbed environment that unsets at least `HEALTH_DASHBOARD_TEST_INSTANCE_ID`, `HEALTH_DASHBOARD_ACTION_INBOX`, `HEALTH_DASHBOARD_TEST_URL`, `HEALTH_DASHBOARD_DB`, and `HEALTH_DASHBOARD_API_TOKEN_FILE`.

If a full suite fails during module import because a synthetic-instance guard sees stale environment state, first rerun only the named failures in that scrubbed environment. Do not weaken the server's fail-closed guard or edit many legacy tests. If the focused failures pass, invalidate the contaminated full-suite attempt and run the complete suite once in the same clean environment. Record the contamination and the clean rerun in release evidence.

## Health and regulated-domain delegation boundary

Do not hand a broad end-to-end health, finance, security, migration, or production-write sprint to an external coding agent, even when the CLI is capable of editing the whole tree. This creates superficially complete implementations whose domain semantics can be wrong—for example conflating a source classification with personal tolerance, turning missing nutrients into zero, inventing traffic-light meaning, or weakening an action-worker boundary.

For regulated work:

1. The main agent first freezes public JSON shapes, missingness rules, medical wording, action decisions, database ownership, migration/rollback semantics, and release gates.
2. Delegate only disjoint mechanical slices: CSS, fixture rows, a red synthetic test, formatting, static analysis, or a narrowly specified renderer that cannot redefine semantics.
3. Keep API contracts, CSRF/session logic, queue/worker validation, idempotency, schema migration, medical score definitions, privacy decisions, and deployment in the main agent.
4. If a worker nevertheless touches a regulated boundary, treat its result as an untrusted draft. Review every changed contract and mutation path before running broad suites; do not repair it through repeated broad prompts.
5. Allow at most one tightly scoped correction prompt after review. Further semantic findings become main-agent edits or a concrete blocker—not another expansive autonomous pass.

## 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.

Pitfall: do not claim to be using a specific lightweight model lane such as `codex-spark`/`codex-5.3` unless that worker/profile is actually configured and invoked. Native `delegate_task` children may inherit the parent model; for simple-task routing, create a dedicated profile/wrapper and report whether it was really used.

## Default routing for lightweight profile workers

When a dedicated lightweight coding quota/profile exists, use it proactively rather than merely documenting it. Route small, bounded, low-risk mechanical work through the profile wrapper by default:

- focused unit/regression tests;
- lint/type/format fixes;
- small local bug fixes with an explicit file scope;
- bounded refactors and docs/changelog drafts;
- test/build-log root-cause analysis.

Keep the main JARVIS on planning, architecture, health/finance/trading safety decisions, privacy/security boundaries, final diff/test verification, commits, pushes, deploys, and production actions. For high-risk tasks, finish the current safety review coherently rather than switching executors mid-review; apply lightweight routing to the next clearly bounded coding block.

Important accounting nuance: a worker may not reduce total tokens, but it shifts mechanical loops to a separate quota and keeps the expensive main-session context smaller. Report whether the profile wrapper was actually invoked. A native `delegate_task` is not proof of lightweight-model use because children normally inherit the parent model. If the user explicitly requests a named lightweight lane (for example Codex Spark), check for and invoke the configured profile/wrapper first. If it is unavailable, state that limitation before dispatching native subagents; never describe inherited-model delegation as the requested lightweight worker.

For parallel frontend/backend work, write the shared DOM/data contract before dispatch (selectors, IDs, JSON shape, ownership boundaries). Otherwise worker assets and the main renderer can both be correct but incompatible, forcing expensive integration rework. Give each worker disjoint files and keep contract integration with the main architect.

Example profile-wrapper routing:

```bash
jarvis-code-worker <repo> "Add focused regression tests for the strict date parser; no unrelated changes"
jarvis-test-analyze <repo> "Run and summarize only the relevant failing suite"
jarvis-pr-draft <repo> main
```

The main agent must read the resulting diff, rerun acceptance checks, and own every side effect.

## Preserved source details

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