@cubis/foundry 0.3.81 → 0.3.83

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

@@ -0,0 +1,124 @@
+---
+name: architecture
+description: "Refresh the core project foundation docs in docs/foundation/MEMORY.md, docs/foundation/PRODUCT.md, docs/foundation/ARCHITECTURE.md, docs/foundation/TECH.md, docs/foundation/memory/*.md, and ADR scaffolds with explicit structure, product context, testing, and flow guidance."
+license: MIT
+metadata:
+  author: cubis-foundry
+  route-kind: "workflow"
+  route-id: "architecture"
+  platform: "Codex"
+  command: "/architecture"
+compatibility: Codex
+---
+# architecture Workflow
+# Architecture Workflow
+
+## When to use
+
+Use this when the task is to declare, refresh, or validate the project backbone docs, especially after structure changes, scale changes, design-system changes, migrations, product-direction shifts, or major feature additions.
+
+## Routing
+
+- Primary coordinator: `@project-planner`
+- Documentation support: `@documentation-writer`
+- Research support: `@researcher`
+- Domain validation: `@backend-specialist`, `@frontend-specialist`, `@database-architect`
+
+## Skill Routing
+
+- Primary skills: `architecture-doc`, `system-design`, `tech-doc`, `frontend-design`
+- Supporting skills (optional): `api-design`, `database-design`, `sadd`, `deep-research`
+- Load the four primary skills directly for this workflow. Add `api-design` or `database-design` when service or data boundaries are central, `sadd` when tying the architecture update to an active spec pack, and `deep-research` only when outside evidence is required.
+
+## Workflow steps
+
+1. Inspect the repo first and derive the current product surfaces, architecture style, module boundaries, technical constraints, and testing strategy from the codebase itself.
+2. Read concrete repo anchors before drafting: root README/manifests, main entrypoints, the primary app roots, existing `docs/specs/`, and representative source folders for each major surface.
+3. Read `docs/foundation/MEMORY.md` first if it exists, then load `docs/foundation/PRODUCT.md`, `docs/foundation/ARCHITECTURE.md`, `docs/foundation/TECH.md`, `docs/foundation/memory/*.md`, and ADRs on demand.
+4. Update the managed foundation sections in `docs/foundation/MEMORY.md`, `docs/foundation/PRODUCT.md`, `docs/foundation/ARCHITECTURE.md`, `docs/foundation/TECH.md`, and `docs/foundation/memory/*.md`.
+5. Make `docs/foundation/MEMORY.md` the durable entrypoint: concise project summary, load-on-demand map, exact links to deeper docs, explicit consumer guidance for rules, workflows, agents, and skills, and a strong bias against bloat.
+6. Ensure each deeper foundation doc makes it obvious when it should be consulted and by which route families (planning/spec, architecture/refactor, build/test/debug, runtime/integration, or ADR work).
+7. Make `docs/foundation/ARCHITECTURE.md` explicitly state the architecture type in use and include a folder-structure guide for the important apps/packages/directories.
+8. Add or refresh Mermaid diagrams using fenced ` ```mermaid ` blocks with valid syntax inside `docs/foundation/ARCHITECTURE.md` or `docs/foundation/TECH.md` when they clarify system behavior. Use `sequenceDiagram` for runtime flows and `graph TD` or `C4Context` for structural views.
+9. Ensure `docs/foundation/PRODUCT.md` includes a `## Domain Glossary` defining project-specific terms so future agents use consistent vocabulary.
+10. Ensure `docs/foundation/ARCHITECTURE.md` includes `## Crosscutting Concerns` (logging, auth, error handling patterns), `## Quality Requirements`, and `## Risks And Tech Debt` sections.
+11. Ensure `docs/foundation/TECH.md` includes `## Build And Validation` (exact commands from clean clone to passing CI), `## CI CD Pipeline` (workflow files and triggers), and `## Error Patterns And Debugging` (common errors and resolutions).
+12. Ensure the topic docs under `docs/foundation/memory/` stay narrow and task-oriented:
+    - `domain.md`
+    - `runtime.md`
+    - `integrations.md`
+    - `debugging.md`
+13. Seed or refresh `docs/foundation/adr/README.md` and `docs/foundation/adr/0000-template.md`, and keep ADR linkage explicit when decisions should be durable.
+14. Record whether the update was driven by a broader spec and whether future implementation must follow newly declared structure or product constraints.
+
+## Context notes
+
+- This workflow is route-fixed and skill-fixed: do not start with `route_resolve` or `skill_search`.
+- `docs/foundation/MEMORY.md` is the first-stop index for AI agents. It should stay concise, durable, and link outward instead of duplicating every deep detail.
+- Keep `docs/foundation/MEMORY.md` under roughly 120 lines when possible. If a section grows beyond a short paragraph or 5-7 bullets, move the detail into a deeper doc and leave only the routing summary behind.
+- `docs/foundation/PRODUCT.md` captures intent and domain glossary, `docs/foundation/ARCHITECTURE.md` captures accepted structure and crosscutting concerns, and `docs/foundation/TECH.md` is the developer-facing technical map with build/validation commands. Keep them aligned but not redundant.
+- `docs/foundation/MEMORY.md` should tell future rules, workflows, agents, and skills which deeper doc to consult for planning/spec work, architecture/refactors, build/test/debug work, runtime/integration work, and ADR-worthy decisions.
+- `docs/foundation/PRODUCT.md` should make it obvious that planning/spec/product routes consult it first; `docs/foundation/ARCHITECTURE.md` should make it obvious that architecture/refactor routes consult it first; `docs/foundation/TECH.md` should make it obvious that build/test/debug/devops routes consult it first.
+- Favor a lean arc42/C4 style: clear scope, boundaries, building blocks, runtime flows, crosscutting concerns, quality requirements, risks, deployment/testing notes, and only diagrams that add real value.
+- `docs/foundation/ARCHITECTURE.md` should guide future contributors, not just describe the system. Be explicit about architecture style and folder ownership.
+- `docs/foundation/TECH.md` should enable an AI agent to start working immediately: exact build commands, environment setup, error patterns, and validation steps.
+- Topic docs in `docs/foundation/memory/` should be load-on-demand references rather than duplicated summary docs, and should clearly indicate which runtime, integration, or debugging routes benefit from them.
+- Prefer stable section headings over ad hoc prose so future refreshes stay clean and easy to diff.
+- All generated markdown must use correct formatting: single H1, proper heading hierarchy, fenced code blocks with language identifiers, valid Mermaid syntax, and tables with header/separator rows.
+- Preserve manual content outside the managed foundation sections.
+- Mark non-applicable sections explicitly instead of silently omitting them.
+- Use relative markdown links between foundation docs: `[ARCHITECTURE.md](docs/foundation/ARCHITECTURE.md)`.
+
+## Verification
+
+- Managed foundation sections exist in the target docs under `docs/foundation/`.
+- `docs/foundation/MEMORY.md` exists and points cleanly to the deeper backbone docs and topic docs.
+- `docs/foundation/MEMORY.md` includes a clear consumer/load map for rules, workflows, agents, and skills.
+- `docs/foundation/MEMORY.md` stays lean and index-like instead of copying large sections from the deeper foundation docs.
+- Product intent, architecture style, dependency rules, and technical guidance are explicit.
+- `docs/foundation/PRODUCT.md` includes a `## Domain Glossary` with project-specific terms.
+- `docs/foundation/ARCHITECTURE.md` includes `## Crosscutting Concerns`, `## Quality Requirements`, and `## Risks And Tech Debt`.
+- `docs/foundation/ARCHITECTURE.md` or `docs/foundation/TECH.md` includes flow text and at least one Mermaid diagram when the repo has meaningful flow complexity.
+- `docs/foundation/TECH.md` includes `## Build And Validation` with exact commands and `## Error Patterns And Debugging`.
+- All Mermaid diagrams use fenced ```mermaid blocks with valid syntax (no rendering errors).
+- All markdown files use correct heading hierarchy (single H1, no skipped levels).
+- The update records `doc_impact` and whether future feature work must refresh the docs again.
+
+## Output Contract
+
+```yaml
+ARCHITECTURE_WORKFLOW_RESULT:
+  primary_agent: project-planner
+  supporting_agents: [documentation-writer?, researcher?, backend-specialist?, frontend-specialist?, database-architect?]
+  primary_skills: [architecture-doc, system-design, tech-doc, frontend-design]
+  supporting_skills: [api-design?, database-design?, sadd?, deep-research?]
+  managed_targets:
+    memory_doc: docs/foundation/MEMORY.md
+    product_doc: docs/foundation/PRODUCT.md
+    architecture_doc: docs/foundation/ARCHITECTURE.md
+    tech_doc: docs/foundation/TECH.md
+    memory_topics_dir: docs/foundation/memory
+    adr_dir: docs/foundation/adr
+  files_updated: [docs/foundation/MEMORY.md, docs/foundation/PRODUCT.md, docs/foundation/ARCHITECTURE.md, docs/foundation/TECH.md, docs/foundation/memory/domain.md, docs/foundation/memory/runtime.md, docs/foundation/memory/integrations.md, docs/foundation/memory/debugging.md]
+  architecture_contract:
+    style: <string>
+    dependency_rules: [<string>]
+    design_system_source: <string>
+    crosscutting_concerns: [<string>]
+    quality_requirements: [<string>]
+    risks_and_tech_debt: [<string>]
+  technical_snapshot:
+    topology: [<string>]
+    flows: [<string>]
+    diagrams: [<string>] | []
+    build_commands: [<string>]
+    error_patterns: [<string>] | []
+  product_glossary: [<string>] | []
+  consumer_guidance:
+    memory_routes: [<string>]
+    product_routes: [<string>]
+    architecture_routes: [<string>]
+    tech_routes: [<string>]
+  doc_impact: rules | tech | both
+  next_actions: [<string>] | []
+```

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

@@ -1,24 +1,16 @@
 ---
-command: "/backend"
+name: backend
 description: "Drive backend architecture, API operations, and Postman-oriented execution with API, data, and reliability focus."
-triggers:
-  [
-    "backend",
-    "api",
-    "service",
-    "database",
-    "performance",
-    "postman",
-    "collection",
-    "workspace",
-    "environment",
-    "runcollection",
-    "monitor",
-    "mock",
-    "api test",
-  ]
+license: MIT
+metadata:
+  author: cubis-foundry
+  route-kind: "workflow"
+  route-id: "backend"
+  platform: "Codex"
+  command: "/backend"
+compatibility: Codex
 ---
-
+# backend Workflow
 # Backend Workflow
 
 ## When to use
@@ -40,9 +32,9 @@ Use this for backend architecture, API design, service implementation, or Postma
 
 ## Skill Routing
 
-- Primary skills: `api-design`, `api-design`, `javascript-best-practices`
-- Supporting skills (optional): `owasp-security-review`, `database-design`, `database-design`, `nestjs`, `fastapi`, `api-design`, `microservices-design`, `drizzle-orm`, `database-design`, `stripe-integration`, `ci-cd-pipeline`, `frontend-design`, `typescript-best-practices`, `javascript-best-practices`, `python-best-practices`, `golang-best-practices`
-- Start with `api-design` for API contract work and `javascript-best-practices` for Node.js services. Add framework-specific skill when applicable.
+- Primary skills: `api-design`, `api-patterns`, `nodejs-best-practices`
+- Supporting skills (optional): `auth-architect`, `database-design`, `database-design`, `nestjs-expert`, `fastapi-expert`, `graphql-architect`, `microservices-architect`, `drizzle-expert`, `firebase`, `stripe-best-practices`, `serverless-patterns`, `i18n-localization`, `typescript-pro`, `javascript-pro`, `python-pro`, `golang-pro`
+- Start with `api-design` for API contract work and `nodejs-best-practices` for Node.js services. Add framework-specific skill when applicable.
 
 ## Workflow steps
 
@@ -67,8 +59,8 @@ Use this for backend architecture, API design, service implementation, or Postma
 BACKEND_WORKFLOW_RESULT:
   primary_agent: backend-specialist
   supporting_agents: [database-architect?, security-auditor?, test-engineer?]
-  primary_skills: [api-design, api-design, javascript-best-practices]
-  supporting_skills: [owasp-security-review?, database-design?, <framework-skill>?]
+  primary_skills: [api-design, api-patterns, nodejs-best-practices]
+  supporting_skills: [auth-architect?, database-design?, <framework-skill>?]
   api_changes:
     endpoints_created: [<string>] | []
     endpoints_modified: [<string>] | []
@@ -81,4 +73,4 @@ BACKEND_WORKFLOW_RESULT:
     checks_run: [<command-or-test>]
     evidence: [<string>]
   follow_up_items: [<string>] | []
-```
+```

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

@@ -1,9 +1,16 @@
 ---
-command: "/create"
+name: create
 description: "Implement feature work with minimal blast radius and clear verification checkpoints."
-triggers: ["create", "build", "implement", "feature", "develop"]
+license: MIT
+metadata:
+  author: cubis-foundry
+  route-kind: "workflow"
+  route-id: "create"
+  platform: "Codex"
+  command: "/create"
+compatibility: Codex
 ---
-
+# create Workflow
 # Create Workflow
 
 ## When to use
@@ -26,8 +33,8 @@ Use this for net-new implementation after design is stable.
 
 ## Skill Routing
 
-- Primary skills: `typescript-best-practices`, `javascript-best-practices`, `python-best-practices`, `golang-best-practices`, `java-best-practices`, `csharp-best-practices`, `kotlin-best-practices`, `rust-best-practices`, `php-best-practices`, `php-best-practices`, `rust-best-practices`, `rust-best-practices`, `expo-app`, `swift-best-practices`
-- Supporting skills (optional): `api-design`, `api-design`, `javascript-best-practices`, `nestjs`, `fastapi`, `api-design`, `drizzle-orm`, `database-design`, `mcp-server-builder`, `stitch`, `react`, `react`, `nextjs`, `frontend-design`, `frontend-design`, `frontend-design`, `performance-testing`, `skill-creator`, `stripe-integration`, `ci-cd-pipeline`, `frontend-design`
+- Primary skills: `typescript-pro`, `javascript-pro`, `python-pro`, `golang-pro`, `java-pro`, `csharp-pro`, `kotlin-pro`, `rust-pro`, `php-pro`, `ruby-pro`, `c-pro`, `cpp-pro`, `dart-pro`, `swift-pro`
+- Supporting skills (optional): `api-design`, `api-patterns`, `nodejs-best-practices`, `nestjs-expert`, `fastapi-expert`, `graphql-architect`, `drizzle-expert`, `firebase`, `mcp-server-builder`, `stitch`, `react-expert`, `react-best-practices`, `nextjs-developer`, `tailwind-patterns`, `frontend-design`, `design-system-builder`, `web-perf`, `skill-creator`, `stripe-best-practices`, `serverless-patterns`, `i18n-localization`
 - Pick one primary language skill from repo signals or touched files. Add the narrowest specialist only when the feature is clearly backend or frontend framework-specific.
 - If the request references Stitch screens, artifacts, design-to-code, or UI sync, add `stitch` first and route the implementation through the frontend or mobile specialist based on the destination surface.
 
@@ -63,4 +70,4 @@ CREATE_WORKFLOW_RESULT:
     evidence: [<string>]
     gaps: [<string>] | []
   follow_up_items: [<string>] | []
-```
+```

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

@@ -1,9 +1,16 @@
 ---
-command: "/database"
+name: database
 description: "Design or review schema, queries, and migrations with performance and integrity controls."
-triggers: ["database", "sql", "schema", "migration", "index"]
+license: MIT
+metadata:
+  author: cubis-foundry
+  route-kind: "workflow"
+  route-id: "database"
+  platform: "Codex"
+  command: "/database"
+compatibility: Codex
 ---
-
+# database Workflow
 # Database Workflow
 
 ## When to use
@@ -24,9 +31,9 @@ Use this for schema design, query optimization, migration planning, or database
 
 ## Skill Routing
 
-- Primary skills: `database-design`, `database-design`, `database-design`
-- Supporting skills (optional): `drizzle-orm`, `database-design`, `database-design`, `database-design`, `database-design`, `database-design`, `database-design`, `database-design`, `database-design`, `typescript-best-practices`, `javascript-best-practices`, `python-best-practices`
-- Start with `database-design` for schema work, `database-design` for performance, or `database-design` for general database operations. Add engine-specific skill when applicable.
+- Primary skills: `database-design`, `database-optimizer`, `database-design`
+- Supporting skills (optional): `drizzle-expert`, `postgres`, `mysql`, `sqlite`, `mongodb`, `redis`, `supabase`, `firebase`, `vitess`, `typescript-pro`, `javascript-pro`, `python-pro`
+- Start with `database-design` for schema work, `database-optimizer` for performance, or `database-design` for general database operations. Add engine-specific skill when applicable.
 
 ## Workflow steps
 
@@ -50,8 +57,8 @@ Use this for schema design, query optimization, migration planning, or database
 DATABASE_WORKFLOW_RESULT:
   primary_agent: database-architect
   supporting_agents: [backend-specialist?, test-engineer?]
-  primary_skills: [database-design, database-design, database-design]
-  supporting_skills: [<engine-specific-skill>?, drizzle-orm?]
+  primary_skills: [database-design, database-optimizer, database-design]
+  supporting_skills: [<engine-specific-skill>?, drizzle-expert?]
   schema_changes:
     tables_affected: [<string>]
     migration_plan: <string>
@@ -62,4 +69,4 @@ DATABASE_WORKFLOW_RESULT:
   doc_impact: none | tech | rules | both
   integrity_checks: [<string>]
   follow_up_items: [<string>] | []
-```
+```

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

@@ -1,9 +1,16 @@
 ---
-command: "/debug"
+name: debug
 description: "Isolate root cause quickly, apply the smallest safe remediation, and leave behind regression evidence."
-triggers: ["debug", "bug", "error", "incident", "stack trace"]
+license: MIT
+metadata:
+  author: cubis-foundry
+  route-kind: "workflow"
+  route-id: "debug"
+  platform: "Codex"
+  command: "/debug"
+compatibility: Codex
 ---
-
+# debug Workflow
 # Debug Workflow
 
 ## When to use
@@ -23,9 +30,9 @@ Use this when behavior is failing, inconsistent, flaky, or only reproducible und
 
 ## Skill Routing
 
-- Primary skills: `systematic-debugging`, `observability`
-- Supporting skills (optional): `unit-testing`, `typescript-best-practices`, `javascript-best-practices`, `python-best-practices`, `golang-best-practices`, `java-best-practices`, `csharp-best-practices`, `kotlin-best-practices`, `rust-best-practices`, `integration-testing`, `playwright-interactive`, `skill-creator`
-- Start with `systematic-debugging` for reproduce, isolate, instrument, and verify flow. Add `observability` when the failure involves error states, logging, or tracing gaps. Add the dominant language skill for exact code-path analysis, `integration-testing` or `playwright-interactive` when the failure lives in browser or release verification.
+- Primary skills: `debugging-strategies`, `error-ux-observability`
+- Supporting skills (optional): `testing-patterns`, `typescript-pro`, `javascript-pro`, `python-pro`, `golang-pro`, `java-pro`, `csharp-pro`, `kotlin-pro`, `rust-pro`, `webapp-testing`, `playwright-e2e`, `skill-creator`
+- Start with `debugging-strategies` for reproduce, isolate, instrument, and verify flow. Add `error-ux-observability` when the failure involves error states, logging, or tracing gaps. Add the dominant language skill for exact code-path analysis, `webapp-testing` or `playwright-e2e` when the failure lives in browser or release verification.
 
 ## Workflow steps
 
@@ -47,8 +54,8 @@ Use this when behavior is failing, inconsistent, flaky, or only reproducible und
 DEBUG_WORKFLOW_RESULT:
   primary_agent: debugger
   supporting_agents: [backend-specialist?, frontend-specialist?, test-engineer?]
-  primary_skills: [systematic-debugging, observability]
-  supporting_skills: [unit-testing?, <language-skill>?, integration-testing?, playwright-interactive?]
+  primary_skills: [debugging-strategies, error-ux-observability]
+  supporting_skills: [testing-patterns?, <language-skill>?, webapp-testing?, playwright-e2e?]
   reproduction:
     steps: [<string>]
     expected_vs_actual: <string>
@@ -58,4 +65,4 @@ DEBUG_WORKFLOW_RESULT:
     changed_artifacts: [<path-or-artifact>]
   regression_checks: [<command or test>]
   follow_up_items: [<string>] | []
-```
+```

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

@@ -1,23 +1,16 @@
 ---
-command: "/devops"
+name: devops
 description: "Plan and execute deployment, CI/CD, incident response, and operational safety changes with rollback controls."
-triggers:
-  [
-    "devops",
-    "deploy",
-    "ci",
-    "cd",
-    "rollback",
-    "infra",
-    "incident",
-    "outage",
-    "sev",
-    "degraded",
-    "hotfix",
-    "recovery",
-  ]
+license: MIT
+metadata:
+  author: cubis-foundry
+  route-kind: "workflow"
+  route-id: "devops"
+  platform: "Codex"
+  command: "/devops"
+compatibility: Codex
 ---
-
+# devops Workflow
 # DevOps Workflow
 
 ## When to use
@@ -26,8 +19,8 @@ Use this for deployment automation, CI/CD pipeline changes, incident response, o
 
 ## Routing
 
-- Primary specialist: `@ci-cd-pipeline`
-- Reliability support: `@observability`
+- Primary specialist: `@devops-engineer`
+- Reliability support: `@sre-engineer`
 - Verification support: `@validator`
 
 ## Context notes
@@ -37,9 +30,9 @@ Use this for deployment automation, CI/CD pipeline changes, incident response, o
 
 ## Skill Routing
 
-- Primary skills: `ci-cd-pipeline`, `ci-cd-pipeline`, `kubernetes-deploy`
-- Supporting skills (optional): `observability`, `observability`, `ci-cd-pipeline`, `git-workflow`, `systematic-debugging`, `typescript-best-practices`, `javascript-best-practices`, `python-best-practices`, `golang-best-practices`
-- Start with `ci-cd-pipeline` for operational patterns. Add `ci-cd-pipeline` for pipeline work, `kubernetes-deploy` for container operations, `observability` for incident response, `ci-cd-pipeline` for serverless infrastructure.
+- Primary skills: `devops-engineer`, `ci-cd-pipelines`, `docker-kubernetes`
+- Supporting skills (optional): `sre-engineer`, `observability`, `serverless-patterns`, `git-workflow`, `debugging-strategies`, `typescript-pro`, `javascript-pro`, `python-pro`, `golang-pro`
+- Start with `devops-engineer` for operational patterns. Add `ci-cd-pipelines` for pipeline work, `docker-kubernetes` for container operations, `sre-engineer` for incident response, `serverless-patterns` for serverless infrastructure.
 
 ## Workflow steps
 
@@ -60,10 +53,10 @@ Use this for deployment automation, CI/CD pipeline changes, incident response, o
 
 ```yaml
 DEVOPS_WORKFLOW_RESULT:
