@cubis/foundry 0.3.82 → 0.3.83

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

@@ -80,8 +80,15 @@ Load detailed guidance based on context:
 
 ## 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/copilot/prompts/accessibility.prompt.md

@@ -0,0 +1,78 @@
+# Workflow Prompt: /accessibility
+
+Run a structured accessibility audit on web UI code with WCAG 2.2 AA compliance checks, ARIA validation, keyboard navigation testing, and screen reader verification.
+
+Execution contract:
+1. Treat route selection as already resolved by this command; do not begin with skill discovery.
+2. Read `docs/foundation/PRODUCT.md`, `ENGINEERING_RULES.md`, `docs/foundation/ARCHITECTURE.md`, and `docs/foundation/TECH.md` in that order when they exist before non-trivial execution.
+Attached skills:
+- Load these exact skill IDs first: `code-review`, `frontend-design`, `performance-testing`, `react`, `nextjs`, `playwright-interactive`, `typescript-best-practices`, `javascript-best-practices`.
+- Local skill file hints if installed: `.github/skills/code-review/SKILL.md`, `.github/skills/frontend-design/SKILL.md`, `.github/skills/performance-testing/SKILL.md`, `.github/skills/react/SKILL.md`, `.github/skills/nextjs/SKILL.md`, `.github/skills/playwright-interactive/SKILL.md`, `.github/skills/typescript-best-practices/SKILL.md`, `.github/skills/javascript-best-practices/SKILL.md`.
+- Treat the skill bundle as already resolved for this workflow. Do not start with route discovery.
+3. Apply workflow sections in order: When to use, Workflow steps, Context notes, Verification.
+4. Route to the workflow's primary specialist and only add supporting specialists when needed.
+5. If freshness or public comparison matters, run `deep-research` before implementation and use official docs as primary evidence.
+6. Return actions taken, verification evidence, and any gaps.
+
+Workflow source:
+# Accessibility Workflow
+
+## When to use
+
+Use this for accessibility audits, WCAG compliance review, or improving accessible user experience.
+
+## Routing
+
+- Primary specialist: `@frontend-specialist`
+- Verification support: `@test-engineer`
+- Review support: `@validator`
+
+## Context notes
+
+- This workflow file, active platform rules, and selected agents or skills guide execution.
+- Attach the target components, pages, or routes to audit. Include any existing axe or Lighthouse results.
+
+## Skill Routing
+
+- Primary skills: `frontend-code-review`, `frontend-design`
+- Supporting skills (optional): `i18n-localization`, `web-perf`, `react-expert`, `nextjs-developer`, `tailwind-patterns`, `playwright-e2e`, `typescript-pro`, `javascript-pro`
+- Start with `frontend-code-review` for WCAG compliance checks. Add `frontend-design` for accessible design patterns. Add `i18n-localization` for RTL and locale-specific accessibility.
+
+## Workflow steps
+
+1. Inventory components and user flows to audit.
+2. Run automated accessibility checks (axe, Lighthouse).
+3. Manual keyboard navigation and focus management review.
+4. ARIA validation — correct roles, states, and properties.
+5. Screen reader compatibility assessment.
+6. Prioritize findings and provide remediation guidance.
+
+## Verification
+
+- All critical WCAG 2.2 AA violations identified.
+- Keyboard navigation works for all interactive elements.
+- ARIA attributes are semantically correct.
+- Color contrast meets minimum ratios.
+- Focus management is logical and visible.
+
+## Output Contract
+
+```yaml
+ACCESSIBILITY_WORKFLOW_RESULT:
+  primary_agent: frontend-specialist
+  supporting_agents: [test-engineer?, validator?]
+  primary_skills: [frontend-code-review, frontend-design]
+  supporting_skills: [i18n-localization?, web-perf?, playwright-e2e?]
+  audit_scope: [<component-or-route>]
+  findings:
+    - severity: critical | high | medium | low
+      wcag_criterion: <string>
+      element: <string>
+      description: <string>
+      remediation: <string>
+  automated_results:
+    tool: <axe | lighthouse | other>
+    violations: <number>
+    passes: <number>
+  follow_up_items: [<string>] | []
+```

package/workflows/workflows/agent-environment-setup/platforms/copilot/prompts/architecture.prompt.md

@@ -0,0 +1,128 @@
+# Workflow Prompt: /architecture
+
+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.
+
+Execution contract:
+1. Treat route selection as already resolved by this command; do not begin with skill discovery.
+2. Read `docs/foundation/PRODUCT.md`, `docs/foundation/ARCHITECTURE.md`, and `docs/foundation/TECH.md` in that order when they exist before non-trivial execution.
+Attached skills:
+- Load these exact skill IDs first: `architecture-doc`, `system-design`, `tech-doc`, `frontend-design`, `api-design`, `database-design`, `sadd`, `deep-research`.
+- Local skill file hints if installed: `.github/skills/architecture-doc/SKILL.md`, `.github/skills/system-design/SKILL.md`, `.github/skills/tech-doc/SKILL.md`, `.github/skills/frontend-design/SKILL.md`, `.github/skills/api-design/SKILL.md`, `.github/skills/database-design/SKILL.md`, `.github/skills/sadd/SKILL.md`, `.github/skills/deep-research/SKILL.md`.
+- Treat the skill bundle as already resolved for this workflow. Do not start with route discovery.
+3. Apply workflow sections in order: When to use, Workflow steps, Context notes, Verification.
+4. Route to the workflow's primary specialist and only add supporting specialists when needed.
+5. If freshness or public comparison matters, run `deep-research` before implementation and use official docs as primary evidence.
+6. Return actions taken, verification evidence, and any gaps.
+
+Workflow source:
+# 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/copilot/prompts/backend.prompt.md

@@ -0,0 +1,80 @@
+# Workflow Prompt: /backend
+
+Drive backend architecture, API operations, and Postman-oriented execution with API, data, and reliability focus.
+
+Execution contract:
+1. Treat route selection as already resolved by this command; do not begin with skill discovery.
+2. Read `docs/foundation/PRODUCT.md`, `ENGINEERING_RULES.md`, `docs/foundation/ARCHITECTURE.md`, and `docs/foundation/TECH.md` in that order when they exist before non-trivial execution.
+Attached skills:
+- Load these exact skill IDs first: `api-design`, `javascript-best-practices`, `owasp-security-review`, `database-design`, `nestjs`, `fastapi`, `microservices-design`, `drizzle-orm`, `stripe-integration`, `ci-cd-pipeline`, `frontend-design`, `typescript-best-practices`, `python-best-practices`, `golang-best-practices`.
+- Local skill file hints if installed: `.github/skills/api-design/SKILL.md`, `.github/skills/javascript-best-practices/SKILL.md`, `.github/skills/owasp-security-review/SKILL.md`, `.github/skills/database-design/SKILL.md`, `.github/skills/nestjs/SKILL.md`, `.github/skills/fastapi/SKILL.md`, `.github/skills/microservices-design/SKILL.md`, `.github/skills/drizzle-orm/SKILL.md`.
+- Treat the skill bundle as already resolved for this workflow. Do not start with route discovery.
+3. Apply workflow sections in order: When to use, Workflow steps, Context notes, Verification.
+4. Route to the workflow's primary specialist and only add supporting specialists when needed.
+5. If freshness or public comparison matters, run `deep-research` before implementation and use official docs as primary evidence.
+6. Return actions taken, verification evidence, and any gaps.
+
+Workflow source:
+# 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/copilot/prompts/create.prompt.md

