@cubis/foundry 0.3.82 → 0.3.83

package/workflows/workflows/agent-environment-setup/platforms/{claude/workflows/release.md → codex/generated-skills/release/SKILL.md}

@@ -1,9 +1,16 @@
 ---
-command: "/release"
+name: release
 description: "Prepare and execute release with rollout guardrails, verification, and rollback plan."
-triggers: ["release", "deploy", "rollout", "ship", "go-live"]
+license: MIT
+metadata:
+  author: cubis-foundry
+  route-kind: "workflow"
+  route-id: "release"
+  platform: "Codex"
+  command: "/release"
+compatibility: Codex
 ---
-
+# release Workflow
 # Release Workflow
 
 ## When to use
@@ -12,7 +19,7 @@ Use this when preparing a release, deploying to production, or managing a rollou
 
 ## Routing
 
-- Primary coordinator: `@ci-cd-pipeline`
+- Primary coordinator: `@devops-engineer`
 - Release verification: `@test-engineer`, `@validator`
 - Documentation: `@documentation-writer`
 
@@ -24,9 +31,9 @@ Use this when preparing a release, deploying to production, or managing a rollou
 
 ## Skill Routing
 
-- Primary skills: `ci-cd-pipeline`, `git-workflow`
-- Supporting skills (optional): `tech-doc`, `ci-cd-pipeline`, `observability`, `kubernetes-deploy`, `observability`, `ci-cd-pipeline`, `typescript-best-practices`, `javascript-best-practices`
-- Start with `ci-cd-pipeline` for deployment automation and `git-workflow` for release branching. Add `tech-doc` for release notes.
+- Primary skills: `ci-cd-pipelines`, `git-workflow`
+- Supporting skills (optional): `changelog-generator`, `devops-engineer`, `sre-engineer`, `docker-kubernetes`, `observability`, `serverless-patterns`, `typescript-pro`, `javascript-pro`
+- Start with `ci-cd-pipelines` for deployment automation and `git-workflow` for release branching. Add `changelog-generator` for release notes.
 
 ## Workflow steps
 