-  primary_agent: ci-cd-pipeline
-  supporting_agents: [observability?, validator?]
-  primary_skills: [ci-cd-pipeline, ci-cd-pipeline, kubernetes-deploy]
-  supporting_skills: [observability?, observability?, ci-cd-pipeline?]
+  primary_agent: devops-engineer
+  supporting_agents: [sre-engineer?, validator?]
+  primary_skills: [devops-engineer, ci-cd-pipelines, docker-kubernetes]
+  supporting_skills: [sre-engineer?, observability?, serverless-patterns?]
   change:
     description: <string>
     blast_radius: <string>
@@ -73,4 +66,4 @@ DEVOPS_WORKFLOW_RESULT:
     health_checks: [<string>]
   operational_docs: [<string>] | []
   follow_up_items: [<string>] | []
-```
+```

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

@@ -1,9 +1,16 @@
 ---
-command: "/implement-track"
+name: implement-track
 description: "Execute large work in milestones with explicit quality gates and status updates."
-triggers: ["track", "milestone", "delivery", "progress", "execution"]
+license: MIT
+metadata:
+  author: cubis-foundry
+  route-kind: "workflow"
+  route-id: "implement-track"
+  platform: "Codex"
+  command: "/implement-track"
+compatibility: Codex
 ---
-
+# implement-track Workflow
 # Implement Track Workflow
 
 ## When to use
