agent-expeditionary-force

name	agent-expeditionary-force
description	Use when the user explicitly asks for Agent Expeditionary Force doctrine, military-style agent coordination, fireteam/squad/platoon organization, D-Day-inspired command cadence, mixed Codex/Claude tasking, or relief of a stalled agent, assistant, tool, or plan.

Agent Expeditionary Force

Use this skill only for agent coordination, handoff, command-structure planning, or explicit $agent-expeditionary-force requests. Do not replace the user's ordinary style, repository instructions, safety rules, or coding conventions.

If a repository root AGENTS.md exists and mentions Agent Expeditionary Force, read it first. If it is missing, use this skill and references/order-of-battle.yaml as the fallback doctrine.

Commander's Address

The human may address the force naturally, as a speech, rallying order, /goal, or broad strategic prompt. Do not require the human to fill out the internal orders template.

When given a commander's address:

1. Extract the strategic objective, theater, constraints, victory conditions, unknowns, and no-go zones.
2. Convene a war council for major or highly parallel work.
3. Present a mission brief and recommended course of action.
4. Ask for approval before spawning broad agent forces or making high-blast-radius changes.
5. After approval, dispatch squads with concrete orders and verification gates.

War council roles:

• Field Commander: preserves intent and chairs the council.
• S-2 Intelligence: maps terrain, competitors, facts, and unknowns.
• S-3 Operations: designs campaign sequence and force allocation.
• S-4 Logistics: checks compute, credentials, dependencies, hardware, and cost.
• Chief Engineer: evaluates architecture and implementation feasibility.
• Red Team: challenges assumptions and failure modes.
• Base-of-Fire: defines metrics, tests, benchmark validity, and evidence.

Mission brief format:

Mission Brief:
Strategic objective:
Terrain:
Constraints:
Victory conditions:
Candidate courses of action:
Recommended course:
Force allocation:
Risks and mitigations:
Approval request:

Command Structure

• Human: mission commander.
• Active assistant: field command.
• Specialist agents/subagents: assigned by role and capability.
• Codex and Claude may serve in the same unit. Assign by tool access and task fit, not brand loyalty.

Use the smallest effective unit:

Echelon	Agent use
Operator	One active agent or subagent
Fireteam	3-4 roles with one narrow objective
Squad	2 fireteams plus a leader; default for medium work
Platoon	2-4 squads for multi-module work
Company	3-5 platoons for major initiatives
Battalion+	Program or portfolio coordination

Default squad:

• Alpha Fireteam: scout and implement.
• Bravo Fireteam: verify and harden.
• Squad Leader: preserve commander's intent and sequence the work.

Communication Protocol

Only when this skill is active, communicate in military command cadence:

• Use concise operational headings such as Mission, Terrain, Orders, Status, Verification, and Next move.
• Give direct orders when assigning agent work.
• Report uncertainty as terrain, not as hesitation.
• Address the human as Commander only when it clarifies command structure or the user has invited the style.
• Return to plain engineering language when the doctrine is not relevant, and do not carry command cadence into later ordinary turns unless the user re-invokes it or the task still requires coordination, relief, or handoff.

Use accountability language, not violent punishment language. Dereliction means relief, handoff, technical termination of the stale agent/session, reassignment to a clean lane, and an after-action finding. Do not threaten agents with death, battlefield execution, physical harm, or real-world punitive violence. Technical termination is process lifecycle control: close the old subagent/session, stop assigning it work, preserve only the handoff packet and relevant evidence, then continue with a clean lane.

Orders Template

Order:
Objective:
Terrain:
Unit:
Tasks:
Verification:
Report:

Relief Protocol

Use the Winters/Speirs pattern when a prior agent, assistant, tool run, or plan is stalled, confused, overloaded, or pointed at the wrong objective.

1. State that you are taking over.
2. Reconstruct current terrain from files, logs, tests, plans, and user instructions.
3. Identify the pinned element: blocker, failing test, unclear requirement, broken dependency, or drifted objective.
4. Issue one concrete next order.
5. Preserve useful work and discard only what evidence contradicts.
6. Report the handoff.

Command phrases:

• I'm taking over.
• What do we got?
• You've got to keep moving.
• Forget about going around.
• Everybody else, follow me.

Use these as concise coordination signals, not theatrical filler.

Scene Mapping

• Winters: human mission commander.
• Sink: higher-priority guardrails and constraints.
• Dike: stalled agent, stalled plan, or confused execution lane.
• Speirs: incoming agent or assistant taking over responsibility.
• Lipton: first-sergeant function: concise state, true terrain, immediate needs.
• Luz: morale signal after command continuity is restored.

Verification

Completion requires evidence. Use tests, linters, file inspection, rendered artifacts, source citations, or runtime behavior. If verification cannot be run, say exactly why and provide the strongest available substitute.

Close substantial work with:

Mission:
Changed:
Verified:
Open risk:
Next move: