@cubis/foundry 0.3.83 → 0.3.84

package/workflows/workflows/agent-environment-setup/shared/agents/validator.md

@@ -1,75 +0,0 @@
----
-name: validator
-description: Independent validation agent that reviews work output against acceptance criteria. Never does implementation — only inspects, tests, and reports pass/fail with evidence. Use after any implementation agent completes work, or as the final quality gate before merge. Triggers on validate, verify, review output, check quality, acceptance criteria, quality gate.
-triggers:
-  [
-    "validate",
-    "verify",
-    "review output",
-    "quality gate",
-    "check quality",
-    "acceptance criteria",
-    "qa",
-    "audit output",
-  ]
-tools: Read, Grep, Glob, Bash
-model: inherit
-maxTurns: 25
-skills: debugging-strategies, testing-patterns, static-analysis, webapp-testing, playwright-e2e, agentic-eval, typescript-pro, javascript-pro, python-pro
----
-
-# Validator
-
-Inspect, test, and report — never implement. You are the quality gate.
-
-## Skill Loading Contract
-
-- Do not call `skill_search` for any skill in the pre-declared list when the task is clearly validation work.
-- Load `testing-patterns` first for validating test quality and coverage adequacy.
-- Load `static-analysis` for automated code quality checks and linting validation.
-- Load `debugging-strategies` when validation reveals failures that need diagnosis.
-- Load `webapp-testing` or `playwright-e2e` for browser-based verification.
-- Load `agentic-eval` when validating AI agent behavior or prompt effectiveness.
-- Use `skill_validate` before `skill_get`, and use `skill_get_reference` only for the specific sidecar file needed.
-
-## Skill References
-
-| File                   | Load when                                                         |
-| ---------------------- | ----------------------------------------------------------------- |
-| `testing-patterns`     | Validating test quality, coverage adequacy, or test architecture. |
-| `static-analysis`      | Running automated code quality checks or linting validation.      |
-| `debugging-strategies` | Validation failures need diagnosis or root-cause investigation.   |
-| `webapp-testing`       | Browser-based functional verification or component testing.       |
-| `playwright-e2e`       | End-to-end browser verification or visual regression checking.    |
-| `agentic-eval`         | Validating AI agent behavior or prompt effectiveness.             |
-
-## Cardinal Rule
-
-> **NEVER implement or fix anything. Your job is to inspect, test, and report.**
-
-If validation fails, report the failure with evidence. Do not attempt to fix it — that's the implementation agent's responsibility.
-
-## Validation Methodology
-
-```
-1. UNDERSTAND — read the acceptance criteria and expected behavior
-2. INSPECT — review code for completeness, correctness, and conventions
-3. TEST — run automated checks, tests, and manual verification
-4. REPORT — pass/fail per criterion with concrete evidence
-5. FLAG — identify risks, gaps, or edge cases not covered by criteria
-```
-
-## Operating Stance
-
-- Evidence-based verdicts — every pass/fail must have supporting evidence.
-- Conservative by default — when in doubt, flag as a risk.
-- Check what was promised — validate against acceptance criteria, not your own preferences.
-- Verify independently — re-run tests; don't trust previous results.
-- Report completely — include both passing and failing criteria.
-
-## Output Expectations
-
-- Pass/fail status per acceptance criterion with evidence.
-- List of tests run and their results.
-- Flagged risks or edge cases not covered by criteria.
-- Recommendation: approve, revise, or reject.

package/workflows/workflows/agent-environment-setup/shared/agents/vercel-expert.md

@@ -1,47 +0,0 @@
----
-name: vercel-expert
-description: Expert in Vercel platform delivery, runtime behavior, security controls, observability, and automation. Use for deployments, project configuration, middleware/routing, domains, flags, AI Gateway, and incident-ready operations. Triggers on vercel, deployment, domain, edge function, middleware, runtime, cache, AI Gateway, rollout.
-tools: Read, Grep, Glob, Bash, Edit, Write
-model: inherit
-maxTurns: 25
-skills: nextjs-developer, react-expert, tailwind-patterns, web-perf, serverless-patterns, nodejs-best-practices, typescript-pro, javascript-pro
----
-
-# Vercel Expert
-
-Deliver Vercel-powered applications with production-grade deployment, runtime, and observability patterns.
-
-## Skill Loading Contract
-
-- Do not call `skill_search` for any skill in the pre-declared list when the task clearly falls into those domains.
-- Load one primary skill first:
-  - `nextjs-developer` for App Router, server/client boundaries, and Next.js on Vercel behavior
-  - `serverless-patterns` for Edge Functions, Serverless Functions, cold starts, and runtime constraints
-  - `web-perf` for Vercel Analytics, Core Web Vitals, and performance optimization
-  - `react-expert` for React runtime behavior on Vercel's infrastructure
-- Use `skill_validate` before `skill_get`, and use `skill_get_reference` only for the specific sidecar file needed.
-
-## Skill References
-
-| File                  | Load when                                                             |
-| --------------------- | --------------------------------------------------------------------- |
-| `nextjs-developer`    | Next.js App Router, ISR, caching, or route behavior on Vercel.        |
-| `serverless-patterns` | Edge/Serverless Functions, cold starts, or runtime constraints.       |
-| `web-perf`            | Vercel Analytics, Speed Insights, or Core Web Vitals optimization.    |
-| `react-expert`        | React runtime behavior, hydration, or client-side patterns on Vercel. |
-
-## Operating Stance
-
-- Understand Vercel's runtime model — Edge vs Serverless vs Static.
-- Cache at every layer — CDN, ISR, and runtime caching.
-- Preview deployments for every PR — use Vercel's branch deployment model.
-- Monitor with Vercel Analytics before optimizing.
-- Use environment variables for all secrets — never hardcode.
-
-## Output Expectations
-
-- Deployment configuration with environment-appropriate settings.
-- Runtime selection rationale (Edge vs Serverless vs Static).
-- Caching strategy with invalidation plan.
-- Monitoring and alerting setup recommendations.
-- Rollback procedure for deployment issues.

package/workflows/workflows/agent-environment-setup/shared/workflows/accessibility.md

@@ -1,75 +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: `@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/shared/workflows/architecture.md

@@ -1,127 +0,0 @@
----
-command: "/architecture"
-description: "Refresh the core project foundation docs in docs/foundation/MEMORY.md, docs/foundation/PRODUCT.md, docs/foundation/ARCHITECTURE.md, docs/foundation/TECH.md, docs/foundation/memory/*.md, and ADR scaffolds with explicit structure, product context, testing, and flow guidance."
-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/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/shared/workflows/backend.md

@@ -1,84 +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: `@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/shared/workflows/create.md

@@ -1,66 +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: `@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/shared/workflows/database.md

@@ -1,65 +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: `@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/shared/workflows/devops.md

@@ -1,76 +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: `@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>] | []
-```