@cubis/foundry 0.3.81 → 0.3.83

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

@@ -1,18 +0,0 @@
-# Workflow Prompt: /vercel
-
-Drive Vercel implementation and operations via vercel-expert with deployment, runtime, security, and observability guardrails.
-
-Use this prompt with the matching workflow file:
-- Workflow: ../copilot/workflows/vercel.md
-
-Execution contract:
-1. Treat route selection as already resolved by this prompt; 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: `nextjs`, `ci-cd-pipeline`, `performance-testing`, `react`, `frontend-design`, `javascript-best-practices`, `typescript-best-practices`.
-- Local skill file hints if installed: `.github/skills/nextjs/SKILL.md`, `.github/skills/ci-cd-pipeline/SKILL.md`, `.github/skills/performance-testing/SKILL.md`, `.github/skills/react/SKILL.md`, `.github/skills/frontend-design/SKILL.md`, `.github/skills/javascript-best-practices/SKILL.md`, `.github/skills/typescript-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.

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

@@ -1,88 +0,0 @@
----
-command: "/architecture"
-description: "Refresh the core project foundation docs in docs/foundation/PRODUCT.md, docs/foundation/ARCHITECTURE.md, docs/foundation/TECH.md, and ADR scaffolds with explicit structure, product context, testing, and flow guidance."
-triggers:
-  [
-    "architecture",
-    "design system",
-    "adr",
-    "clean architecture",
-    "system map",
-    "app structure",
-    "technical governance",
-    "flow diagram",
-  ]
----
-
-# 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/PRODUCT.md`, `docs/foundation/ARCHITECTURE.md`, and `docs/foundation/TECH.md` in that order if they exist.
-4. Update the managed foundation sections in `docs/foundation/PRODUCT.md`, `docs/foundation/ARCHITECTURE.md`, and `docs/foundation/TECH.md`.
-5. Make `docs/foundation/ARCHITECTURE.md` explicitly state the architecture type in use and include a folder-structure guide for the important apps/packages/directories.
-6. Add or refresh Mermaid diagrams and flow narratives inside `docs/foundation/ARCHITECTURE.md` or `docs/foundation/TECH.md` when they clarify system behavior.
-7. 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.
-8. 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/PRODUCT.md` captures intent, `docs/foundation/ARCHITECTURE.md` captures accepted structure, and `docs/foundation/TECH.md` is the developer-facing technical map. Keep them aligned but not redundant.
-- Favor a lean arc42/C4 style: clear scope, boundaries, building blocks, runtime flows, 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.
-- Prefer stable section headings over ad hoc prose so future refreshes stay clean and easy to diff.
-- Preserve manual content outside the managed foundation sections.
-- Mark non-applicable sections explicitly instead of silently omitting them.
-
-## Verification
-
-- Managed foundation sections exist in the target docs under `docs/foundation/`.
-- Product intent, architecture style, dependency rules, and technical guidance are explicit.
-- `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.
-- 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:
-    product_doc: docs/foundation/PRODUCT.md
-    architecture_doc: docs/foundation/ARCHITECTURE.md
-    tech_doc: docs/foundation/TECH.md
-    adr_dir: docs/foundation/adr
-  files_updated: [docs/foundation/PRODUCT.md, docs/foundation/ARCHITECTURE.md, docs/foundation/TECH.md]
-  architecture_contract:
-    style: <string>
-    dependency_rules: [<string>]
-    design_system_source: <string>
-  technical_snapshot:
-    topology: [<string>]
-    flows: [<string>]
-    diagrams: [<string>] | []
-  doc_impact: rules | tech | both
-  next_actions: [<string>] | []
-```

package/workflows/workflows/agent-environment-setup/platforms/gemini/workflows/accessibility.md

@@ -1,77 +0,0 @@
----
-command: "/accessibility"
-description: "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."
-triggers:
-  [
-    "accessibility",
-    "a11y",
-    "wcag",
-    "aria",
-    "screen reader",
-    "keyboard navigation",
-  ]
----
-
-# Accessibility Workflow
-
-## When to use
-
-Use this for accessibility audits, WCAG compliance review, or improving accessible user experience.
-
-## Routing
-
-- Primary specialist: `the frontend-specialist posture`
-- Verification support: `the test-engineer posture`
-- Review support: `the validator posture`
-
-## 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: `code-review`, `frontend-design`
-- Supporting skills (optional): `frontend-design`, `performance-testing`, `react`, `nextjs`, `frontend-design`, `playwright-interactive`, `typescript-best-practices`, `javascript-best-practices`
-- Start with `code-review` for WCAG compliance checks. Add `frontend-design` for accessible design patterns. Add `frontend-design` 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: [code-review, frontend-design]
-  supporting_skills: [frontend-design?, performance-testing?, playwright-interactive?]
-  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>] | []
-```
-
-> **Gemini note:** Commands route into workflow files under `.gemini/workflows/`. Specialists are inline postures coordinated through GEMINI.md guidance, not separate agent artifacts.