@@ -21,12 +28,12 @@ Use this for large-scale implementation work that spans multiple sessions or mil
 - This workflow file, active platform rules, and selected agents or skills guide execution.
 - Attach the implementation plan, milestone definitions, and acceptance criteria per milestone.
 - Reuse `docs/specs/<spec-id>/` when present instead of maintaining a separate progress source of truth.
-- Read `ENGINEERING_RULES.md` first and `TECH.md` next before starting milestone execution.
+- Read `ENGINEERING_RULES.md` first and `docs/foundation/TECH.md` next before starting milestone execution. Use `## Build And Validation` for the validated build sequence and `## Key Commands` for test/lint commands.
 
 ## Skill Routing
 
 - Primary skills: `system-design`, `api-design`
-- Supporting skills (optional): `database-design`, `typescript-best-practices`, `javascript-best-practices`, `python-best-practices`, `golang-best-practices`, `react`, `nextjs`
+- Supporting skills (optional): `database-design`, `typescript-pro`, `javascript-pro`, `python-pro`, `golang-pro`, `react-expert`, `nextjs-developer`
 - Start with `system-design` for milestone planning. Load domain-specific skills per milestone based on implementation needs.
 
 ## Workflow steps
@@ -52,7 +59,7 @@ IMPLEMENT_TRACK_WORKFLOW_RESULT:
   primary_agent: orchestrator
   supporting_agents: [<milestone-agents>]
   primary_skills: [system-design, api-design]
