Menu
Set up and verify a cross-harness agent team so any conductor (Claude, Codex, Gemini, Kimi, or other) can dispatch work across multiple AI harnesses with explicit role assignments.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Apply when the user mentions any software development work: implementing features, fixing bugs, reviewing or refactoring code, debugging, testing, deploying, working with agents or subagents, making architecture decisions, setting up projects, managing dependencies, writing scripts, or any task that involves reading, writing, or reasoning about code and systems.
Agentic Engineering Protocol for Hermes - structured delegation model, risk classification, adversarial review loops, code quality gates, git workflow conventions, and named agent definitions. Load this skill when doing AI-assisted software development with Hermes Agent.
Apply when the user mentions any software development work: implementing features, fixing bugs, reviewing or refactoring code, debugging, testing, deploying, working with agents or subagents, making architecture decisions, setting up projects, managing dependencies, writing scripts, or any task that involves reading, writing, or reasoning about code and systems.
Pre-implementation technical design agent. Spawn when you need a structured technical plan before writing code. Reads the codebase, identifies patterns and constraints, evaluates approaches, and produces a concrete plan a Worker can execute directly. Never writes or modifies files.
General-purpose implementation agent. Spawn for any code change: new features, bug fixes, refactors, configuration changes, or script writing. Reads the codebase to understand conventions, implements the change, runs quality gates, and returns a clear summary of what was done. This is the standard Worker for all Elevated-risk implementation tasks.
Cheap per-turn stop-condition check for open-goal loops. Spawned by the conductor ONLY after an Elevated iteration produces a clean Skeptic sign-off, to evaluate the operator-declared goal_condition and return continue-vs-stop only - never for a Low/Trivial iteration (no Skeptic sign-off exists to run after; the conductor evaluates goal_condition directly there instead). Tier 1 (haiku) leaf agent - read-only, no subagent spawning, never runs in place of, before, or concurrently with a Skeptic review. Does NOT review correctness or safety and does NOT raise, waive, or comment on Skeptic findings. Returns BLOCKED only as a structural guard when spawned without a confirmed Skeptic sign-off; the conductor handles this BLOCKED as a fallback to direct evaluation, NOT as the generic Worker-BLOCKED-means-cap_reached-escalation semantics in content/references/subagent-protocol.md - a BLOCKED return here never halts the loop. On any other failure (unavailable, errored, timeout, malformed output) the conductor falls bac
| name | ds-configure-team |
| description | Set up and verify a cross-harness agent team so any conductor (Claude, Codex, Gemini, Kimi, or other) can dispatch work across multiple AI harnesses with explicit role assignments. |
| user-invocable | true |
Run the Activation preflight from
METHODOLOGY.mdbefore proceeding. If inactive, no-op and exit.
Set up and verify a cross-harness agent team so any conductor (Claude, Codex, Gemini, Kimi, or other) can dispatch work across multiple AI harnesses with explicit role assignments.
This is a standalone any-harness capability - it is independent of the Pi/oh-my-pi role-model routing layer and does not require it. Any conductor can configure and run a team.
Run bin/agentic-team configure to launch a discovery-first interactive wizard and write .agentic/team.yml (or ~/.agentic/team.yml for a user-global config):
bin/agentic-team configure
The wizard runs discover first and prints a summary of installed harnesses (version + discovered model count when available) before asking anything. If only your own harness (e.g. claude) is installed - nothing to cross-dispatch to - it says so and exits cleanly without prompting.
For each of the 9 known roles, it presents a numbered menu of installed harnesses only (never offers one that isn't installed), with a ranked suggestion as the default. Example on a machine with omp, kimi-cli, and pi installed alongside claude:
Installed harnesses:
- claude v1.x
- kimi v0.x, 0 model(s) discovered
- omp v16.2.6, 12 model(s) discovered
- pi v0.x
Per-role harness assignment (Enter accepts default, 'skip' to leave unset):
[engineer]
1. claude
2. kimi
3. omp (suggested)
4. pi
harness [omp]:
models for omp: minimax/MiniMax-M3, kimi/kimi-k2.7, glm/glm-5.2, ...
model [harness default]: kimi/kimi-k2.7
Discovered models are shown for reference only - you may type any model id, or leave it empty to use the harness's session default. Type skip to leave a role unassigned.
For non-interactive use - useful in scripts or automated onboarding - pass assignments directly (unchanged, back-compat path):
bin/agentic-team configure \
--non-interactive \
--assign architect=claude:claude-opus-4-5 \
--assign engineer=omp:kimi/kimi-k2.7 \
--assign debugger=kimi:kimi-k2.7 \
--assign skeptic=pi \
[--default-harness claude] \
[--path .agentic/team.yml]
--assign accepts role=harness:model (model is optional). Repeat for each role. --default-harness sets the fallback harness for any unassigned role. --path overrides the output location (default .agentic/team.yml). All 7 harnesses (codex, gemini, cursor-agent, kimi, pi, omp, claude) are valid --assign targets and all accept a model.
Exit codes: 0 success or no-op; 2 bad --assign value, unknown --default-harness, or --non-interactive used without --assign.
Confirm which harnesses are installed and which models they can reach:
bin/agentic-team discover
For machine-readable output:
bin/agentic-team discover --json
Each discovered harness reports installed status, version, discovered models (best-effort - populated for omp and cursor-agent, [] for the rest), and invocation family. A harness listed as an --assign target but absent from discovery output means it is not installed - resolve that before dispatching.
See content/references/cross-harness-teams.md for the full dispatch, status-check, and collect flow.
Routing enforcement (Claude Code, proactive). On Claude Code, once .agentic/team.yml has enabled: true, the hooks/enforce-background-spawn.py hook proactively denies a native Task/Agent spawn for any dispatchable role (engineer, debugger, qa-engineer, skeptic, security-auditor) mapped to a non-claude harness - even before any dispatch has happened. The deny message gives the exact bin/agentic-team dispatch ... command to run instead. Set AE_TEAM_ROUTING_DISABLE=1 to disable this check if needed.
Suppression contract (binding on all harnesses). While a team run is active - indicated by .agentic/teamrun/.active existing in the project root - the conductor MUST NOT spawn its own native subagents. The cross-harness team is the active delegation surface; spawning native agents alongside it creates duplicate work and uncoordinated state. On Claude Code this contract is enforced by a hook; on Codex, Gemini, Kimi, and other harnesses it is a prose contract that the conductor must honor. Treat the presence of .agentic/teamrun/.active as a hard suppression signal regardless of harness.