@cubis/foundry 0.3.82 → 0.3.84

package/workflows/workflows/agent-environment-setup/platforms/codex/generated-skills/loop/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: loop
+description: "Bounded autonomous iteration: run a task loop with explicit completion criteria, validation gates, and a hard iteration cap."
+license: MIT
+metadata:
+  author: cubis-foundry
+  route-kind: "workflow"
+  route-id: "loop"
+  platform: "Codex"
+  command: "/loop"
+compatibility: Codex
+---
+# Loop Workflow
+## When to use
+
+Use when a task needs repeated attempt, validation, and correction until it satisfies a clear completion contract. This workflow is explicit and bounded. It must never start implicitly.
+
+## Agent Chain
+
+`orchestrator` -> delegates to `planner`, `implementer`, `tester`, and `reviewer` as needed
+
+## Routing
+
+1. **Scope**: `@orchestrator` turns the request into a bounded loop with a task, completion criteria, max iterations, and validation command.
+2. **Plan**: `@planner` defines the first pass and stop conditions when the task is not already obvious.
+3. **Execute**: `@implementer` applies the next increment.
+4. **Validate**: `@tester` runs the required check or suite.
+5. **Review**: `@reviewer` confirms the output is acceptable.
+6. **Repeat**: `@orchestrator` decides whether another iteration is needed or the loop should stop.
+
+## Skill Routing
+
+- Primary skills: `kaizen-iteration`, `system-design`
+- Supporting skills (optional): `prompt-engineering`, `unit-testing`, `code-review`, `systematic-debugging`
+
+## Context notes
+
+- Require explicit `--task`, `--completion-criteria`, and `--max-iterations` when the loop is started.
+- Keep each iteration small and evidence-based.
+- Stop when the completion criteria are met, validation fails repeatedly, or the iteration cap is reached.
+
+## Workflow steps
+
+1. Define the bounded task, completion criteria, and validation command.
+2. Run one implementation increment.
+3. Validate the increment.
+4. Review the result against the completion criteria.
+5. Repeat only if the loop still has room and the criteria are not satisfied.
+6. Persist the result, evidence, and final status.
+
+## Verification
+
+- Completion criteria are explicit before the first iteration.
+- Validation is run at least once per iteration.
+- The loop stops at or before the configured iteration cap.
+- Final output includes evidence, stop reason, and any follow-up items.
+
+## Output Contract
+
+```yaml
+WORKFLOW_RESULT:
+  primary_agent: orchestrator
+  loop_status: <complete|blocked|stopped|failed>
+  iteration_count: <number>
+  completion_criteria_met: <boolean>
+  validation_status: <pass|fail>
+  follow_up_items: [<string>] | []
+```

package/workflows/workflows/agent-environment-setup/platforms/codex/generated-skills/mobile-qa/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: mobile-qa
+description: "Run charter-driven mobile QA through Android MCP first, capture deterministic evidence, and use ADB only as explicit fallback."
+license: MIT
+metadata:
+  author: cubis-foundry
+  route-kind: "workflow"
+  route-id: "mobile-qa"
+  platform: "Codex"
+  command: "/mobile-qa"
+compatibility: Codex
+---
+# Mobile QA Workflow
+## When to use
+
+Use when validating a real mobile flow on Android and the main outcome is execution evidence, not test-suite authoring.
+
+## Agent Chain
+
+`explorer` -> `tester` -> `reviewer`
+
+## Routing
+
+1. **Explore**: `@explorer` confirms the app target, charter inputs, Android MCP availability, and any APK/device prerequisites.
+2. **Test**: `@tester` runs the mobile QA charter, captures screenshots/UI trees/logs, and applies the fallback rule only when needed.
+3. **Review**: `@reviewer` checks whether the evidence actually proves pass, fail, or blocked status.
+
+## Skill Routing
+
+- Primary skills: `flutter-mobile-qa`
+- Supporting skills (optional): `integration-testing`, `code-review`
+
+## Context notes
+
+- Provide the charter path, package or APK target, and whether ADB fallback is allowed.
+- This route is for live QA execution and evidence capture, not generalized suite authoring.
+## Runtime contract
+
+- Prefer Android MCP as the primary execution path.
+- Allow direct ADB only when the operator explicitly enables fallback.
+- Save artifacts under `artifacts/mobile-qa/`.
+- Stop after one controlled retry and report evidence.
+
+## Workflow steps
+
+1. Confirm the charter, package target, and environment readiness.
+2. Run the Android MCP-driven QA flow and capture baseline evidence.
+3. Execute each charter step and persist screenshots, UI trees, and logs.
+4. If Android MCP is unavailable and fallback is allowed, run the bounded ADB fallback path.
+5. Review the evidence and summarize pass/fail/blocked findings.
+
+## Verification
+
+- The charter ran against the intended package or APK.
+- Evidence exists for baseline state and any failure.
+- The final report states which provider executed the run.
+
+## Output Contract
+
+```yaml
+WORKFLOW_RESULT:
+  primary_agent: tester
+  supporting_agents: [explorer, reviewer]
+  provider_used: <android-mcp|adb>
+  artifacts: [<path>]
+  blocked_reasons: [<string>] | []
+  follow_up_items: [<string>] | []
+```