@@ -50,10 +57,10 @@ Use this when preparing a release, deploying to production, or managing a rollou
 
 ```yaml
 RELEASE_WORKFLOW_RESULT:
-  primary_agent: ci-cd-pipeline
+  primary_agent: devops-engineer
   supporting_agents: [test-engineer?, validator?, documentation-writer?]
-  primary_skills: [ci-cd-pipeline, git-workflow]
-  supporting_skills: [tech-doc?, ci-cd-pipeline?, observability?]
+  primary_skills: [ci-cd-pipelines, git-workflow]
+  supporting_skills: [changelog-generator?, devops-engineer?, sre-engineer?]
   release:
     version: <string>
     changelog: <string>
@@ -65,4 +72,4 @@ RELEASE_WORKFLOW_RESULT:
   rollback_plan: <string>
   doc_impact: none | tech | rules | both
   follow_up_items: [<string>] | []
-```
+```

package/workflows/workflows/agent-environment-setup/platforms/{copilot/workflows/review.md → codex/generated-skills/review/SKILL.md}

@@ -1,9 +1,16 @@
 ---
-command: "/review"
+name: review
 description: "Run a strict review for bugs, regressions, accessibility issues, security risk, and code quality with prioritized findings."
-triggers: ["review", "audit", "pr", "quality", "security review"]
+license: MIT
+metadata:
+  author: cubis-foundry
+  route-kind: "workflow"
+  route-id: "review"
+  platform: "Codex"
+  command: "/review"
+compatibility: Codex
 ---
-
+# review Workflow
 # Review Workflow
 
 ## When to use
@@ -24,9 +31,9 @@ Use this for code review, PR review, or quality audit of existing code changes.
 
 ## Skill Routing
 
-- Primary skills: `code-review`, `code-review`, `unit-testing`
-- Supporting skills (optional): `owasp-security-review`, `owasp-security-review`, `performance-testing`, `react`, `nextjs`, `typescript-best-practices`, `javascript-best-practices`, `python-best-practices`, `golang-best-practices`
-- Start with `code-review` for UI code or `code-review` for backend code. Add `unit-testing` when evaluating test quality. Add `owasp-security-review` for security-sensitive changes.
+- Primary skills: `frontend-code-review`, `static-analysis`, `testing-patterns`
+- Supporting skills (optional): `security-engineer`, `vulnerability-scanner`, `web-perf`, `react-expert`, `nextjs-developer`, `typescript-pro`, `javascript-pro`, `python-pro`, `golang-pro`
+- Start with `frontend-code-review` for UI code or `static-analysis` for backend code. Add `testing-patterns` when evaluating test quality. Add `security-engineer` for security-sensitive changes.
 
 ## Workflow steps
 
@@ -50,8 +57,8 @@ Use this for code review, PR review, or quality audit of existing code changes.
 REVIEW_WORKFLOW_RESULT:
   primary_agent: <frontend-specialist | backend-specialist>
   supporting_agents: [security-auditor?, validator?, test-engineer?]
-  primary_skills: [code-review?, code-review?, unit-testing?]
-  supporting_skills: [owasp-security-review?, owasp-security-review?, performance-testing?]
+  primary_skills: [frontend-code-review?, static-analysis?, testing-patterns?]
+  supporting_skills: [security-engineer?, vulnerability-scanner?, web-perf?]
   findings:
     - severity: critical | high | medium | low
       category: correctness | security | accessibility | performance | style
@@ -61,4 +68,4 @@ REVIEW_WORKFLOW_RESULT:
   overall_assessment: approve | request_changes | reject
   positive_observations: [<string>] | []
   follow_up_items: [<string>] | []
-```
+```

package/workflows/workflows/agent-environment-setup/platforms/{copilot/workflows/security.md → codex/generated-skills/security/SKILL.md}

@@ -1,9 +1,16 @@
 ---
-command: "/security"
+name: security
 description: "Run security-focused analysis and remediation planning with exploitability-first triage."
-triggers: ["security", "vulnerability", "owasp", "auth", "hardening"]
+license: MIT
+metadata:
+  author: cubis-foundry
+  route-kind: "workflow"
+  route-id: "security"
+  platform: "Codex"
+  command: "/security"
+compatibility: Codex
 ---
-
+# security Workflow
 # Security Workflow
 
 ## When to use
@@ -24,9 +31,9 @@ Use this for security audits, vulnerability assessments, threat modeling, or sec
 
 ## Skill Routing
 
-- Primary skills: `owasp-security-review`, `owasp-security-review`
-- Supporting skills (optional): `owasp-security-review`, `code-review`, `api-design`, `api-design`, `typescript-best-practices`, `javascript-best-practices`, `python-best-practices`, `golang-best-practices`, `rust-best-practices`
-- Start with `owasp-security-review` for OWASP methodology and threat modeling. Add `owasp-security-review` for authentication/authorization review. Add `owasp-security-review` for dependency scanning and CVE triage.
+- Primary skills: `security-engineer`, `auth-architect`
+- Supporting skills (optional): `vulnerability-scanner`, `static-analysis`, `api-design`, `graphql-architect`, `typescript-pro`, `javascript-pro`, `python-pro`, `golang-pro`, `rust-pro`
+- Start with `security-engineer` for OWASP methodology and threat modeling. Add `auth-architect` for authentication/authorization review. Add `vulnerability-scanner` for dependency scanning and CVE triage.
 
 ## Workflow steps
 
@@ -50,8 +57,8 @@ Use this for security audits, vulnerability assessments, threat modeling, or sec
 SECURITY_WORKFLOW_RESULT:
   primary_agent: security-auditor
   supporting_agents: [penetration-tester?, backend-specialist?, frontend-specialist?, validator?]
-  primary_skills: [owasp-security-review, owasp-security-review]
-  supporting_skills: [owasp-security-review?, code-review?, api-design?]
+  primary_skills: [security-engineer, auth-architect]
+  supporting_skills: [vulnerability-scanner?, static-analysis?, api-design?]
   threat_model:
     assets: [<string>]
     threats: [<string>]
@@ -64,4 +71,4 @@ SECURITY_WORKFLOW_RESULT:
   compliance_notes: [<string>] | []
   remaining_risks: [<string>] | []
   follow_up_items: [<string>] | []
-```
+```

package/workflows/workflows/agent-environment-setup/platforms/{copilot/workflows/spec.md → codex/generated-skills/spec/SKILL.md}

@@ -1,19 +1,16 @@
 ---
-command: "/spec"
+name: spec
 description: "Create or refresh a Git-tracked spec pack for non-trivial work, including acceptance criteria, traceability, architecture impact, and next-route handoff."
-triggers:
-  [
-    "spec",
-    "sdd",
-    "source of truth",
-    "traceability",
-    "acceptance criteria",
-    "openspec",
-    "requirements",
-    "architecture impact",
-  ]
+license: MIT
+metadata:
+  author: cubis-foundry
+  route-kind: "workflow"
+  route-id: "spec"
+  platform: "Codex"
+  command: "/spec"
+compatibility: Codex
 ---
-
+# spec Workflow
 # Spec Workflow
 
 ## When to use
@@ -76,4 +73,4 @@ SPEC_WORKFLOW_RESULT:
     updated: [<path>] | []
   next_route: </create | /implement-track | /orchestrate | /architecture | direct>
   gaps: [<string>] | []
-```
+```

package/workflows/workflows/agent-environment-setup/platforms/{copilot/workflows/test.md → codex/generated-skills/test/SKILL.md}

@@ -1,9 +1,16 @@
 ---
-command: "/test"
+name: test
 description: "Design and execute verification strategy aligned to user risk, release confidence, and regression evidence."
-triggers: ["test", "verify", "coverage", "qa", "regression"]
+license: MIT
+metadata:
+  author: cubis-foundry
+  route-kind: "workflow"
+  route-id: "test"
+  platform: "Codex"
+  command: "/test"
+compatibility: Codex
 ---
-
+# test Workflow
 # Test Workflow
 
 ## When to use
@@ -24,9 +31,9 @@ Use this when writing new tests, improving coverage, debugging test failures, or
 
 ## Skill Routing
 
-- Primary skills: `unit-testing`, `integration-testing`
-- Supporting skills (optional): `playwright-interactive`, `observability`, `systematic-debugging`, `code-review`, `code-review`, `typescript-best-practices`, `javascript-best-practices`, `python-best-practices`, `golang-best-practices`, `java-best-practices`
-- Start with `unit-testing` for test strategy and architecture. Add `integration-testing` for implementation. Add `playwright-interactive` for E2E automation. Add `observability` for testing error states.
+- Primary skills: `testing-patterns`, `webapp-testing`
+- Supporting skills (optional): `playwright-e2e`, `error-ux-observability`, `debugging-strategies`, `frontend-code-review`, `static-analysis`, `typescript-pro`, `javascript-pro`, `python-pro`, `golang-pro`, `java-pro`
+- Start with `testing-patterns` for test strategy and architecture. Add `webapp-testing` for implementation. Add `playwright-e2e` for E2E automation. Add `error-ux-observability` for testing error states.
 
 ## Workflow steps
 
@@ -49,8 +56,8 @@ Use this when writing new tests, improving coverage, debugging test failures, or
 TEST_WORKFLOW_RESULT:
   primary_agent: test-engineer
   supporting_agents: [qa-automation-engineer?, backend-specialist?, frontend-specialist?, validator?]
-  primary_skills: [unit-testing, integration-testing]
-  supporting_skills: [playwright-interactive?, observability?, systematic-debugging?]
+  primary_skills: [testing-patterns, webapp-testing]
+  supporting_skills: [playwright-e2e?, error-ux-observability?, debugging-strategies?]
   test_strategy:
     unit: <number of tests>
     integration: <number of tests>
@@ -61,4 +68,4 @@ TEST_WORKFLOW_RESULT:
     after: <percentage or description>
   gaps_remaining: [<string>] | []
   follow_up_items: [<string>] | []
-```
+```

package/workflows/workflows/agent-environment-setup/platforms/{claude/workflows/vercel.md → codex/generated-skills/vercel/SKILL.md}

@@ -1,18 +1,16 @@
 ---
-command: "/vercel"
+name: vercel
 description: "Drive Vercel implementation and operations via vercel-expert with deployment, runtime, security, and observability guardrails."
-triggers:
-  [
-    "vercel",
-    "deployment",
-    "preview",
-    "edge",
-    "functions",
-    "domains",
-    "vercel cli",
-  ]
+license: MIT
+metadata:
+  author: cubis-foundry
+  route-kind: "workflow"
+  route-id: "vercel"
+  platform: "Codex"
+  command: "/vercel"
+compatibility: Codex
 ---
-
+# vercel Workflow
 # Vercel Workflow
 
 ## When to use
@@ -22,7 +20,7 @@ Use this for Vercel-specific deployment, configuration, runtime optimization, or
 ## Routing
 
 - Primary specialist: `@vercel-expert`
-- Infrastructure support: `@ci-cd-pipeline`
+- Infrastructure support: `@devops-engineer`
 - Verification support: `@test-engineer`
 
 ## Context notes
@@ -32,9 +30,9 @@ Use this for Vercel-specific deployment, configuration, runtime optimization, or
 
 ## Skill Routing
 
-- Primary skills: `nextjs`, `ci-cd-pipeline`
-- Supporting skills (optional): `performance-testing`, `react`, `frontend-design`, `javascript-best-practices`, `typescript-best-practices`, `javascript-best-practices`
-- Start with `nextjs` for Next.js on Vercel and `ci-cd-pipeline` for runtime behavior. Add `performance-testing` for performance optimization.
+- Primary skills: `nextjs-developer`, `serverless-patterns`
+- Supporting skills (optional): `web-perf`, `react-expert`, `tailwind-patterns`, `nodejs-best-practices`, `typescript-pro`, `javascript-pro`
+- Start with `nextjs-developer` for Next.js on Vercel and `serverless-patterns` for runtime behavior. Add `web-perf` for performance optimization.
 
 ## Workflow steps
 
@@ -57,9 +55,9 @@ Use this for Vercel-specific deployment, configuration, runtime optimization, or
 ```yaml
 VERCEL_WORKFLOW_RESULT:
   primary_agent: vercel-expert
-  supporting_agents: [ci-cd-pipeline?, test-engineer?]
-  primary_skills: [nextjs, ci-cd-pipeline]
-  supporting_skills: [performance-testing?, react?]
+  supporting_agents: [devops-engineer?, test-engineer?]
+  primary_skills: [nextjs-developer, serverless-patterns]
+  supporting_skills: [web-perf?, react-expert?]
   deployment:
     project: <string>
     runtime: <edge | serverless | static>
@@ -71,4 +69,4 @@ VERCEL_WORKFLOW_RESULT:
     caching: <string>
   monitoring: <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/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.

package/workflows/workflows/agent-environment-setup/platforms/codex/skills/docker-compose-dev/SKILL.md

@@ -67,8 +67,15 @@ Provide complete `docker-compose.yml` and `Dockerfile` content with inline comme
 
 ## 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/drizzle-orm/SKILL.md

@@ -74,8 +74,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/electron-qa/SKILL.md

@@ -80,8 +80,15 @@ Deliver:
 
 ## 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.