@cubis/foundry 0.3.82 → 0.3.83

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/vibesec/SKILL.md

@@ -89,8 +89,12 @@ Deliver a fast, opinionated security assessment that catches the most common and
 
 ## Gemini Platform Notes
 
-- Use `activate_skill` to invoke skills by name from Gemini CLI or Gemini Code Assist.
-- Skill files are stored under `.gemini/skills/` in the project root.
-- Gemini does not support `context: fork` — all skill execution is inline.
+- Workflow and agent routes are compiled into `.gemini/commands/*.toml` TOML command files.
+- Commands use `{{args}}` for user input, `!{shell command}` for shell output, `@{file}` for file content.
+- Specialists are internal postures (modes of reasoning), not spawned subagent processes.
+- Gemini does not support `context: fork` — all skill execution is inline within the current session.
+- Skills are loaded via MCP when the Cubis Foundry MCP server is configured. Local `.agents/skills/` paths serve as hints.
 - User arguments are passed as natural language in the activation prompt.
-- Reference files are loaded relative to the skill directory under `.gemini/skills/<skill-id>/`.
+- Rules file: `.gemini/GEMINI.md`.
+- Reference files are loaded relative to the skill directory under `.agents/skills/<skill-id>/`.
+- MCP skill tools (`skill_search`, `skill_get`, `skill_validate`, `skill_get_reference`) are available when MCP is connected.

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

@@ -80,8 +80,12 @@ Load detailed guidance based on context:
 
 ## Gemini Platform Notes
 
-- Use `activate_skill` to invoke skills by name from Gemini CLI or Gemini Code Assist.
-- Skill files are stored under `.gemini/skills/` in the project root.
-- Gemini does not support `context: fork` — all skill execution is inline.
+- Workflow and agent routes are compiled into `.gemini/commands/*.toml` TOML command files.
+- Commands use `{{args}}` for user input, `!{shell command}` for shell output, `@{file}` for file content.
+- Specialists are internal postures (modes of reasoning), not spawned subagent processes.
+- Gemini does not support `context: fork` — all skill execution is inline within the current session.
+- Skills are loaded via MCP when the Cubis Foundry MCP server is configured. Local `.agents/skills/` paths serve as hints.
 - User arguments are passed as natural language in the activation prompt.
-- Reference files are loaded relative to the skill directory under `.gemini/skills/<skill-id>/`.
+- Rules file: `.gemini/GEMINI.md`.
+- Reference files are loaded relative to the skill directory under `.agents/skills/<skill-id>/`.
+- MCP skill tools (`skill_search`, `skill_get`, `skill_validate`, `skill_get_reference`) are available when MCP is connected.

package/workflows/workflows/agent-environment-setup/shared/rules/STEERING.md

@@ -37,7 +37,7 @@ Follow this decision tree for EVERY user request:
 
 > **Rule:** Inspect the repo and task locally BEFORE choosing a route or loading any skill.
 > **Rule:** If the user already chose the route, do not re-route it unless the named workflow, agent, or skill is invalid.
-> **Rule:** For non-trivial work, read `PRODUCT.md`, `ENGINEERING_RULES.md`, `ARCHITECTURE.md`, and `TECH.md` in that order when they exist before planning or implementing.
+> **Rule:** For non-trivial work, read `docs/foundation/MEMORY.md` first when it exists. Then load `docs/foundation/PRODUCT.md`, `ENGINEERING_RULES.md`, `docs/foundation/ARCHITECTURE.md`, `docs/foundation/TECH.md`, `docs/foundation/memory/*.md`, and ADRs only as needed. Use the MEMORY load map to decide which deeper docs the active workflow, agent, or skill should consult.
 
 ---
 

package/workflows/workflows/agent-environment-setup/shared/rules/overrides/antigravity.md

@@ -2,9 +2,8 @@
 
 ## Platform Paths
 