-  supporting_skills: [database-design?, typescript-best-practices?, javascript-best-practices?, python-best-practices?, golang-best-practices?, react?, nextjs?]
+  supporting_skills: [database-design?, typescript-pro?, javascript-pro?, python-pro?, golang-pro?, react-expert?, nextjs-developer?]
   milestones:
     - id: <milestone-id>
       description: <string>
@@ -66,4 +73,4 @@ IMPLEMENT_TRACK_WORKFLOW_RESULT:
   traceability_status: complete | partial | blocked
   doc_impact: none | tech | rules | both
   follow_up_items: [<string>] | []
-```
+```

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

@@ -1,17 +1,16 @@
 ---
-command: "/migrate"
+name: migrate
 description: "Plan and execute technology migrations, framework upgrades, and dependency updates with rollback safety, incremental verification, and zero-downtime transition."
-triggers:
-  [
-    "migrate",
-    "upgrade",
-    "update dependency",
-    "framework upgrade",
-    "version bump",
-    "major update",
-  ]
+license: MIT
+metadata:
+  author: cubis-foundry
+  route-kind: "workflow"
+  route-id: "migrate"
+  platform: "Codex"
+  command: "/migrate"
+compatibility: Codex
 ---
-
+# migrate Workflow
 # Migrate Workflow
 
 ## When to use
