@cubis/foundry 0.3.83 → 0.3.84

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

@@ -1,76 +0,0 @@
----
-name: backend
-description: "Drive backend architecture, API operations, and Postman-oriented execution with API, data, and reliability focus."
-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
-
-Use this for backend architecture, API design, service implementation, or Postman-oriented API operations.
-
-## Routing
-
-- Primary specialist: `@backend-specialist`
-- Database support: `@database-architect`
-- Security review: `@security-auditor`
-- Verification support: `@test-engineer`
-
-## Context notes
-
-- This workflow file, active platform rules, and selected agents or skills guide execution.
-- Attach API specifications, schema diagrams, Postman collections, and relevant service code.
-- Read `ENGINEERING_RULES.md` and `TECH.md` before changing service boundaries or shared backend structure.
-
-## Skill Routing
-
-- 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
-
-1. Clarify API contracts and data model requirements.
-2. Design or review schema and service boundaries.
-3. Implement backend logic with proper error handling and validation.
-4. Write integration tests covering happy path and error cases.
-5. Review for security, performance, and reliability.
-6. Set `doc_impact` if the change alters service boundaries, shared contracts, or operational shape.
-
-## Verification
-
-- API contracts match specification.
-- All endpoints have input validation and error handling.
-- Integration tests cover happy path and key error cases.
-- No N+1 queries or unindexed access patterns.
-- Auth applied correctly to protected endpoints.
-
-## Output Contract
-
-```yaml
-BACKEND_WORKFLOW_RESULT:
-  primary_agent: backend-specialist
-  supporting_agents: [database-architect?, security-auditor?, test-engineer?]
-  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>] | []
-    schema_changes: [<string>] | []
-  implementation:
-    files_changed: [<path>]
-    tests_added: [<path>]
-  doc_impact: none | tech | rules | both
-  verification:
-    checks_run: [<command-or-test>]
-    evidence: [<string>]
-  follow_up_items: [<string>] | []
-```

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

@@ -1,73 +0,0 @@
----
-name: create
-description: "Implement feature work with minimal blast radius and clear verification checkpoints."
-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
-
-Use this for net-new implementation after design is stable.
-
-## Routing
-
-- Primary coordinator: `@orchestrator`
-- Backend implementation: `@backend-specialist`
-- Frontend implementation: `@frontend-specialist`
-- Mobile implementation: `@mobile-developer`
-- Verification support: `@test-engineer`
-
-## Context notes
-
-- This workflow file, active platform rules, and selected agents or skills guide execution.
-- Attach logs, screenshots, failing output, and relevant paths when context is incomplete.
-- Read `ENGINEERING_RULES.md` first and `TECH.md` next for non-trivial work so new code follows the declared architecture and design-system rules.
-
-## Skill Routing
-
-- 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.
-
-## Workflow steps
-
-1. Confirm target files and contracts.
-2. Implement smallest coherent increment.
-3. Validate behavior with focused tests.
-4. Capture `doc_impact` when the feature changes architecture, boundaries, scale, or design-system rules.
-5. Capture remaining gaps and follow-ups.
-
-## Verification
-
-- Run focused checks/tests for the changed scope.
-- Confirm no regressions in adjacent behavior.
-- Note any gaps that were not validated.
-
-## Output Contract
-
-```yaml
-CREATE_WORKFLOW_RESULT:
-  primary_agent: orchestrator
-  supporting_agents: [backend-specialist?, frontend-specialist?, mobile-developer?, test-engineer?]
-  primary_skills: [<dominant-language-skill>]
-  supporting_skills: [stitch?, <framework-specific-skills-used>]
-  implemented_scope:
-    summary: <string>
-    changed_artifacts: [<path-or-artifact>]
-  behavioral_impact: [<string>]
-  doc_impact: none | tech | rules | both
-  verification:
-    checks_run: [<command-or-test>]
-    evidence: [<string>]
-    gaps: [<string>] | []
-  follow_up_items: [<string>] | []
-```

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