-- Workflows: `.agent/workflows`
-- Agents: `.agent/agents`
-- Skills: `.agent/skills`
+- Rules: `.agents/rules/GEMINI.md`
+- Skills: `.agents/skills/<skill-id>/SKILL.md`
 - Gemini commands: `.gemini/commands/*.toml`
 - Rules file: `GEMINI.md`
 
@@ -13,7 +12,7 @@
 Gemini recognizes these additional entry points:
 
 1. **Explicit Gemini command** (`.gemini/commands/*.toml`) — highest priority route.
-2. **Agent Manager** for multi-agent coordination — Gemini's orchestration surface.
+2. Foundry compiles `/workflow` and `@agent` routes into command entry points instead of installing undocumented workspace workflow or agent folders.
 3. Standard workflow/agent routing from shared steering.
 
 ## Gemini Commands
@@ -25,7 +24,7 @@ Gemini recognizes these additional entry points:
 ## Agent Manager
 
 - Gemini's Agent Manager handles multi-specialist coordination (equivalent to `@orchestrator`).
-- Agent Manager delegates to specialist agents defined in `.agent/agents/`.
+- In Foundry, specialist routes are exposed through generated command files rather than project-local agent markdown.
 - Use Agent Manager when work crosses 2+ domains with explicit handoff needs.
 
 ## Platform Notes

package/workflows/workflows/agent-environment-setup/shared/rules/overrides/codex.md

@@ -2,16 +2,17 @@
 
 ## Platform Paths
 
-- Workflows: `.agents/workflows`
-- Agents: `.agents/agents`
-- Skills: `.agents/skills`
+- Workflow skills: `.agents/skills/<workflow-id>/SKILL.md`
+- Skills: `.agents/skills/<skill-id>/SKILL.md`
+- Native subagents: `.codex/agents/*.toml`
 - Rules file: `AGENTS.md`
 
 ## Platform-Specific Routing
 
 1. **Explicit `/workflow` or `@agent`** — highest priority route.
-2. Compatibility aliases (`$workflow-*`, `$agent-*`) may be accepted as hints but are never the primary route surface.
-3. Standard workflow/agent routing from shared steering.
+2. `/workflow` resolves to a native workflow skill in `.agents/skills/<workflow-id>/SKILL.md`.
+3. `@agent` resolves to a native Codex subagent in `.codex/agents/*.toml`.
+4. Standard workflow/agent routing from shared steering.
 
 ## Sandbox Constraints
 
@@ -25,5 +26,5 @@
 
 - Codex supports three autonomy levels: `suggest` (propose only), `auto-edit` (edit with confirmation), `full-auto` (autonomous execution).
 - Codex operates in a sandboxed environment — destructive operations are inherently limited.
-- Orchestration in Codex is capability-based: use native delegation when available, otherwise coordinate specialist postures sequentially.
+- Orchestration in Codex is native-subagent-first: delegate through `.codex/agents/*.toml` when the task benefits from a specialist handoff.
 - Keep workflow instructions self-contained since network access for external docs may be restricted.

package/workflows/workflows/agent-environment-setup/shared/rules/overrides/copilot.md

@@ -2,7 +2,6 @@
 
 ## Platform Paths
 
-- Workflows: `.github/copilot/workflows`
 - Agents: `.github/agents`
 - Skills: `.github/skills`
 - Rules file: `copilot-instructions.md`
@@ -13,7 +12,7 @@
 ## Platform-Specific Routing
 
 1. **Explicit workflow prompt or `@agent`** — highest priority route.
-2. Copilot prompt files (`.github/prompts/*.prompt.md`) provide structured entry points.
+2. `/workflow` routes compile into prompt files (`.github/prompts/*.prompt.md`).
 3. Standard workflow/agent routing from shared steering.
 
 ## Agent Handoffs

package/workflows/workflows/agent-environment-setup/shared/rules/overrides/gemini.md

@@ -2,15 +2,13 @@
 
 ## Platform Paths
 
-- Workflows: `.gemini/workflows`
-- Skills: `.gemini/skills`
 - Commands: `.gemini/commands`
 - Rules file: `.gemini/GEMINI.md` (or `GEMINI.md` at repo root when used directly)
 
 ## Platform-Specific Routing
 
 1. **Explicit Gemini command** (`.gemini/commands/*.toml`) — highest priority route.