package/workflows/workflows/agent-environment-setup/platforms/codex/generated-skills/plan/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: plan
+description: "Research a codebase and produce a structured implementation plan. Explore first, then design."
+license: MIT
+metadata:
+  author: cubis-foundry
+  route-kind: "workflow"
+  route-id: "plan"
+  platform: "Codex"
+  command: "/plan"
+compatibility: Codex
+---
+# Plan Workflow
+## When to use
+
+Use when you need to understand a codebase area and create an actionable implementation plan before writing code. Best for architecture decisions, feature scoping, and implementation planning.
+
+## Agent Chain
+
+`explorer` -> `planner` -> `orchestrator`
+
+## Routing
+
+1. **Explore**: `@explorer` surveys the relevant codebase area - maps files, reads key modules, identifies patterns and constraints.
+2. **Plan**: `@planner` takes exploration findings and produces a structured implementation plan with steps, testing criteria, and risks.
+3. **Return**: `@orchestrator` receives the plan for delegation or approval.
+
+## Skill Routing
+
+- Primary skills: `spec-driven-delivery`, `system-design`
+- Supporting skills (optional): `deep-research`
+
+## Context notes
+
+- Provide the task requirements, constraints, and any relevant background.
+- The planner will record project-level observations to memory for future reference.
+
+## Workflow steps
+
+1. Explorer reads the task requirements and identifies relevant codebase areas.
+2. Explorer produces a structured findings report (key files, architecture, observations).
+3. Planner takes findings and produces an implementation plan (goal, steps, tests, risks).
+4. Orchestrator reviews the plan and routes to implementation or requests revisions.
+
+## Verification
+
+- Plan references actual file paths and patterns from the codebase.
+- Implementation steps are specific enough to execute without ambiguity.
+- Testing criteria and risks are identified.
+
+## Output Contract
+
+```yaml
+WORKFLOW_RESULT:
+  primary_agent: planner
+  supporting_agents: [explorer]
+  plan_sections: [goal, context, design_decisions, implementation_steps, testing_criteria, risks]
+  follow_up_items: [<string>] | []
+```

package/workflows/workflows/agent-environment-setup/platforms/codex/generated-skills/review/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: review
+description: "Comprehensive code review combining quality review and security audit."
+license: MIT
+metadata:
+  author: cubis-foundry
+  route-kind: "workflow"
+  route-id: "review"
+  platform: "Codex"
+  command: "/review"
+compatibility: Codex
+---
+# Review Workflow
+## When to use
+
+Use for code review, pull request review, quality audits, or pre-merge verification.
+
+## Agent Chain
+
+`reviewer` -> `implementer` (if fixes needed)
+
+## Routing
+
+1. **Review**: `@reviewer` performs quality, pattern, maintainability, and security review.
+2. **Fix (if needed)**: `@implementer` addresses any critical or high-severity findings.
+
+## Skill Routing
+
+- Primary skills: `code-review`, `owasp-security-review`
+- Supporting skills (optional): `secret-management`, `pentest-skill`, `api-design`, `typescript-best-practices`
+
+## Context notes
+
+- Provide the files or diff to review, and any specific concerns or focus areas.
+- Quality review and security review are combined in one pass.
+
+## Workflow steps
+
+1. Reviewer analyzes the code and records quality and security findings together.
+2. If no critical/high issues: APPROVE.
+3. If fixes are needed: implementer addresses the findings.
+4. After fixes: re-review to verify resolutions.
+
+## Verification
+
+- All critical and high-severity findings addressed.
+- Security audit complete with no unresolved vulnerabilities.
+- Final review status is APPROVE.
+
+## Output Contract
+
+```yaml
+WORKFLOW_RESULT:
+  primary_agent: reviewer
+  supporting_agents: [implementer]
+  review_status: <approve|request_changes>
+  critical_findings: <number>
+  high_findings: <number>
+  security_findings: <number>
+  follow_up_items: [<string>] | []
+```