@@ -1,72 +0,0 @@
----
-name: database
-description: "Design or review schema, queries, and migrations with performance and integrity controls."
-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
-
-Use this for schema design, query optimization, migration planning, or database architecture decisions.
-
-## Routing
-
-- Primary specialist: `@database-architect`
-- Implementation support: `@backend-specialist`
-- Verification support: `@test-engineer`
-
-## Context notes
-
-- This workflow file, active platform rules, and selected agents or skills guide execution.
-- Attach existing schema, migration history, query patterns, and performance requirements.
-- Read `ENGINEERING_RULES.md` and `TECH.md` before changing data ownership, persistence boundaries, or shared schema conventions.
-
-## Skill Routing
-
-- 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
-
-1. Understand current schema and data model.
-2. Design or review proposed changes with normalization analysis.
-3. Plan migration with rollback strategy.
-4. Optimize queries and indexes for known access patterns.
-5. Validate data integrity constraints.
-6. Set `doc_impact` if the change alters data boundaries, core entities, or persistence patterns that future work should follow.
-
-## Verification
-
-- Schema changes maintain referential integrity.
-- Migrations are reversible or have documented rollback plan.
-- EXPLAIN output reviewed for performance-sensitive queries.
-- No breaking changes to existing consumers without migration plan.
-
-## Output Contract
-
-```yaml
-DATABASE_WORKFLOW_RESULT:
-  primary_agent: database-architect
-  supporting_agents: [backend-specialist?, test-engineer?]
-  primary_skills: [database-design, database-optimizer, database-design]
-  supporting_skills: [<engine-specific-skill>?, drizzle-expert?]
-  schema_changes:
-    tables_affected: [<string>]
-    migration_plan: <string>
-    rollback_plan: <string>
-  query_optimization:
-    queries_reviewed: <number>
-    indexes_recommended: [<string>] | []
-  doc_impact: none | tech | rules | both
-  integrity_checks: [<string>]
-  follow_up_items: [<string>] | []
-```

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

@@ -1,69 +0,0 @@
----
-name: devops
-description: "Plan and execute deployment, CI/CD, incident response, and operational safety changes with rollback controls."
-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
-
-Use this for deployment automation, CI/CD pipeline changes, incident response, or infrastructure operations.
-
-## Routing
-
-- Primary specialist: `@devops-engineer`
-- Reliability support: `@sre-engineer`
-- Verification support: `@validator`
-
-## Context notes
-
-- This workflow file, active platform rules, and selected agents or skills guide execution.
-- Attach deployment targets, pipeline configs, incident details, and infrastructure specs.
-
-## Skill Routing
-
-- 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
-
-1. Assess current state and change scope.
-2. Plan change with rollback strategy.
-3. Apply change in staged manner (dev → staging → production).
-4. Verify health at each stage before proceeding.
-5. Document operational procedures and runbooks.
-
-## Verification
-
-- Change applied successfully with no service degradation.
-- Rollback procedure verified or documented.
-- Monitoring confirms normal operation after change.
-- Runbook updated for new procedures.
-
-## Output Contract
-
-```yaml
-DEVOPS_WORKFLOW_RESULT:
-  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>
-    rollback_plan: <string>
-  execution:
-    stages_completed: [<string>]
-    health_checks: [<string>]
-  operational_docs: [<string>] | []
-  follow_up_items: [<string>] | []
-```

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