@@ -28,13 +27,13 @@ Use this for technology migrations, framework upgrades, dependency updates, or m
 
 - This workflow file, active platform rules, and selected agents or skills guide execution.
 - Attach the migration target, current versions, breaking change lists, and impact assessment.
-- Read `ENGINEERING_RULES.md` and `TECH.md` first because migrations often change accepted patterns and current-state architecture at the same time.
+- Read `ENGINEERING_RULES.md` and `docs/foundation/TECH.md` first because migrations often change accepted patterns and current-state architecture at the same time. After migration, flag updates needed in `docs/foundation/ARCHITECTURE.md` for `## Risks And Tech Debt`.
 
 ## Skill Routing
 
-- Primary skills: `system-design`, `system-design`
-- Supporting skills (optional): `code-review`, `unit-testing`, `typescript-best-practices`, `javascript-best-practices`, `python-best-practices`, `golang-best-practices`
-- Start with `system-design` for migration methodology and `system-design` for system impact. Add `code-review` for automated codemod or compatibility analysis.
+- Primary skills: `legacy-modernizer`, `system-design`
+- Supporting skills (optional): `static-analysis`, `testing-patterns`, `typescript-pro`, `javascript-pro`, `python-pro`, `golang-pro`
+- Start with `legacy-modernizer` for migration methodology and `system-design` for system impact. Add `static-analysis` for automated codemod or compatibility analysis.
 
 ## Workflow steps
 