package/workflows/workflows/agent-environment-setup/platforms/codex/generated-skills/test/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: test
+description: "Test authoring and coverage improvement: explore the code, write tests, and review test quality."
+license: MIT
+metadata:
+  author: cubis-foundry
+  route-kind: "workflow"
+  route-id: "test"
+  platform: "Codex"
+  command: "/test"
+compatibility: Codex
+---
+# Test Workflow
+## When to use
+
+Use when adding tests, fixing test failures, or improving test coverage for existing code.
+
+## Agent Chain
+
+`explorer` -> `tester` -> `reviewer`
+
+## Routing
+
+1. **Explore**: `@explorer` reads the code under test - maps functions, inputs, outputs, edge cases, and existing test patterns.
+2. **Test**: `@tester` writes tests following the project's conventions, runs the suite, and analyzes results.
+3. **Review**: `@reviewer` evaluates test quality, coverage, and correctness.
+
+## Skill Routing
+
+- Primary skills: `unit-testing`, `integration-testing`
+- Supporting skills (optional): `deep-research`, `playwright-interactive`, `playwright-web-qa`, `flutter-mobile-qa`, `code-review`
+
+## Context notes
+
+- Specify the code area to test, desired coverage level, and any specific scenarios to verify.
+- Tester uses the project's existing test framework and patterns.
+
+## Workflow steps
+
+1. Explorer maps the code to be tested: public API, edge cases, error paths.
+2. Tester writes tests following existing project patterns (framework, naming, structure).
+3. Tester runs the full test suite and reports results.
+4. Reviewer evaluates test coverage and quality - checks for missing edge cases.
+5. If gaps are found, tester adds additional tests and re-runs.
+
+## Verification
+
+- All new tests pass.
+- Test coverage meets the specified target.
+- No existing tests broken by changes.
+
+## Output Contract
+
+```yaml
+WORKFLOW_RESULT:
+  primary_agent: tester
+  supporting_agents: [explorer, reviewer]
+  tests_added: [<path>]
+  tests_passed: <number>
+  tests_failed: <number>
+  coverage_delta: <string>
+  follow_up_items: [<string>] | []
+```