@@ -0,0 +1,77 @@
+# Workflow Prompt: /create
+
+Implement feature work with minimal blast radius and clear verification checkpoints.
+
+Execution contract:
+1. Treat route selection as already resolved by this command; do not begin with skill discovery.
+2. Read `docs/foundation/PRODUCT.md`, `ENGINEERING_RULES.md`, `docs/foundation/ARCHITECTURE.md`, and `docs/foundation/TECH.md` in that order when they exist before non-trivial execution.
+Attached skills:
+- Load these exact skill IDs first: `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`, `expo-app`, `swift-best-practices`, `api-design`, `nestjs`, `fastapi`, `drizzle-orm`, `database-design`, `mcp-server-builder`, `stitch`, `react`, `nextjs`, `frontend-design`, `performance-testing`, `skill-creator`, `stripe-integration`, `ci-cd-pipeline`.
+- Local skill file hints if installed: `.github/skills/typescript-best-practices/SKILL.md`, `.github/skills/javascript-best-practices/SKILL.md`, `.github/skills/python-best-practices/SKILL.md`, `.github/skills/golang-best-practices/SKILL.md`, `.github/skills/java-best-practices/SKILL.md`, `.github/skills/csharp-best-practices/SKILL.md`, `.github/skills/kotlin-best-practices/SKILL.md`, `.github/skills/rust-best-practices/SKILL.md`.
+- Treat the skill bundle as already resolved for this workflow. Do not start with route discovery.
+3. Apply workflow sections in order: When to use, Workflow steps, Context notes, Verification.
+4. Route to the workflow's primary specialist and only add supporting specialists when needed.
+5. If freshness or public comparison matters, run `deep-research` before implementation and use official docs as primary evidence.
+6. Return actions taken, verification evidence, and any gaps.
+
+Workflow source:
+# 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/copilot/prompts/database.prompt.md

@@ -0,0 +1,76 @@
+# Workflow Prompt: /database
+
+Design or review schema, queries, and migrations with performance and integrity controls.
+
+Execution contract:
+1. Treat route selection as already resolved by this command; do not begin with skill discovery.
+2. Read `docs/foundation/PRODUCT.md`, `ENGINEERING_RULES.md`, `docs/foundation/ARCHITECTURE.md`, and `docs/foundation/TECH.md` in that order when they exist before non-trivial execution.
+Attached skills:
+- Load these exact skill IDs first: `database-design`, `drizzle-orm`, `typescript-best-practices`, `javascript-best-practices`, `python-best-practices`.
+- Local skill file hints if installed: `.github/skills/database-design/SKILL.md`, `.github/skills/drizzle-orm/SKILL.md`, `.github/skills/typescript-best-practices/SKILL.md`, `.github/skills/javascript-best-practices/SKILL.md`, `.github/skills/python-best-practices/SKILL.md`.
+- Treat the skill bundle as already resolved for this workflow. Do not start with route discovery.
+3. Apply workflow sections in order: When to use, Workflow steps, Context notes, Verification.
+4. Route to the workflow's primary specialist and only add supporting specialists when needed.
+5. If freshness or public comparison matters, run `deep-research` before implementation and use official docs as primary evidence.
+6. Return actions taken, verification evidence, and any gaps.
+
+Workflow source:
+# 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/copilot/prompts/debug.prompt.md