@@ -60,8 +59,8 @@ Use this for technology migrations, framework upgrades, dependency updates, or m
 MIGRATE_WORKFLOW_RESULT:
   primary_agent: code-archaeologist
   supporting_agents: [backend-specialist?, frontend-specialist?, test-engineer?, validator?]
-  primary_skills: [system-design, system-design]
-  supporting_skills: [code-review?, unit-testing?]
+  primary_skills: [legacy-modernizer, system-design]
+  supporting_skills: [static-analysis?, testing-patterns?]
   migration:
     from: <string>
     to: <string>
@@ -73,4 +72,4 @@ MIGRATE_WORKFLOW_RESULT:
     performance_impact: <string>
   doc_impact: none | tech | rules | both
   follow_up_items: [<string>] | []
-```
+```

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

@@ -1,9 +1,16 @@
 ---
-command: "/mobile"
+name: mobile
 description: "Drive mobile implementation decisions for Flutter/cross-platform behavior and reliability."
-triggers: ["mobile", "flutter", "ios", "android", "navigation"]
+license: MIT
+metadata:
+  author: cubis-foundry
+  route-kind: "workflow"
+  route-id: "mobile"
+  platform: "Codex"
+  command: "/mobile"
+compatibility: Codex
 ---
-
+# mobile Workflow
 # Mobile Workflow
 
 ## When to use