@@ -1,76 +0,0 @@
----
-name: implement-track
-description: "Execute large work in milestones with explicit quality gates and status updates."
-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
-
-Use this for large-scale implementation work that spans multiple sessions or milestones and needs progress tracking with quality gates.
-
-## Routing
-
-- Primary coordinator: `@orchestrator`
-- Implementation agents: determined by task domain
-- Quality gate: `@validator`
-
-## Context notes
-
-- 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 `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-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
-
-1. Review implementation plan and confirm milestone boundaries.
-2. Execute current milestone with focused implementation.
-3. Run quality gate validation at milestone completion.
-4. Update progress tracking and capture status.
-5. Adjust remaining plan, spec traceability, and doc refresh needs based on learnings.
-6. Proceed to next milestone or report completion.
-
-## Verification
-
-- Each milestone has clear acceptance criteria that are verified.
-- Quality gate passed before proceeding to next milestone.
-- Progress tracker updated with evidence of completion.
-- Remaining milestones adjusted for any scope changes.
-
-## Output Contract
-
-```yaml
-IMPLEMENT_TRACK_WORKFLOW_RESULT:
-  primary_agent: orchestrator
-  supporting_agents: [<milestone-agents>]
-  primary_skills: [system-design, api-design]
-  supporting_skills: [database-design?, typescript-pro?, javascript-pro?, python-pro?, golang-pro?, react-expert?, nextjs-developer?]
-  milestones:
-    - id: <milestone-id>
-      description: <string>
-      status: completed | in_progress | pending
-      acceptance_criteria_met: [<string>]
-      validation_evidence: <string>
-  overall_progress: <percentage>
-  scope_changes: [<string>] | []
-  spec_id: <string> | null
-  spec_root: docs/specs/<spec-id> | null
-  traceability_status: complete | partial | blocked
-  doc_impact: none | tech | rules | both
-  follow_up_items: [<string>] | []
-```

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

@@ -1,75 +0,0 @@
----
-name: migrate
-description: "Plan and execute technology migrations, framework upgrades, and dependency updates with rollback safety, incremental verification, and zero-downtime transition."
-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
-
-Use this for technology migrations, framework upgrades, dependency updates, or major version transitions.
-
-## Routing
-
-- Primary specialist: `@code-archaeologist`
-- Implementation support: `@backend-specialist`, `@frontend-specialist`
-- Verification support: `@test-engineer`, `@validator`
-
-## Context notes
-
-- 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 `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: `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
-
-1. Assess current state and migration target.
-2. Map breaking changes and affected code paths.
-3. Plan incremental migration steps with rollback points.
-4. Execute migration one step at a time with verification.
-5. Update tests and documentation for new patterns.
-6. Set `doc_impact` when the migration changes architecture, deployment shape, boundaries, or design-system rules.
-7. Verify full system behavior after migration complete.
-
-## Verification
-
-- All breaking changes addressed.
-- Tests pass on migrated code.
-- Rollback tested at each migration step.
-- No degradation in performance or functionality.
-- Documentation updated for new patterns.
-
-## Output Contract
-
-```yaml
-MIGRATE_WORKFLOW_RESULT:
-  primary_agent: code-archaeologist
-  supporting_agents: [backend-specialist?, frontend-specialist?, test-engineer?, validator?]
-  primary_skills: [legacy-modernizer, system-design]
-  supporting_skills: [static-analysis?, testing-patterns?]
-  migration:
-    from: <string>
-    to: <string>
-    breaking_changes: [<string>]
-    steps_completed: [<string>]
-    rollback_points: [<string>]
-  verification:
-    tests_passed: true | false
-    performance_impact: <string>
-  doc_impact: none | tech | rules | both
-  follow_up_items: [<string>] | []
-```

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

@@ -1,76 +0,0 @@
----
-name: mobile
-description: "Drive mobile implementation decisions for Flutter/cross-platform behavior and reliability."
-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
-
-Use this for mobile app development, Flutter architecture, Stitch-driven mobile screen handoff, native integrations, or platform-specific behavior.
-
-## Routing
-
-- Primary specialist: `@mobile-developer`
-- Design support: `@frontend-specialist`
-- Verification support: `@test-engineer`
-
-## Context notes
-
-- 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 `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: `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
-
-1. Clarify platform targets and feature requirements.
-2. Design architecture with platform-appropriate patterns.
-3. Implement with consideration for iOS/Android differences.
-4. Write widget and integration tests.
-5. Review for platform-specific edge cases and UX conventions.
-6. Set `doc_impact` if the feature changes navigation, shared UI rules, or mobile architecture conventions.
-
-## Verification
-
-- Runs correctly on both target platforms.
-- Platform-specific conventions respected (iOS/Android).
-- Touch targets and gesture feedback appropriate.
-- Widget tests cover core behavior.
-- Offline behavior tested if applicable.
-
-## Output Contract
-
-```yaml
-MOBILE_WORKFLOW_RESULT:
-  primary_agent: mobile-developer
-  supporting_agents: [frontend-specialist?, test-engineer?]
-  primary_skills: [flutter-feature, mobile-design]
-  supporting_skills: [stitch?, i18n-localization?, flutter-riverpod?, flutter-testing?, <flutter-specific>?]
-  implementation:
-    platforms: [ios, android]
-    architecture_decisions: [<string>]
-    changed_artifacts: [<path>]
-  testing:
-    widget_tests: [<path>]
-    integration_tests: [<path>] | []
-  platform_notes:
-    ios: [<string>] | []
-    android: [<string>] | []
-  doc_impact: none | tech | rules | both
-  follow_up_items: [<string>] | []
-```

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

@@ -1,70 +0,0 @@
----
-name: onboard
-description: "Survey an unfamiliar codebase, map its architecture, identify patterns and conventions, and produce a structured orientation report for new contributors."
-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
-
-Use this when joining a new project, exploring an unfamiliar codebase, or preparing orientation material.
-
-## Routing
-
-- Primary specialist: `@researcher`
-- Architecture mapping: `@code-archaeologist`
-- Domain specialists as needed: `@backend-specialist`, `@frontend-specialist`
-
-## Context notes
-
-- 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, 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): `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
-
-1. Survey the project structure — directories, entry points, and configuration.
-2. Map the architecture — components, data flow, and integration points.
-3. Identify patterns — naming conventions, design patterns, and coding standards.
-4. Document dependencies — external services, databases, and APIs.
-5. Produce orientation report with development setup instructions.
-
-## Verification
-
-- All major components identified and documented.
-- Development setup instructions verified (can be followed by a newcomer).
-- Architecture diagram or description covers main data flows.
-- Key patterns and conventions explicitly documented.
-
-## Output Contract
-
-```yaml
-ONBOARD_WORKFLOW_RESULT:
-  primary_agent: researcher
-  supporting_agents: [code-archaeologist?, backend-specialist?, frontend-specialist?]
-  primary_skills: [deep-research, system-design]
-  supporting_skills: [legacy-modernizer?, database-design?]
-  project_overview:
-    purpose: <string>
-    tech_stack: [<string>]
-    architecture: <string>
-  key_components: [<string>]
-  patterns_and_conventions: [<string>]
-  development_setup: [<step>]
-  dependencies: [<string>]
-  knowledge_gaps: [<string>] | []
-```

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