package/workflows/workflows/agent-environment-setup/platforms/gemini/workflows/architecture.md

@@ -1,90 +0,0 @@
----
-command: "/architecture"
-description: "Refresh the core project foundation docs in docs/foundation/PRODUCT.md, docs/foundation/ARCHITECTURE.md, docs/foundation/TECH.md, and ADR scaffolds with explicit structure, product context, testing, and flow guidance."
-triggers:
-  [
-    "architecture",
-    "design system",
-    "adr",
-    "clean architecture",
-    "system map",
-    "app structure",
-    "technical governance",
-    "flow diagram",
-  ]
----
-
-# 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: `the project-planner posture`
-- Documentation support: `the documentation-writer posture`
-- Research support: `the researcher posture`
-- Domain validation: `the backend-specialist posture`, `the frontend-specialist posture`, `the database-architect posture`
-
-## 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/PRODUCT.md`, `docs/foundation/ARCHITECTURE.md`, and `docs/foundation/TECH.md` in that order if they exist.
-4. Update the managed foundation sections in `docs/foundation/PRODUCT.md`, `docs/foundation/ARCHITECTURE.md`, and `docs/foundation/TECH.md`.
-5. Make `docs/foundation/ARCHITECTURE.md` explicitly state the architecture type in use and include a folder-structure guide for the important apps/packages/directories.
-6. Add or refresh Mermaid diagrams and flow narratives inside `docs/foundation/ARCHITECTURE.md` or `docs/foundation/TECH.md` when they clarify system behavior.
-7. 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.
-8. 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/PRODUCT.md` captures intent, `docs/foundation/ARCHITECTURE.md` captures accepted structure, and `docs/foundation/TECH.md` is the developer-facing technical map. Keep them aligned but not redundant.
-- Favor a lean arc42/C4 style: clear scope, boundaries, building blocks, runtime flows, 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.
-- Prefer stable section headings over ad hoc prose so future refreshes stay clean and easy to diff.
-- Preserve manual content outside the managed foundation sections.
-- Mark non-applicable sections explicitly instead of silently omitting them.
-
-## Verification
-
-- Managed foundation sections exist in the target docs under `docs/foundation/`.
-- Product intent, architecture style, dependency rules, and technical guidance are explicit.
-- `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.
-- 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:
-    product_doc: docs/foundation/PRODUCT.md
-    architecture_doc: docs/foundation/ARCHITECTURE.md
-    tech_doc: docs/foundation/TECH.md
-    adr_dir: docs/foundation/adr
-  files_updated: [docs/foundation/PRODUCT.md, docs/foundation/ARCHITECTURE.md, docs/foundation/TECH.md]
-  architecture_contract:
-    style: <string>
-    dependency_rules: [<string>]
-    design_system_source: <string>
-  technical_snapshot:
-    topology: [<string>]
-    flows: [<string>]
-    diagrams: [<string>] | []
-  doc_impact: rules | tech | both
-  next_actions: [<string>] | []
-```
-
-> **Gemini note:** Commands route into workflow files under `.gemini/workflows/`. Specialists are inline postures coordinated through GEMINI.md guidance, not separate agent artifacts.

package/workflows/workflows/agent-environment-setup/platforms/gemini/workflows/backend.md

@@ -1,86 +0,0 @@
----
-command: "/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",
-  ]
----
-
-# Backend Workflow
-
-## When to use
-
-Use this for backend architecture, API design, service implementation, or Postman-oriented API operations.
-
-## Routing
-
-- Primary specialist: `the backend-specialist posture`
-- Database support: `the database-architect posture`
-- Security review: `the security-auditor posture`
-- Verification support: `the test-engineer posture`
-
-## 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-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.
-
-## 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-design, javascript-best-practices]
-  supporting_skills: [owasp-security-review?, 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>] | []
-```
-
-> **Gemini note:** Commands route into workflow files under `.gemini/workflows/`. Specialists are inline postures coordinated through GEMINI.md guidance, not separate agent artifacts.