@@ -20,14 +27,14 @@ Use this for mobile app development, Flutter architecture, Stitch-driven mobile
 
 - This workflow file, active platform rules, and selected agents or skills guide execution.
 - Attach platform targets (iOS, Android, both), Flutter version, and relevant screen/feature context.
-- Read `ENGINEERING_RULES.md` and `TECH.md` before implementing non-trivial mobile work so screens and features follow the declared architecture and design-system rules.
+- Read `ENGINEERING_RULES.md` and `docs/foundation/TECH.md` before implementing non-trivial mobile work so screens and features follow the declared architecture and design-system rules. Check `docs/foundation/PRODUCT.md` for `## Domain Glossary` to use consistent terminology.
 
 ## Skill Routing
 
-- Primary skills: `expo-app`, `react-native`
-- Supporting skills (optional): `stitch`, `frontend-design`, `expo-app`, `expo-app`, `expo-app`, `expo-app`, `expo-app`, `expo-app`, `expo-app`, `expo-app`, `expo-app`, `swift-best-practices`, `kotlin-best-practices`
-- Start with `expo-app` for feature implementation and `react-native` for UX patterns. Add framework-specific Flutter skill when applicable. Add `frontend-design` for multi-language support.
-- When the request starts from Stitch artifacts or a design sync, load `stitch` first and then pair it with `react-native` plus the narrowest mobile implementation skill for the target stack.
+- Primary skills: `flutter-feature`, `mobile-design`
+- Supporting skills (optional): `stitch`, `i18n-localization`, `flutter-riverpod`, `flutter-go-router`, `flutter-design-system`, `flutter-testing`, `flutter-drift`, `flutter-offline-sync`, `flutter-state-machine`, `flutter-repository`, `dart-pro`, `swift-pro`, `kotlin-pro`
+- Start with `flutter-feature` for feature implementation and `mobile-design` for UX patterns. Add framework-specific Flutter skill when applicable. Add `i18n-localization` for multi-language support.
+- When the request starts from Stitch artifacts or a design sync, load `stitch` first and then pair it with `mobile-design` plus the narrowest mobile implementation skill for the target stack.
 
 ## Workflow steps
 