@@ -1,78 +0,0 @@
----
-name: orchestrate
-description: "Coordinate multiple specialists to solve cross-cutting tasks with explicit ownership, validation gates, and repeat-until-good iteration."
-license: MIT
-metadata:
-  author: cubis-foundry
-  route-kind: "workflow"
-  route-id: "orchestrate"
-  platform: "Codex"
-  command: "/orchestrate"
-compatibility: Codex
----
-# orchestrate Workflow
-# Orchestrate Workflow
-
-## When to use
-
-Use this when a task spans multiple domains (backend + frontend, security + infrastructure, etc.) and requires coordinated specialist work with validation between steps.
-
-## Routing
-
-- Primary coordinator: `@orchestrator`
-- Specialist routing determined by task decomposition — delegates to `@backend-specialist`, `@frontend-specialist`, `@database-architect`, `@security-auditor`, `@devops-engineer`, `@test-engineer`, `@mobile-developer`, or other specialist agents as needed.
-- Validation support: `@validator`
-
-## Context notes
-
-- This workflow file, active platform rules, and selected agents or skills guide execution.
-- Attach the full task description, constraints, acceptance criteria, and relevant context when starting.
-- Read `ENGINEERING_RULES.md` and `docs/foundation/TECH.md` before decomposing non-trivial work. Check `docs/foundation/TECH.md` for build/validation commands and `docs/foundation/PRODUCT.md` for domain glossary. Then reuse any existing `docs/specs/<spec-id>/` pack as the handoff source of truth.
-
-## Skill Routing
-
-- Primary skills: `system-design`, `api-design`
-- Supporting skills (optional): `database-design`, `deep-research`, `mcp-server-builder`, `openai-docs`, `prompt-engineering`, `skill-creator`
-- Start with `system-design` for system design coordination and `api-design` for integration contracts. Add `deep-research` before implementation when the coordination challenge depends on fresh external facts or public comparison.
-
-## Workflow steps
-
-1. Decompose the task into discrete work items with acceptance criteria.
-2. Identify dependencies and determine execution order (DAG).
-3. Delegate each task to the best specialist agent with full context.
-4. Validate each deliverable against acceptance criteria via independent validation.
-5. Iterate on failed validations with specific feedback (max 3 iterations).
-6. Surface `doc_impact` when the coordinated work changes architecture, boundaries, scale, or the design system.
-7. Integrate outputs, verify cross-task consistency, and report results.
-
-## Verification
-
-- Each task validated independently against its acceptance criteria.
-- Cross-task consistency check after integration.
-- Run any applicable automated tests or checks.
-- Final validation pass on combined result.
-
-## Output Contract
-
-```yaml
-ORCHESTRATE_WORKFLOW_RESULT:
-  primary_agent: orchestrator
-  supporting_agents: [<specialist-agents-used>]
-  primary_skills: [system-design, api-design]
-  supporting_skills: [<supporting-skills-used>]
-  spec_id: <string> | null
-  spec_root: docs/specs/<spec-id> | null
-  task_count: <number>
-  completed: <number>
-  failed: <number>
-  tasks:
-    - id: <task-id>
-      agent: <agent-name>
-      status: completed | failed | skipped
-      iterations: <number>
-      validation_evidence: <string>
-  integration_status: clean | conflicts_resolved | issues_remaining
-  doc_impact: none | tech | rules | both
-  remaining_risks: [<string>] | []
-  follow_up_actions: [<string>] | []
-```