package/workflows/workflows/agent-environment-setup/platforms/gemini/workflows/create.md

@@ -1,68 +0,0 @@
----
-command: "/create"
-description: "Implement feature work with minimal blast radius and clear verification checkpoints."
-triggers: ["create", "build", "implement", "feature", "develop"]
----
-
-# Create Workflow
-
-## When to use
-
-Use this for net-new implementation after design is stable.
-
-## Routing
-
-- Primary coordinator: `the orchestrator posture`
-- Backend implementation: `the backend-specialist posture`
-- Frontend implementation: `the frontend-specialist posture`
-- Mobile implementation: `the mobile-developer posture`
-- Verification support: `the test-engineer posture`
-
-## 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-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`
-- 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>] | []
-```
-
-> **Gemini note:** Commands route into workflow files under `.gemini/workflows/`. Specialists are inline postures coordinated through GEMINI.md guidance, not separate agent artifacts.

package/workflows/workflows/agent-environment-setup/platforms/gemini/workflows/database.md

@@ -1,67 +0,0 @@
----
-command: "/database"
-description: "Design or review schema, queries, and migrations with performance and integrity controls."
-triggers: ["database", "sql", "schema", "migration", "index"]
----
-
-# Database Workflow
-
-## When to use
-
-Use this for schema design, query optimization, migration planning, or database architecture decisions.
-
-## Routing
-
-- Primary specialist: `the database-architect posture`
-- Implementation support: `the backend-specialist posture`
-- Verification support: `the test-engineer posture`
-
-## 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-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.
-
-## 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-design, database-design]
-  supporting_skills: [<engine-specific-skill>?, drizzle-orm?]
-  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>] | []
-```
-
-> **Gemini note:** Commands route into workflow files under `.gemini/workflows/`. Specialists are inline postures coordinated through GEMINI.md guidance, not separate agent artifacts.

package/workflows/workflows/agent-environment-setup/platforms/gemini/workflows/debug.md

@@ -1,63 +0,0 @@
----
-command: "/debug"
-description: "Isolate root cause quickly, apply the smallest safe remediation, and leave behind regression evidence."
-triggers: ["debug", "bug", "error", "incident", "stack trace"]
----
-
-# Debug Workflow
-
-## When to use
-
-Use this when behavior is failing, inconsistent, flaky, or only reproducible under certain conditions.
-
-## Routing
-
-- Primary specialist: `the debugger posture`
-- Domain implementation support: `the backend-specialist posture`, `the frontend-specialist posture`
-- Verification support: `the test-engineer posture`
-
-## 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: `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.
-
-## 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: [systematic-debugging, observability]
-  supporting_skills: [unit-testing?, <language-skill>?, integration-testing?, playwright-interactive?]
-  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>] | []
-```
-
-> **Gemini note:** Commands route into workflow files under `.gemini/workflows/`. Specialists are inline postures coordinated through GEMINI.md guidance, not separate agent artifacts.

package/workflows/workflows/agent-environment-setup/platforms/gemini/workflows/devops.md

@@ -1,78 +0,0 @@
----
-command: "/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",
-  ]
----
-
-# DevOps Workflow
-
-## When to use
-
-Use this for deployment automation, CI/CD pipeline changes, incident response, or infrastructure operations.
-
-## Routing
-
-- Primary specialist: `the ci-cd-pipeline posture`
-- Reliability support: `the observability posture`
-- Verification support: `the validator posture`
-
-## 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: `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.
-
-## 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: ci-cd-pipeline
-  supporting_agents: [observability?, validator?]
-  primary_skills: [ci-cd-pipeline, ci-cd-pipeline, kubernetes-deploy]
-  supporting_skills: [observability?, observability?, ci-cd-pipeline?]
-  change:
-    description: <string>
-    blast_radius: <string>
-    rollback_plan: <string>
-  execution:
-    stages_completed: [<string>]
-    health_checks: [<string>]
-  operational_docs: [<string>] | []
-  follow_up_items: [<string>] | []
-```
-
-> **Gemini note:** Commands route into workflow files under `.gemini/workflows/`. Specialists are inline postures coordinated through GEMINI.md guidance, not separate agent artifacts.