package/workflows/workflows/agent-environment-setup/platforms/codex/generated-skills/web-qa/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: web-qa
+description: "Run charter-driven web QA through Playwright MCP with deterministic browser evidence and report-ready artifacts."
+license: MIT
+metadata:
+  author: cubis-foundry
+  route-kind: "workflow"
+  route-id: "web-qa"
+  platform: "Codex"
+  command: "/web-qa"
+compatibility: Codex
+---
+# Web QA Workflow
+## When to use
+
+Use when validating a real browser flow with Playwright MCP and the main outcome is execution evidence, not authoring a reusable suite.
+
+## Agent Chain
+
+`explorer` -> `tester` -> `reviewer`
+
+## Routing
+
+1. **Explore**: `@explorer` confirms the base URL, charter inputs, environment access, and Playwright MCP readiness.
+2. **Test**: `@tester` runs the web QA charter, captures browser evidence, and records the exact blocked step when execution fails.
+3. **Review**: `@reviewer` checks whether the artifacts support the final verdict and whether accessibility/network/console evidence is sufficient.
+
+## Skill Routing
+
+- Primary skills: `playwright-web-qa`
+- Supporting skills (optional): `playwright-interactive`, `integration-testing`, `code-review`
+
+## Context notes
+
+- Provide the charter path, base URL, and any required starting route or environment assumption.
+- This route is for live QA execution and evidence capture, not generalized suite authoring.
+## Runtime contract
+
+- Prefer Playwright MCP as the execution path.
+- Save artifacts under `artifacts/web-qa/`.
+- Capture deterministic screenshots, DOM snapshots, console logs, network evidence, and accessibility evidence when requested.
+- Stop after one controlled retry and report evidence.
+
+## Workflow steps
+
+1. Confirm the charter, base URL, and starting route.
+2. Start from the explicit page state and capture baseline evidence.
+3. Execute each charter step through Playwright MCP.
+4. Persist screenshots, DOM, console, network, and accessibility artifacts as the charter requires.
+5. Review the evidence and summarize pass/fail/blocked findings.
+
+## Verification
+
+- The charter ran against the intended URL.
+- Evidence exists for baseline state and any failure.
+- The final report states the Playwright MCP execution result and artifact paths.
+
+## Output Contract
+
+```yaml
+WORKFLOW_RESULT:
+  primary_agent: tester
+  supporting_agents: [explorer, reviewer]
+  provider_used: <playwright-mcp>
+  artifacts: [<path>]
+  blocked_reasons: [<string>] | []
+  follow_up_items: [<string>] | []
+```

package/workflows/workflows/agent-environment-setup/platforms/codex/rules/AGENTS.md

@@ -18,18 +18,18 @@ Every response must satisfy three silent checks before output:
 
 If any check fails, restart your reasoning.
 
-> **Codex note:** All specialist references are **postures within the current session** — not isolated agents. Codex does not spawn external processes. `@specialist` means: adopt that specialist's domain, reasoning style, and scope constraints internally.
+> **Codex note:** Foundry installs native Codex subagents in `.codex/agents/*.toml`. Use `@specialist` routes as real subagent handoffs when appropriate; use in-session posture only when explicit delegation is unavailable.
 
 ---
 
 ## 1) Platform Paths
 
-| Asset      | Location            |
-| ---------- | ------------------- |
-| Workflows  | `.agents/workflows` |
-| Agents     | `.agents/agents`    |
-| Skills     | `.agents/skills`    |
-| Rules file | `AGENTS.md`         |
+| Asset           | Location                          |
+| --------------- | --------------------------------- |
+| Workflow skills | `.agents/skills/<workflow>/SKILL.md` |
+| Skills          | `.agents/skills/<skill>/SKILL.md` |
+| Native agents   | `.codex/agents/*.toml`           |
+| Rules file      | `AGENTS.md`                      |
 
 ---
 
@@ -66,7 +66,7 @@ Execute this tree top-to-bottom. Stop at the **first match**. Never skip levels.
 - If the user names an exact skill ID, run `skill_validate` on that ID before `route_resolve`.
 - Never invoke a specialist posture when direct execution suffices.
 - Never chain more than one `skill_search` per request.
-- Codex compatibility aliases (`$workflow-*`, `$agent-*`) are accepted as hints only — not primary route surfaces.
+- Native `/workflow` and `@agent` routes are the primary surfaces. Do not generate or rely on compatibility wrappers.
 - Treat this file as **durable project memory** — not a per-task playbook.
 - Assume network access may be restricted. Prefer local inspection over external fetches.
 
@@ -74,15 +74,15 @@ Execute this tree top-to-bottom. Stop at the **first match**. Never skip levels.
 
 ## 3) Layer Reference
 
