Role Creator

Overview

Use this skill when the user wants to create, update, or troubleshoot custom subagent roles backed by [agents.<role>] and a role config_file.

This skill installs the role into ~/.codex/config.toml (or a user-selected project config), writes the role-specific config file, and validates key support against codex-rs/core/config.schema.json.

Default behavior is strict-minimal: configure only model, model_reasoning_effort, and developer_instructions unless the user explicitly asks for additional parameters.

Default location is ~/.codex/config.toml however, if the user asks for a project scoped role, the role will be installed in the project's .codex/config.toml. Can also be installed to subfolders in a repo.

Non-Negotiable Inputs

Step 1 must always be input collection. Before running any write/install/validate command, collect and confirm:

• model
• model_reasoning_effort
• developer_instructions
• install scope (global or project)
• role_name
• description
• role_config_file (absolute path preferred)

Ask concise questions:

1. Which model should this role use? (recommend: gpt-5.3-codex)
2. What reasoning effort should it use? (recommend: medium; options medium|high|xhigh)
3. What should the role's developer instructions prioritize? (goal, boundaries, success criteria)
4. Do you want this installed globally (~/.codex/config.toml) or in a project (.codex/config.toml)?
5. Do you want any sandboxing, web_search, MCP, or other restrictions?
6. What role name and description should be shown in spawn_agent?

Execution gate:

• Do not infer missing required values.
• Do not start Step 2 (writing files) until all required inputs above are explicitly provided or explicitly accepted as defaults by the user.

Default Policy For Optional Parameters

• Do not set sandbox flags unless explicitly requested.
• Do not set web_search unless explicitly requested.
• Do not set MCP flags/entries unless explicitly requested.
• Do not add any other optional config_file keys unless explicitly requested.
• If user intent is ambiguous, ask a short clarification question before adding optional keys.

Knowledge vs Application Rule

The role creator must know the full configuration surface area, but must only apply keys the user asked for.

• Required behavior:
• Explain available optional categories when helpful.
• Provide specific examples/templates when user asks what is possible.
• Keep generated config minimal by default.
• Add optional keys only with explicit user request.
• If user says "keep defaults/inherit", omit optional keys rather than setting explicit values.

Role Config Surface Area (What Can Be Customized)

Role config_file is parsed as a full config layer. If a key is omitted, it generally inherits from the parent.

• Model and reasoning:
• model
• model_reasoning_effort
• model_reasoning_summary
• model_verbosity
• personality
• Core behavior:
• developer_instructions
• Sandboxing and permissions:
• sandbox_mode
• [sandbox_workspace_write] fields like network_access, writable_roots
• Web search:
• web_search (disabled|cached|live)
• Feature toggles:
• [features] keys such as memory_tool, shell_tool
• MCP servers:
• [mcp_servers.<name>] entries (enabled, required, command, args, env_vars)
• Apps/connectors:
• [apps.<name>] entries (enabled)

When user asks for advanced role controls, use concrete examples from:

• templates/minimal-role-config.toml
• templates/restricted-role-config.toml
• templates/full-role-config.toml
• templates/frontend-architecture-role.toml

Supported Role Declaration Keys

For [agents.<role_name>], only these keys are supported:

• description
• config_file

Do not add anything else under [agents.<role_name>].

Workflow

1. Collect and confirm required inputs (hard gate).

• Ask for model, reasoning, developer instructions, install scope, role name, description, and role config file path.
• Confirm whether to use defaults only if user explicitly agrees.
• Do not write files in this step.

2. Validate environment and resolved paths.

• Ensure repo schema exists: codex-rs/core/config.schema.json
• Resolve config target from scope:
• global -> ~/.codex/config.toml
• project -> <project>/.codex/config.toml

3. Create or update role config file.

• Use scripts/write_role_config.sh to write required fields.
• Add optional controls only if the user explicitly requested them.
• Optional controls supported by script:
• sandbox_mode + workspace-write settings
• web_search mode (set to disabled to prevent web search)
• MCP controls (mcp_clear, mcp_enable, mcp_disable)
• If user wants options beyond script flags (for example model_reasoning_summary, features, apps, rich MCP server definitions), start from a template under templates/ and edit manually, then run validation.
• Communicate clearly in output:
• Configured now: keys that were written
• Available but not set: relevant optional keys left to inherit

4. Install role in main config.

• Use scripts/install_role.sh.
• This writes/updates:
• features.multi_agent = true
• [agents.<role_name>] description/config_file
• Additive safety:
• Installer only mutates role-related keys and keeps the rest of config.toml intact.
• Installer always creates a timestamped backup of the target config.toml before writing.
• Existing role definitions are not overwritten unless --update-existing is passed.

5. Validate before reporting success.

• Use scripts/validate_role.sh.
• Confirm required role-config fields are present.
• Confirm role declaration keys are only description/config_file.
• Confirm top-level role config keys are valid against schema.

6. Share runnable spawn example.

• Example:

json
1{"agent_type":"<role_name>","message":"<task>"}

Commands

bash
1# 1) Write role config file (required fields only; default behavior)
2.codex/skills/role-creator/scripts/write_role_config.sh \
3  --output ~/.codex/agents/researcher.toml \
4  --role-name researcher \
5  --model gpt-5.3-codex \
6  --reasoning medium \
7  --developer-instructions "Research code and docs only; no edits; return file:line evidence."
8
9# 1b) Optional controls (only when explicitly requested)
10.codex/skills/role-creator/scripts/write_role_config.sh \
11  --output ~/.codex/agents/researcher.toml \
12  --role-name researcher \
13  --model gpt-5.3-codex \
14  --reasoning medium \
15  --developer-instructions "Research code and docs only; no edits; return file:line evidence." \
16  --sandbox-mode workspace-write \
17  --network-access false \
18  --writable-roots "/home/willr/Applications/codex1" \
19  --web-search disabled
20
21# 2) Register role in ~/.codex/config.toml
22.codex/skills/role-creator/scripts/install_role.sh \
23  --role-name researcher \
24  --description "Read-only codebase research specialist" \
25  --role-config-file ~/.codex/agents/researcher.toml
26
27# 2b) Intentionally update an existing role definition
28.codex/skills/role-creator/scripts/install_role.sh \
29  --role-name researcher \
30  --description "Updated role description" \
31  --role-config-file ~/.codex/agents/researcher.toml \
32  --update-existing
33
34# 3) Validate role config and declaration keys
35.codex/skills/role-creator/scripts/validate_role.sh \
36  --role-name researcher \
37  --config ~/.codex/config.toml \
38  --role-config ~/.codex/agents/researcher.toml \
39  --schema /home/willr/Applications/codex1/codex-rs/core/config.schema.json

Guardrails

• If runtime returns unknown agent_type, verify role exists in active config and config_file path exists/readable.
• If runtime returns agent type is currently not available, inspect role file TOML validity and unsupported keys.
• Keep instructions role-specific and operational (scope, do/don't, deliverable format).
• Do not claim success without running validation.

References

• Role key matrix and runtime behavior: references/role-config-reference.md
• Reusable templates: templates/