-2. **Explicit workflow or named skill** — honor it directly before route discovery.
+2. Foundry compiles both `/workflow` and `@agent` routes into command entry points when targeting Gemini CLI.
 3. Standard workflow and MCP routing from shared steering.
 
 ## Platform Notes

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

@@ -1,6 +1,6 @@
 ---
 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."
+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",
@@ -37,23 +37,35 @@ Use this when the task is to declare, refresh, or validate the project backbone
 
 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 (using fenced ```mermaid blocks with valid syntax) and flow narratives 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.
-7. Ensure `docs/foundation/PRODUCT.md` includes a `## Domain Glossary` defining project-specific terms so future agents use consistent vocabulary.
-8. Ensure `docs/foundation/ARCHITECTURE.md` includes `## Crosscutting Concerns` (logging, auth, error handling patterns), `## Quality Requirements`, and `## Risks And Tech Debt` sections.
-9. 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).
-10. 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.
-11. Record whether the update was driven by a broader spec and whether future implementation must follow newly declared structure or product constraints.
+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.
@@ -63,6 +75,9 @@ Use this when the task is to declare, refresh, or validate the project backbone
 ## 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`.
@@ -81,11 +96,13 @@ ARCHITECTURE_WORKFLOW_RESULT:
   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/PRODUCT.md, docs/foundation/ARCHITECTURE.md, docs/foundation/TECH.md]
+  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>]
@@ -100,6 +117,11 @@ ARCHITECTURE_WORKFLOW_RESULT:
     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/antigravity/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: `.agent/agents/frontend-specialist`
-- Verification support: `.agent/agents/test-engineer`
-- Review support: `.agent/agents/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: `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>] | []
-```
-
-> **Antigravity note:** Use Agent Manager for parallel agent coordination. Workflow files are stored under `.agent/workflows/`.

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

@@ -1,107 +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: `.agent/agents/project-planner`
-- Documentation support: `.agent/agents/documentation-writer`
-- Research support: `.agent/agents/researcher`
-- Domain validation: `.agent/agents/backend-specialist`, `.agent/agents/frontend-specialist`, `.agent/agents/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 (using fenced ```mermaid blocks with valid syntax) and flow narratives 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.
-7. Ensure `docs/foundation/PRODUCT.md` includes a `## Domain Glossary` defining project-specific terms so future agents use consistent vocabulary.
-8. Ensure `docs/foundation/ARCHITECTURE.md` includes `## Crosscutting Concerns` (logging, auth, error handling patterns), `## Quality Requirements`, and `## Risks And Tech Debt` sections.
-9. 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).
-10. 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.
-11. 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 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.
-- 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.
-- 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/`.
-- 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:
-    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>
-    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>] | []
-  doc_impact: rules | tech | both
-  next_actions: [<string>] | []
-```
-
-> **Antigravity note:** Use Agent Manager for parallel agent coordination. Workflow files are stored under `.agent/workflows/`.

package/workflows/workflows/agent-environment-setup/platforms/antigravity/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: `.agent/agents/backend-specialist`
-- Database support: `.agent/agents/database-architect`
-- Security review: `.agent/agents/security-auditor`
-- Verification support: `.agent/agents/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-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>] | []
-```
-
-> **Antigravity note:** Use Agent Manager for parallel agent coordination. Workflow files are stored under `.agent/workflows/`.

package/workflows/workflows/agent-environment-setup/platforms/antigravity/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: `.agent/agents/orchestrator`
-- Backend implementation: `.agent/agents/backend-specialist`
-- Frontend implementation: `.agent/agents/frontend-specialist`
-- Mobile implementation: `.agent/agents/mobile-developer`
-- Verification support: `.agent/agents/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-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>] | []
-```
-
-> **Antigravity note:** Use Agent Manager for parallel agent coordination. Workflow files are stored under `.agent/workflows/`.