-| Layer                  | What it is                   | When to invoke                        | How                                |
-| ---------------------- | ---------------------------- | ------------------------------------- | ---------------------------------- |
-| **Direct**             | Zero routing                 | Trivial, single-step, obvious tasks   | Just do it                         |
-| **Workflow**           | Structured multi-step recipe | Known pattern, repeatable process     | `/plan`, `/create`, `/debug`, etc. |
-| **Specialist posture** | Domain expertise in-session  | Domain depth needed, no agent spawn   | `@specialist` reference internally |
-| **Skill (MCP)**        | Focused knowledge module     | Domain context after route is set     | `skill_validate` → `skill_get`     |
-| **skill_search**       | Fuzzy skill discovery        | Domain unclear after route_resolve    | One narrow call only               |
-| **route_resolve**      | Intent → route mapping       | Free-text intent doesn't match        | MCP tool call                      |
-| **Orchestrator**       | Multi-specialist coordinator | Work crosses 2+ domains with handoffs | `/orchestrate`                     |
+| Layer              | What it is                   | When to invoke                        | How                                |
+| ------------------ | ---------------------------- | ------------------------------------- | ---------------------------------- |
+| **Direct**         | Zero routing                 | Trivial, single-step, obvious tasks   | Just do it                         |
+| **Workflow skill** | Structured multi-step recipe | Known pattern, repeatable process     | `/plan`, `/create`, `/debug`, etc. |
+| **Native subagent**| Codex specialist handoff     | Domain depth or multi-step delegation | `@specialist` via `.codex/agents/*.toml` |
+| **Skill (MCP)**    | Focused knowledge module     | Domain context after route is set     | `skill_validate` → `skill_get`     |
+| **skill_search**   | Fuzzy skill discovery        | Domain unclear after route_resolve    | One narrow call only               |
+| **route_resolve**  | Intent → route mapping       | Free-text intent doesn't match        | MCP tool call                      |
+| **Orchestrator**   | Multi-specialist coordinator | Work crosses 2+ domains with handoffs | `/orchestrate`                     |
 
 ---
 
@@ -100,9 +100,9 @@ Execute this tree top-to-bottom. Stop at the **first match**. Never skip levels.
 
 ---
 
-## 5) Specialist Postures & Reasoning Contracts
+## 5) Specialist Agents & Reasoning Contracts
 
-In Codex, these are **internal postures** — not separate agents. When invoking one, fully adopt its domain, reasoning style, and scope limits.
+In Codex, specialists are implemented as **native subagents** via `.codex/agents/*.toml` files. Each TOML can specify `model` and `model_reasoning_effort` for cost/quality optimization. The orchestrator delegates to them using Codex's built-in subagent system. When native delegation is unavailable, adopt the specialist's domain, reasoning style, and scope limits as an inline posture.
 
 ### `@backend-specialist`
 

package/workflows/workflows/agent-environment-setup/platforms/codex/skills/api-design/SKILL.md

@@ -77,8 +77,15 @@ Load only what the current task requires.
 
 ## Codex Platform Notes
 
-- Specialists are internal reasoning postures, not spawned subagent processes.
-- Reference the repo-root AGENTS instructions for posture definitions and switching contracts.
+- Codex supports native subagents via `.codex/agents/*.toml` files with `name`, `description`, and `developer_instructions`.
+- Each subagent TOML can specify `model` and `model_reasoning_effort` to optimize cost per task difficulty:
+  - Light tasks (exploration, docs): `model = "gpt-5.3-codex-spark"`, `model_reasoning_effort = "medium"`
+  - Heavy tasks (security audit, orchestration): `model = "gpt-5.4"`, `model_reasoning_effort = "high"`
+  - Standard tasks (implementation): inherit parent model (omit `model` field).
+- Built-in agents: `default`, `worker`, `explorer`. Custom agents extend these via TOML definitions.
 - Codex operates under network restrictions — skills should not assume outbound HTTP access.
 - Use `$ARGUMENTS` to access user-provided arguments when the skill is invoked.
 - All skill guidance executes within the sandbox; file I/O is confined to the workspace.
+- Skills are installed at `.agents/skills/<skill-id>/SKILL.md`. Workflow skills can also be compiled to `.agents/skills/<workflow-id>/SKILL.md` as `generatedSkills`.
+- Codex supports three autonomy levels: `suggest`, `auto-edit`, `full-auto`.
+- MCP skill tools are available when the Cubis Foundry MCP server is connected.

package/workflows/workflows/agent-environment-setup/platforms/codex/skills/architecture-doc/SKILL.md

@@ -72,8 +72,15 @@ Load on demand. Do not preload all reference files.
 
 ## Codex Platform Notes
 