@@ -0,0 +1,72 @@
+# Workflow Prompt: /debug
+
+Isolate root cause quickly, apply the smallest safe remediation, and leave behind regression evidence.
+
+Execution contract:
+1. Treat route selection as already resolved by this command; do not begin with skill discovery.
+2. Read `docs/foundation/PRODUCT.md`, `ENGINEERING_RULES.md`, `docs/foundation/ARCHITECTURE.md`, and `docs/foundation/TECH.md` in that order when they exist before non-trivial execution.
+Attached skills:
+- Load these exact skill IDs first: `systematic-debugging`, `observability`, `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`.
+- Local skill file hints if installed: `.github/skills/systematic-debugging/SKILL.md`, `.github/skills/observability/SKILL.md`, `.github/skills/unit-testing/SKILL.md`, `.github/skills/typescript-best-practices/SKILL.md`, `.github/skills/javascript-best-practices/SKILL.md`, `.github/skills/python-best-practices/SKILL.md`, `.github/skills/golang-best-practices/SKILL.md`, `.github/skills/java-best-practices/SKILL.md`.
+- Treat the skill bundle as already resolved for this workflow. Do not start with route discovery.
+3. Apply workflow sections in order: When to use, Workflow steps, Context notes, Verification.
+4. Route to the workflow's primary specialist and only add supporting specialists when needed.
+5. If freshness or public comparison matters, run `deep-research` before implementation and use official docs as primary evidence.
+6. Return actions taken, verification evidence, and any gaps.
+
+Workflow source:
+# Debug Workflow
+
+## When to use
+
+Use this when behavior is failing, inconsistent, flaky, or only reproducible under certain conditions.
+
+## Routing
+
+- Primary specialist: `@debugger`
+- Domain implementation support: `@backend-specialist`, `@frontend-specialist`
+- Verification support: `@test-engineer`
+
+## Context notes
+
+- This workflow file, active platform rules, and selected agents or skills guide execution.
+- Attach stack traces, request IDs, traces, repro steps, recent diffs, and environment notes when context is incomplete.
+
+## Skill Routing
+
+- 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
+
+1. Reproduce the issue and record expected versus actual behavior.
+2. Narrow the fault domain with the smallest useful evidence.
+3. Fix the confirmed cause with the lowest regression risk.
+4. Add or update the regression proof.
+5. Document any remaining uncertainty or environment-specific gaps.
+
+## Verification
+
+- Re-run the failing scenario first.
+- Run focused regression checks on adjacent high-risk paths.
+- Call out any remaining gaps if the full environment could not be reproduced.
+
+## Output Contract
+
+```yaml
+DEBUG_WORKFLOW_RESULT:
+  primary_agent: debugger
+  supporting_agents: [backend-specialist?, frontend-specialist?, test-engineer?]
+  primary_skills: [debugging-strategies, error-ux-observability]
+  supporting_skills: [testing-patterns?, <language-skill>?, webapp-testing?, playwright-e2e?]
+  reproduction:
+    steps: [<string>]
+    expected_vs_actual: <string>
+  root_cause: <string>
+  remediation:
+    summary: <string>
+    changed_artifacts: [<path-or-artifact>]
+  regression_checks: [<command or test>]
+  follow_up_items: [<string>] | []
+```

package/workflows/workflows/agent-environment-setup/platforms/copilot/prompts/devops.prompt.md

@@ -0,0 +1,73 @@
+# Workflow Prompt: /devops
+
+Plan and execute deployment, CI/CD, incident response, and operational safety changes with rollback controls.
+
+Execution contract:
+1. Treat route selection as already resolved by this command; do not begin with skill discovery.
+2. Read `docs/foundation/PRODUCT.md`, `ENGINEERING_RULES.md`, `docs/foundation/ARCHITECTURE.md`, and `docs/foundation/TECH.md` in that order when they exist before non-trivial execution.
+Attached skills:
+- Load these exact skill IDs first: `ci-cd-pipeline`, `kubernetes-deploy`, `observability`, `git-workflow`, `systematic-debugging`, `typescript-best-practices`, `javascript-best-practices`, `python-best-practices`, `golang-best-practices`.
+- Local skill file hints if installed: `.github/skills/ci-cd-pipeline/SKILL.md`, `.github/skills/kubernetes-deploy/SKILL.md`, `.github/skills/observability/SKILL.md`, `.github/skills/git-workflow/SKILL.md`, `.github/skills/systematic-debugging/SKILL.md`, `.github/skills/typescript-best-practices/SKILL.md`, `.github/skills/javascript-best-practices/SKILL.md`, `.github/skills/python-best-practices/SKILL.md`.
+- Treat the skill bundle as already resolved for this workflow. Do not start with route discovery.
+3. Apply workflow sections in order: When to use, Workflow steps, Context notes, Verification.
+4. Route to the workflow's primary specialist and only add supporting specialists when needed.
+5. If freshness or public comparison matters, run `deep-research` before implementation and use official docs as primary evidence.
+6. Return actions taken, verification evidence, and any gaps.
+
+Workflow source:
+# 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>] | []
+```