@@ -52,8 +59,8 @@ Use this for mobile app development, Flutter architecture, Stitch-driven mobile
 MOBILE_WORKFLOW_RESULT:
   primary_agent: mobile-developer
   supporting_agents: [frontend-specialist?, test-engineer?]
-  primary_skills: [expo-app, react-native]
-  supporting_skills: [stitch?, frontend-design?, expo-app?, expo-app?, <flutter-specific>?]
+  primary_skills: [flutter-feature, mobile-design]
+  supporting_skills: [stitch?, i18n-localization?, flutter-riverpod?, flutter-testing?, <flutter-specific>?]
   implementation:
     platforms: [ios, android]
     architecture_decisions: [<string>]
@@ -66,4 +73,4 @@ MOBILE_WORKFLOW_RESULT:
     android: [<string>] | []
   doc_impact: none | tech | rules | both
   follow_up_items: [<string>] | []
-```
+```

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

@@ -1,16 +1,16 @@
 ---
-command: "/onboard"
+name: onboard
 description: "Survey an unfamiliar codebase, map its architecture, identify patterns and conventions, and produce a structured orientation report for new contributors."
-triggers:
-  [
-    "onboard",
-    "explore codebase",
-    "understand project",
-    "new to this repo",
-    "codebase survey",
-  ]
+license: MIT
+metadata:
+  author: cubis-foundry
+  route-kind: "workflow"
+  route-id: "onboard"
+  platform: "Codex"
+  command: "/onboard"
+compatibility: Codex
 ---
-
+# onboard Workflow
 # Onboard Workflow
 
 ## When to use
@@ -27,13 +27,13 @@ Use this when joining a new project, exploring an unfamiliar codebase, or prepar
 
 - This workflow file, active platform rules, and selected agents or skills guide execution.
 - Provide the repo URL, focus areas, and any specific questions to answer during onboarding.
-- Read `ENGINEERING_RULES.md` first and `TECH.md` next when present so onboarding distinguishes the intended contract from current implementation reality.
+- Read `ENGINEERING_RULES.md` first, then `docs/foundation/TECH.md`, `docs/foundation/PRODUCT.md`, and `docs/foundation/ARCHITECTURE.md` when present so onboarding distinguishes the intended contract from current implementation reality. Use the `## Domain Glossary` in PRODUCT.md to learn project-specific terms, and `## Build And Validation` in TECH.md to set up the local environment.
 
 ## Skill Routing
 
 - Primary skills: `deep-research`, `system-design`
-- Supporting skills (optional): `system-design`, `database-design`, `typescript-best-practices`, `javascript-best-practices`, `python-best-practices`
-- Start with `deep-research` for systematic exploration and `system-design` for architecture mapping. Add `system-design` for undocumented systems. Prefer repo evidence first; use external sources only when setup or dependency behavior cannot be confirmed locally.
+- Supporting skills (optional): `legacy-modernizer`, `database-design`, `typescript-pro`, `javascript-pro`, `python-pro`
+- Start with `deep-research` for systematic exploration and `system-design` for architecture mapping. Add `legacy-modernizer` for undocumented systems. Prefer repo evidence first; use external sources only when setup or dependency behavior cannot be confirmed locally.
 
 ## Workflow steps
 
@@ -57,7 +57,7 @@ ONBOARD_WORKFLOW_RESULT:
   primary_agent: researcher
   supporting_agents: [code-archaeologist?, backend-specialist?, frontend-specialist?]
   primary_skills: [deep-research, system-design]
-  supporting_skills: [system-design?, database-design?]
+  supporting_skills: [legacy-modernizer?, database-design?]
   project_overview:
     purpose: <string>
     tech_stack: [<string>]
@@ -67,4 +67,4 @@ ONBOARD_WORKFLOW_RESULT:
   development_setup: [<step>]
   dependencies: [<string>]
   knowledge_gaps: [<string>] | []
-```
+```