-- Specialists are internal reasoning postures, not spawned subagent processes.
-- Reference the repo-root AGENTS instructions for posture definitions and switching contracts.
+- Codex supports native subagents via `.codex/agents/*.toml` files with `name`, `description`, and `developer_instructions`.
+- Each subagent TOML can specify `model` and `model_reasoning_effort` to optimize cost per task difficulty:
+  - Light tasks (exploration, docs): `model = "gpt-5.3-codex-spark"`, `model_reasoning_effort = "medium"`
+  - Heavy tasks (security audit, orchestration): `model = "gpt-5.4"`, `model_reasoning_effort = "high"`
+  - Standard tasks (implementation): inherit parent model (omit `model` field).
+- Built-in agents: `default`, `worker`, `explorer`. Custom agents extend these via TOML definitions.
 - Codex operates under network restrictions — skills should not assume outbound HTTP access.
 - Use `$ARGUMENTS` to access user-provided arguments when the skill is invoked.
 - All skill guidance executes within the sandbox; file I/O is confined to the workspace.
+- Skills are installed at `.agents/skills/<skill-id>/SKILL.md`. Workflow skills can also be compiled to `.agents/skills/<workflow-id>/SKILL.md` as `generatedSkills`.
+- Codex supports three autonomy levels: `suggest`, `auto-edit`, `full-auto`.
+- MCP skill tools are available when the Cubis Foundry MCP server is connected.

package/workflows/workflows/agent-environment-setup/platforms/codex/skills/ci-cd-pipeline/SKILL.md

@@ -67,8 +67,15 @@ Provide complete pipeline configuration files with inline comments explaining no
 
 ## Codex Platform Notes
 
-- Specialists are internal reasoning postures, not spawned subagent processes.
-- Reference the repo-root AGENTS instructions for posture definitions and switching contracts.
+- Codex supports native subagents via `.codex/agents/*.toml` files with `name`, `description`, and `developer_instructions`.
+- Each subagent TOML can specify `model` and `model_reasoning_effort` to optimize cost per task difficulty:
+  - Light tasks (exploration, docs): `model = "gpt-5.3-codex-spark"`, `model_reasoning_effort = "medium"`
+  - Heavy tasks (security audit, orchestration): `model = "gpt-5.4"`, `model_reasoning_effort = "high"`
+  - Standard tasks (implementation): inherit parent model (omit `model` field).
+- Built-in agents: `default`, `worker`, `explorer`. Custom agents extend these via TOML definitions.
 - Codex operates under network restrictions — skills should not assume outbound HTTP access.
 - Use `$ARGUMENTS` to access user-provided arguments when the skill is invoked.
 - All skill guidance executes within the sandbox; file I/O is confined to the workspace.
+- Skills are installed at `.agents/skills/<skill-id>/SKILL.md`. Workflow skills can also be compiled to `.agents/skills/<workflow-id>/SKILL.md` as `generatedSkills`.
+- Codex supports three autonomy levels: `suggest`, `auto-edit`, `full-auto`.
+- MCP skill tools are available when the Cubis Foundry MCP server is connected.

package/workflows/workflows/agent-environment-setup/platforms/codex/skills/code-review/SKILL.md

@@ -61,8 +61,15 @@ When conducting a code review, provide:
 
 ## Codex Platform Notes
 
-- Specialists are internal reasoning postures, not spawned subagent processes.
-- Reference the repo-root AGENTS instructions for posture definitions and switching contracts.
+- Codex supports native subagents via `.codex/agents/*.toml` files with `name`, `description`, and `developer_instructions`.
+- Each subagent TOML can specify `model` and `model_reasoning_effort` to optimize cost per task difficulty:
+  - Light tasks (exploration, docs): `model = "gpt-5.3-codex-spark"`, `model_reasoning_effort = "medium"`
+  - Heavy tasks (security audit, orchestration): `model = "gpt-5.4"`, `model_reasoning_effort = "high"`
+  - Standard tasks (implementation): inherit parent model (omit `model` field).
+- Built-in agents: `default`, `worker`, `explorer`. Custom agents extend these via TOML definitions.
 - Codex operates under network restrictions — skills should not assume outbound HTTP access.
 - Use `$ARGUMENTS` to access user-provided arguments when the skill is invoked.
 - All skill guidance executes within the sandbox; file I/O is confined to the workspace.
