English | 简体中文

codex-cto-agent-team

A reusable CTO team skill with Codex integration, host capability guidance, five product managers, and fifty engineers. The CTO gives work to the team and makes cross-team decisions. Product managers (PMs) divide tasks and review results. Engineers return outputs and evidence. Use it across projects with private task records, explicit permissions, and one writer for each shared resource.

Install · Use · Model routes · Private state

Organization

flowchart TD
    CTO["CTO · Intake, coordination, final delivery"]
    CTO --> PM01["PM01 · Product and interaction"]
    CTO --> PM02["PM02 · Services and data"]
    CTO --> PM03["PM03 · Systems and devices"]
    CTO --> PM04["PM04 · Automation and integration"]
    CTO --> PM05["PM05 · Quality and release"]
    PM01 --> CS01["CS0101–CS0110 · 10 engineer roles"]
    PM02 --> CS02["CS0201–CS0210 · 10 engineer roles"]
    PM03 --> CS03["CS0301–CS0310 · 10 engineer roles"]
    PM04 --> CS04["CS0401–CS0410 · 10 engineer roles"]
    PM05 --> CS05["CS0501–CS0510 · 10 engineer roles"]

The full roster has 56 roles, including the current CTO chat. A role definition does not make a chat. A created chat, a READY reply, and active computation are different states. Chat count does not establish simultaneous computing capacity or permanent availability. Use only roles that help the current task. Engineer specialties guide assignment and permit suitable work outside a title.

Install

Use a host that can load the skill or accept its instructions manually. The local helpers require Python 3.11 or later and only the standard library. The installation commands below are for Codex. See the host matrix for Claude Code, Cursor, and generic/cloud boundaries. Those integrations have documented guidance, not live client validation or universal native adapters. Chat creation, task messages, and monitoring require supported tools and account capacity. This skill does not add those capabilities.

1. Get this repository.
2. Make a copy of the complete skills/cto-agent-team folder in your personal skill directory.
3. Keep its scripts, references, assets, and agents folders.
4. Select cto-agent-team in Codex. If it is absent, restart Codex.

PowerShell example for a personal installation:

git clone https://github.com/StochasticResult/codex-cto-agent-team.git
Set-Location codex-cto-agent-team
$skillSource = Join-Path (Get-Location) 'skills/cto-agent-team'
$skillTarget = Join-Path $env:USERPROFILE '.agents/skills/cto-agent-team'
if (Test-Path -LiteralPath $skillTarget) { throw 'The target exists. Review it before updating.' }
New-Item -ItemType Directory -Path (Split-Path -Parent $skillTarget) -Force | Out-Null
Copy-Item -LiteralPath $skillSource -Destination $skillTarget -Recurse

For a project installation, use .agents/skills/cto-agent-team in that project. See the official skill documentation. Third-party skills are separate dependencies. Installing this repository does not install them or prove that any chat has read them.

Use

Open a CTO chat in the target project. Select the skill or use $cto-agent-team in your request. For a plan, use:

Use $cto-agent-team to plan the work for <GOAL>. Give the task owners and acceptance criteria. Do not make chats.

For a full organization of independent chats, use:

Use $cto-agent-team for <PROJECT>. Use the current chat as CTO. Make five PM chats and ten engineer chats per PM. Use suitable existing chats. I permit creation of missing chats. I permit CTO-to-PM and PM-to-engineer task messages for this project. Keep private state in <PRIVATE_STATE_DIR>. Use the available tools and account capacity. Give actual creation and READY results.

Replace the placeholders before use. Skill selection alone does not authorize chat creation or task messages. For a general request to use agents, follow existing authorization and tool support, or prepare a plan. For independent chats, discover the current host tools and verify the target project before authorized creation. Host adapters contain specific tool names and parameter boundaries. Examine unknown creation results before another attempt. Reuse real chat identifiers from supported tools.

Each task must identify its target, permissions, outputs, acceptance criteria, and writable resources. Organizational delegation does not grant permission for every device, publication, external message, or purchase. Read the target project's AGENTS.md. Make sure that the device identity, connection, and task permission are correct.

PMs read engineer results in shared private events. One designated clerk writes the shared summary. The CTO reads that summary and necessary exact source references. Canonical tasks remain authoritative. Use messages only for necessary authorized dispatch, continuation, or recovery, with task and document pointers. Active recipients read at safe boundaries. Do not send routine progress or result relay messages. See workflow.md for complete handoffs and result collection.

Model routes

Separate task requirements, host capabilities, model evidence, user policy, native parameters, and actual execution. The following table is the explicit compatibility-6.1 profile. It is not a default for every host or an availability claim:

Within approved escalation scope, conflicting constraints, critical decisions, complex state, and substantive acceptance failures can require Sol/xhigh. For ambiguity in extraction, first use Terra/high. Complex analysis can require Sol/high or Sol/xhigh. User policy can authorize automatic routing and evidenced new candidates within existing resources. Respect explicit pins and hard budgets. A new name alone does not require repeated approval within that authority. Capacity failure never authorizes silent substitution.

Role-registration defaults are Sol/high for PMs and Terra/high for engineers. They do not establish any chat's actual settings. For each authorized dispatch, pass the exact supported native parameters. Record the request and tool outcome privately. Tool acceptance does not independently verify the backend model. Apply new routes on the next authorized dispatch. Do not interrupt active work or wake idle engineers merely to change settings. Keep the CTO's current settings, speed, subscription, and budget intact. See model-routing.md.

The standard-library selector evaluates configurable evidence and returns a payload without sending it. Try the credential-free fixture from the installed skill directory:

python scripts/model_route.py assets/routing.example.json --now 2030-01-02T00:00:00Z

The result is explicitly a fixture, with dispatch_ready: false. For actual work, replace synthetic evidence and use the current time. Use the seven-part schema, private policy/catalog inputs, and an explicit profile. --escalate-from requires substantive failure and prior outcome evidence, and permits at most two quality upgrades. --retry-from preserves the verified original native request and quality history, even when the normal catalog is stale. A pin, unknown capability, unsupported parameter, or unsatisfied budget blocks selection. Unknown costs do not establish savings. Different vendor effort/speed parameters are not synonyms. See the selector guide. Documentation, account availability, permission, fixture/configuration, request acceptance, and actual execution are separate evidence levels.

Delivery and supervision

Give each independent request a unique task ID and an owning PM. Send a complete handoff and end the CTO turn promptly. PMs continue implementation, review, and authorized delivery. Shared events retain results and next actions. New requests preserve earlier open tasks. Link changes and cancellations to the original task. Assign useful independent work in parallel within actual capacity. After an item completes, examine its evidence. Then give the next ready item to a suitable engineer. Record the reason for a necessary serial step. Keep one writer for each shared file, device, desktop, or live operation.

Use a suitable agent for routine supervision through its authorized route. The compatibility profile retains Luna/low. Read back supported monitor settings or documented model inheritance. Keep that evidence. A model name in a prompt does not set the monitor model. Report unsupported settings accurately. Reuse existing supervision and saved cursors. Keep unchanged checks and ordinary retries quiet. Do not add a high-cost CTO loop to watch the supervisor.

A completion candidate must match the task and result revision. It must include output and acceptance evidence