+- Skills are installed at `.agents/skills/<skill-id>/SKILL.md`. Workflow skills can also be compiled to `.agents/skills/<workflow-id>/SKILL.md` as `generatedSkills`.
+- Codex supports three autonomy levels: `suggest`, `auto-edit`, `full-auto`.
+- MCP skill tools are available when the Cubis Foundry MCP server is connected.

package/workflows/workflows/agent-environment-setup/platforms/codex/skills/csharp-best-practices/SKILL.md

@@ -76,8 +76,15 @@ No helper scripts are required for this skill right now. Keep execution in `SKIL
 
 ## Codex Platform Notes
 
-- Specialists are internal reasoning postures, not spawned subagent processes.
-- Reference the repo-root AGENTS instructions for posture definitions and switching contracts.
+- Codex supports native subagents via `.codex/agents/*.toml` files with `name`, `description`, and `developer_instructions`.
+- Each subagent TOML can specify `model` and `model_reasoning_effort` to optimize cost per task difficulty:
+  - Light tasks (exploration, docs): `model = "gpt-5.3-codex-spark"`, `model_reasoning_effort = "medium"`
+  - Heavy tasks (security audit, orchestration): `model = "gpt-5.4"`, `model_reasoning_effort = "high"`
+  - Standard tasks (implementation): inherit parent model (omit `model` field).
+- Built-in agents: `default`, `worker`, `explorer`. Custom agents extend these via TOML definitions.
 - Codex operates under network restrictions — skills should not assume outbound HTTP access.
 - Use `$ARGUMENTS` to access user-provided arguments when the skill is invoked.
 - All skill guidance executes within the sandbox; file I/O is confined to the workspace.
+- Skills are installed at `.agents/skills/<skill-id>/SKILL.md`. Workflow skills can also be compiled to `.agents/skills/<workflow-id>/SKILL.md` as `generatedSkills`.
+- Codex supports three autonomy levels: `suggest`, `auto-edit`, `full-auto`.
+- MCP skill tools are available when the Cubis Foundry MCP server is connected.

package/workflows/workflows/agent-environment-setup/platforms/codex/skills/database-design/SKILL.md

@@ -70,8 +70,15 @@ Load on demand. Do not preload all reference files.
 
 ## Codex Platform Notes
 
-- Specialists are internal reasoning postures, not spawned subagent processes.
-- Reference the repo-root AGENTS instructions for posture definitions and switching contracts.
+- Codex supports native subagents via `.codex/agents/*.toml` files with `name`, `description`, and `developer_instructions`.
+- Each subagent TOML can specify `model` and `model_reasoning_effort` to optimize cost per task difficulty:
+  - Light tasks (exploration, docs): `model = "gpt-5.3-codex-spark"`, `model_reasoning_effort = "medium"`
+  - Heavy tasks (security audit, orchestration): `model = "gpt-5.4"`, `model_reasoning_effort = "high"`
+  - Standard tasks (implementation): inherit parent model (omit `model` field).
+- Built-in agents: `default`, `worker`, `explorer`. Custom agents extend these via TOML definitions.
 - Codex operates under network restrictions — skills should not assume outbound HTTP access.
 - Use `$ARGUMENTS` to access user-provided arguments when the skill is invoked.
 - All skill guidance executes within the sandbox; file I/O is confined to the workspace.
+- Skills are installed at `.agents/skills/<skill-id>/SKILL.md`. Workflow skills can also be compiled to `.agents/skills/<workflow-id>/SKILL.md` as `generatedSkills`.
+- Codex supports three autonomy levels: `suggest`, `auto-edit`, `full-auto`.
+- MCP skill tools are available when the Cubis Foundry MCP server is connected.

package/workflows/workflows/agent-environment-setup/platforms/codex/skills/deep-research/SKILL.md

@@ -82,8 +82,15 @@ Use these when the task shape already matches.
 
 ## Codex Platform Notes
 
-- Specialists are internal reasoning postures, not spawned subagent processes.
-- Reference the repo-root AGENTS instructions for posture definitions and switching contracts.
+- Codex supports native subagents via `.codex/agents/*.toml` files with `name`, `description`, and `developer_instructions`.
+- Each subagent TOML can specify `model` and `model_reasoning_effort` to optimize cost per task difficulty:
+  - Light tasks (exploration, docs): `model = "gpt-5.3-codex-spark"`, `model_reasoning_effort = "medium"`
+  - Heavy tasks (security audit, orchestration): `model = "gpt-5.4"`, `model_reasoning_effort = "high"`
+  - Standard tasks (implementation): inherit parent model (omit `model` field).
+- Built-in agents: `default`, `worker`, `explorer`. Custom agents extend these via TOML definitions.
 - Codex operates under network restrictions — skills should not assume outbound HTTP access.
 - Use `$ARGUMENTS` to access user-provided arguments when the skill is invoked.
 - All skill guidance executes within the sandbox; file I/O is confined to the workspace.
+- Skills are installed at `.agents/skills/<skill-id>/SKILL.md`. Workflow skills can also be compiled to `.agents/skills/<workflow-id>/SKILL.md` as `generatedSkills`.
+- Codex supports three autonomy levels: `suggest`, `auto-edit`, `full-auto`.
+- MCP skill tools are available when the Cubis Foundry MCP server is connected.

package/workflows/workflows/agent-environment-setup/platforms/codex/skills/deep-research/examples/01-latest-docs-check.md

@@ -9,4 +9,4 @@
 1. Inspect the repo's current Claude rule and hook support first.
 2. Verify the current official Claude docs for hooks, event names, and config format.
 3. Separate those verified facts from any community commentary about hook effectiveness.
-4. End with the recommended next route, for example `@researcher` continuing the research or `/create` applying the validated hook template changes.
+4. End with the recommended next route, for example `@explorer` handing off to `@planner` or `/plan` applying the validated research result.

package/workflows/workflows/agent-environment-setup/platforms/codex/skills/deep-research/references/research-output.md

@@ -47,7 +47,7 @@ Research should end with one clear recommendation:
 
 - direct execution
 - a specific workflow like `/plan` or `/create`
-- a specialist like `@researcher` or `@frontend-specialist`
+- a concrete next route such as `@explorer`, `@planner`, or `@implementer`
 - an exact skill like `stitch` or `deep-research`
 
 Keep this recommendation concrete enough that the next step does not need another routing pass.

package/workflows/workflows/agent-environment-setup/platforms/codex/skills/django-drf/SKILL.md

@@ -61,8 +61,15 @@ No helper scripts are required for this skill right now. Keep execution in `SKIL
 
 ## Codex Platform Notes
 
-- Specialists are internal reasoning postures, not spawned subagent processes.
-- Reference the repo-root AGENTS instructions for posture definitions and switching contracts.
+- Codex supports native subagents via `.codex/agents/*.toml` files with `name`, `description`, and `developer_instructions`.
+- Each subagent TOML can specify `model` and `model_reasoning_effort` to optimize cost per task difficulty:
+  - Light tasks (exploration, docs): `model = "gpt-5.3-codex-spark"`, `model_reasoning_effort = "medium"`
+  - Heavy tasks (security audit, orchestration): `model = "gpt-5.4"`, `model_reasoning_effort = "high"`
+  - Standard tasks (implementation): inherit parent model (omit `model` field).
+- Built-in agents: `default`, `worker`, `explorer`. Custom agents extend these via TOML definitions.
 - Codex operates under network restrictions — skills should not assume outbound HTTP access.
 - Use `$ARGUMENTS` to access user-provided arguments when the skill is invoked.
 - All skill guidance executes within the sandbox; file I/O is confined to the workspace.
+- Skills are installed at `.agents/skills/<skill-id>/SKILL.md`. Workflow skills can also be compiled to `.agents/skills/<workflow-id>/SKILL.md` as `generatedSkills`.
+- Codex supports three autonomy levels: `suggest`, `auto-edit`, `full-auto`.
+- MCP skill tools are available when the Cubis Foundry MCP server is connected.