@cubis/foundry 0.3.62 → 0.3.64

package/workflows/workflows/agent-environment-setup/platforms/antigravity/rules/GEMINI.md

@@ -27,13 +27,15 @@ Rules:
 3. Keep progress updates to one short sentence.
 4. For pure Q&A replies, skip the status line.
 
-## 2) Workflow-First Contract
+## 2) Route-First Workflow Contract
 
-1. If the user explicitly requests a slash command, run that command/workflow first.
+1. If the user explicitly requests a slash command, run the matching `.gemini/commands/*.toml` command and its `.agent/workflows/*.md` workflow first.
 2. Otherwise choose the best workflow by intent from `.agent/workflows` and use matching `.gemini/commands/*.toml` when available.
 3. For cross-domain tasks, use orchestrated delegation with `@orchestrator`.
-4. Keep one primary workflow; use others only as supporting references.
-5. Before executing any workflow, check if a matching skill exists via `skill_search`; load with `skill_get` to prime context before the workflow runs (→ §5 MCP Skill Engine).
+4. Resolve explicit `@agent` mentions before skill discovery and treat workflows/agents as route primitives, not skills.
+5. On Antigravity, the primary route surface is Gemini commands/workflow files plus `@agent-name`. Do not treat `$workflow-*` or `$agent-*` as the primary route surface here; those are Codex compatibility aliases.
+6. Keep one primary workflow; use others only as supporting references.
+7. Before loading any skill, inspect the repo/task locally first. Use MCP skill tools only when the user names a skill explicitly or route resolution still leaves the domain unclear (→ §5 MCP Skill Engine).
 
 ## 3) Request Classifier
 
@@ -72,9 +74,11 @@ Use the best specialist first:
 
 Before handing off to any specialist agent, prime context with the relevant domain skill (→ §5 MCP Skill Engine):
 
-1. Run `skill_search <domain>` to find the best matching skill.
-2. If a strong match exists, load it with `skill_get <id>` before delegating.
-3. Include the loaded skill ID in the Decision Log for the routing decision.
+1. Resolve the workflow or custom agent first with `route_resolve <intent>`.
+2. Prime only the mapped primary skills for that route. If the route is still unresolved after local grounding, run one narrow `skill_search <domain>` and then validate the chosen exact ID with `skill_validate <id>`.
+3. Load the core skill with `skill_get <id>` using `includeReferences:false` by default.
+4. Pull one sidecar markdown file at a time with `skill_get_reference` when the skill or task requires it.
+5. Include the resolved route ID and validated skill IDs in the Decision Log.
 
 This ensures the specialist starts with accurate domain knowledge, not just role intent.
 
@@ -86,33 +90,42 @@ The Foundry MCP server is the primary knowledge layer. Use tools decisively —
 
 | Prefix      | Tools                                                                                                | When to use                                                    |
 | ----------- | ---------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- |
-| `skill_*`   | `skill_list_categories`, `skill_search`, `skill_browse_category`, `skill_get`, `skill_budget_report` | Domain expertise for any implementation, debug, or review task |
+| `route_*`   | `route_resolve`                                                                                       | Resolve workflows and custom agents before any skill loading   |
+| `skill_*`   | `skill_list_categories`, `skill_search`, `skill_validate`, `skill_browse_category`, `skill_get`, `skill_get_reference`, `skill_budget_report` | Domain expertise for implementation, debug, or review after the route is known |
 | `postman_*` | `postman_get_mode`, `postman_set_mode`, `postman_get_status`                                         | API testing or Postman configuration tasks                     |
 | `stitch_*`  | `stitch_get_mode`, `stitch_set_profile`, `stitch_get_status`                                         | Stitch data pipeline tasks                                     |
 
-### Discovery Flow (Mandatory Order)
+### Validated Skill Flow (Mandatory Order)
 
-Stop at the earliest step that gives enough signal. Do not jump ahead.
+Stop at the earliest step that gives enough signal. Do not jump ahead or front-load skill discovery.
 
-1. `skill_list_categories` — run once per session if domain is unknown; see what exists
-2. `skill_search <keyword>` — fast keyword match across all skills; always try this first
-3. `skill_browse_category <category>` — explore if search is too broad or returns 0 results
-4. `skill_get <id>` — load full skill content; only when committed to using it
-5. `skill_budget_report` — verify token cost internally; do not emit budget details unless requested
+1. Inspect the codebase/task locally first; do not start with `skill_search`
+2. Resolve explicit workflows, custom agents, or free-text route intent with `route_resolve <intent>`
+3. If the route is still unresolved and local grounding leaves the domain unclear, run one narrow `skill_search <keyword>`
+4. Validate the selected exact skill ID with `skill_validate <id>` before any load
+5. Load only the core `SKILL.md` with `skill_get <id>` and `includeReferences:false`
+6. Load at most one sidecar markdown file at a time with `skill_get_reference <id> <path>`
+7. Use `skill_list_categories` or `skill_browse_category` only as fallback when targeted search fails
+8. Use `skill_budget_report` internally only when the user explicitly asks for context accounting
 
 ### Postman Intent Trigger (Required)
 
 When user intent includes Postman workflows (for example: workspace, collection, environment, runCollection, monitor, mock, or "run Postman tests"):
 
-1. Run `skill_search "postman"` first.
-2. If `postman` skill exists, load `skill_get "postman"` before workflow/agent routing.
-3. Prefer Postman MCP tools (`postman.*`) over Newman/CLI fallback unless the user explicitly asks for fallback.
-4. If `--postman` was installed but `postman` skill cannot be found, report installation drift and suggest reinstall with `cbx workflows install ... --postman`.
+1. Validate `postman` directly with `skill_validate "postman"` when the exact skill ID is known.
+2. If validation fails and local grounding is still insufficient, run a narrow `skill_search "postman"` and validate the selected exact ID.
+3. Load `skill_get "postman"` with `includeReferences:false` before workflow/agent routing.
+4. Prefer Postman MCP tools (`postman.*`) over Newman/CLI fallback unless the user explicitly asks for fallback.
+5. If `--postman` was installed but `postman` skill cannot be found, report installation drift and suggest reinstall with `cbx workflows install ... --postman`.
 
 **Hard rules:**
 
-- Never call `skill_get` without a prior `skill_search` or `skill_browse_category`
-- Never call `skill_get` with a workflow ID — `workflow-*` are routes, not skills; keep workflow mentions in the Decision Log
+- Never call `skill_get` from fuzzy search output without first validating the exact ID via `skill_validate`
+- Never skip local repo inspection and jump straight to `skill_search`
+- Never use `skill_search` to discover workflows or custom agents
+- Never call `skill_get` with a workflow or agent ID — routes are not skills; keep workflow mentions in the Decision Log
+- Never call `skill_get` with `includeReferences:true` by default in agent workflows
+- Never bulk-load sibling/reference markdown files when one targeted `skill_get_reference` will do
 - Never reload a skill already loaded this session — reuse content already in context
 - If `skill_search` returns 0 results, try `skill_browse_category`, then fall back to built-in knowledge
 
@@ -121,6 +134,7 @@ When user intent includes Postman workflows (for example: workspace, collection,
 | Request type                                   | Skills to load via `skill_get`                                  |
 | ---------------------------------------------- | --------------------------------------------------------------- |
 | Q&A / explanation                              | None — answer from knowledge; load only if user explicitly asks |
+| Skill creation / skill maintenance             | `skill-authoring` first; add at most one supporting skill       |
 | Single-domain implementation, debug, or review | 1 primary + 1 supporting (max)                                  |
 | Multi-domain / orchestration                   | 1 per distinct domain, hard cap at 3                            |
 | User explicitly names a skill                  | Always load it — overrides all caps                             |
@@ -142,12 +156,23 @@ After `skill_get`, include at most one short line:
 
 Do not append budget tables or token summaries unless the user explicitly asks.
 
+### Reference Files (Required When Relevant)
+
+Reference markdown files are first-class skill context, but they must be loaded selectively.
+
+1. Use `skill_validate` to see `availableReferences` for the exact skill
+2. Start with `skill_get(..., includeReferences:false)` to load only the core skill body
+3. If the skill points to a reference or the task clearly needs sidecar detail, load one file with `skill_get_reference`
+4. Only load another reference if the first one still leaves a concrete gap
+
 
 ### Anti-Patterns (Never Do These)
 
 - Loading skills speculatively "just in case" they might be useful
-- Calling `skill_get` before running `skill_search` or `skill_browse_category`
+- Calling `skill_get` before `skill_validate`
 - Using partial or guessed skill IDs in `skill_get`
+- Treating `skill_search` results as an implicit final selection
+- Starting a task with `skill_list_categories` or broad catalog browsing
 - Publishing verbose budget fields (`full_catalog_est_tokens`, `loaded_est_tokens`, etc.) in responses
 - Re-emitting the ctx stamp multiple times within a single response
 - Treating workflow IDs as skill IDs in any MCP tool call
@@ -244,66 +269,27 @@ Selection policy:
 <!-- cbx:workflows:auto:end -->
 
 <!-- cbx:mcp:auto:start version=1 -->
-## Cubis Foundry MCP Tool Catalog (auto-managed)
-
-The Foundry MCP server provides progressive-disclosure skill discovery and integration management tools.
-
-### Skill Vault
-
-- **123** skills across **22** categories
-- Estimated full catalog: ~109,067 tokens
-
-Categories:
-- `ai`: 1 skill(s)
-- `api`: 3 skill(s)
-- `architecture`: 3 skill(s)
-- `backend`: 14 skill(s)
-- `data`: 4 skill(s)
-- `design`: 6 skill(s)
-- `devops`: 20 skill(s)
-- `documentation`: 3 skill(s)
-- `frontend`: 9 skill(s)
-- `game-dev`: 1 skill(s)
-- `general`: 26 skill(s)
-- `localization`: 1 skill(s)
-- `marketing`: 2 skill(s)
-- `mobile`: 7 skill(s)
-- `observability`: 1 skill(s)
-- `payments`: 1 skill(s)
-- `performance`: 2 skill(s)
-- `practices`: 5 skill(s)
-- `saas`: 1 skill(s)
-- `security`: 4 skill(s)
-- `testing`: 6 skill(s)
-- `tooling`: 3 skill(s)
-
-### Built-in Tools
-
-**Skill Discovery:**
-- `skill_list_categories`: List all skill categories available in the vault. Returns category names and skill counts.
-- `skill_browse_category`: Browse skills within a specific category. Returns skill IDs and short descriptions.
-- `skill_search`: Search skills by keyword. Matches against skill IDs and descriptions.
-- `skill_get`: Get full content of a specific skill by ID. Returns SKILL.md content and referenced files.
-- `skill_budget_report`: Report estimated context/token budget for selected and loaded skills.
-
-**Postman Integration:**
-- `postman_get_mode`: Get current Postman MCP mode from cbx_config.
-- `postman_set_mode`: Set Postman MCP mode in cbx_config.
-- `postman_get_status`: Get Postman integration status and active profile.
-
-**Stitch Integration:**
-- `stitch_get_mode`: Get Stitch MCP mode from cbx_config.
-- `stitch_set_profile`: Switch active Stitch profile in cbx_config.
-- `stitch_get_status`: Get Stitch integration status and active profile.
-
-### Skill Discovery Flow
-
-Use progressive disclosure to minimize context usage:
-1. `skill_list_categories` → see available categories and counts
-2. `skill_browse_category` → browse skills in a category with short descriptions
-3. `skill_search` → search by keyword across all skills
-4. `skill_get` → load full content of a specific skill (only tool that reads full content)
-5. `skill_budget_report` → check token usage for selected/loaded skills; use result to emit the § Context Budget Tracking stamp
+## Cubis Foundry MCP (auto-managed)
+
+Keep MCP context lazy and exact. Do not front-load the skill catalog.
+
+### Compact Tool Map
+
+- Route tools: `route_resolve`
+- Skill tools: `skill_search`, `skill_validate`, `skill_get`, `skill_get_reference`, `skill_budget_report`
+- Fallback browsing only: `skill_list_categories`, `skill_browse_category`
+- Config tools: `postman_*`, `stitch_*`
+
+### Validated Skill Flow
+
+1. Inspect the repo/task locally first. Do not start with `skill_search`.
+2. Resolve explicit workflows, agents, or free-text route intent with `route_resolve` before loading any skills.
+3. If the route is still unresolved and local grounding leaves the domain unclear, use one narrow `skill_search`.
+4. Always run `skill_validate` on the exact selected ID before `skill_get`.
+5. Call `skill_get` with `includeReferences:false` by default.
+6. Load at most one sidecar markdown file at a time with `skill_get_reference`.
+7. Use `skill_list_categories` or `skill_browse_category` only as fallback when targeted search fails.
+8. Never print catalog counts or budget details unless the user asks.
 
 ### Connection
 

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

@@ -5,22 +5,33 @@ triggers: ["backend", "api", "service", "database", "performance"]
 ---
 # Backend Workflow
 
+# CHANGED: routing contract — made workflow-to-agent and skill mapping explicit — prevents blind startup skill_search and keeps agent selection machine-readable.
+# CHANGED: output contract — replaced human-readable bullets with structured payload fields — allows downstream agents to consume workflow output without re-asking for context.
+
 ## When to use
 Use this when backend architecture or service logic is primary.
 
 ## Routing
 - Primary specialist: `@backend-specialist`
-- Add `@database-architect` for schema/query changes.
-- Add `@security-auditor` when auth, secrets, or sensitive data are involved.
+- Add `@database-architect` for `schema`, `migration`, `query`, `index`, or `N+1` tasks.
+- Add `@security-auditor` for `auth`, `jwt`, `oauth`, `rbac`, `session`, or `secrets`.
+
+## Skill Routing
+- Primary skills: `api-designer`, `nodejs-best-practices`
+- Supporting skills (optional): `api-patterns`, `database-skills`, `secure-code-guardian`, `postman`
+- Primary skill route:
+  - api, endpoint, REST, route, openapi, swagger, spec, contract → `api-designer`
+  - backend, service, middleware, hono, fastify, node → `nodejs-best-practices`
+- Supporting skills:
+  - schema, migration, query, index, performance, N+1 → `database-skills`
+  - auth, jwt, rbac, oauth, session, secrets → `secure-code-guardian`
+  - postman, collection, environment → `postman`
+  - response format, pagination, versioning → `api-patterns`
 
 ## Context notes
 - This workflow file, active platform rules, and selected agents/skills guide execution.
 - Attach logs, screenshots, failing output, and relevant paths when context is incomplete.
 
-## Skill Routing
-- Primary skills: `nodejs-best-practices`, `api-designer`
-- Supporting skills (optional): `api-patterns`, `database-skills`, `secure-code-guardian`
-
 ## Workflow steps
 1. Ask specialist(s) for design and risk assessment.
 2. Validate contracts, data model, and failure handling.
@@ -34,10 +45,26 @@ Use this when backend architecture or service logic is primary.
 - Note any gaps that were not validated.
 
 ## Output Contract
-- API/contract changes
-- OpenAPI spec path
-- Swagger UI route
-- Stoplight route/component status
-- Migration impact
-- Reliability/security notes
-- Verification evidence
+```yaml
+BACKEND_WORKFLOW_RESULT:
+  primary_agent_id: "backend-specialist"
+  supporting_agent_ids: ["database-architect", "security-auditor"]
+  primary_skill_ids: ["api-designer", "nodejs-best-practices"]
+  supporting_skill_ids: ["api-patterns", "database-skills", "secure-code-guardian", "postman"]
+  contract_changes:
+    summary: "Describe contract deltas"
+    openapi_spec_path: null
+    swagger_ui_route: null
+    stoplight_route_or_component: null
+  data_impact:
+    migration_required: false
+    migration_notes: null
+  reliability_and_security:
+    observability_notes: "Summarize logging, tracing, metrics, and alerting impact"
+    security_notes: "Summarize auth, validation, and sensitive-data impact"
+  verification:
+    checks_run: ["<command-or-test>"]
+    gaps: []
+  next_handoff:
+    plan_handoff: null
+```

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

@@ -5,9 +5,17 @@ triggers: ["idea", "brainstorm", "options", "tradeoff", "approach"]
 ---
 # Brainstorm Workflow
 
+# CHANGED: routing — added explicit primary and supporting specialists — prevents route manifest fallback to orchestrator for ideation work.
+# CHANGED: output contract — converted free-form bullets into structured YAML — keeps option handoff machine-readable across platforms.
+
 ## When to use
 Use this when requirements are still fluid and architecture choices are open.
 
+## Routing
+- Primary specialist: `@project-planner`
+- Scope and user-value framing: `@product-manager`
+- Technical tradeoff review: `@backend-specialist`
+
 ## Context notes
 - This workflow file, active platform rules, and selected agents/skills guide execution.
 - Attach logs, screenshots, failing output, and relevant paths when context is incomplete.
@@ -28,7 +36,21 @@ Use this when requirements are still fluid and architecture choices are open.
 - Note any gaps that were not validated.
 
 ## Output Contract
-- Option table (pros/cons)
-- Recommended option
-- Known unknowns
-- First implementation milestone
+```yaml
+BRAINSTORM_WORKFLOW_RESULT:
+  primary_agent: project-planner
+  supporting_agents: [product-manager?, backend-specialist?]
+  primary_skills: [brainstorming, feature-forge]
+  supporting_skills: [plan-writing?]
+  options:
+    - id: <string>
+      summary: <string>
+      pros: [<string>]
+      cons: [<string>]
+      risks: [<string>]
+  recommended_option: <option-id>
+  known_unknowns: [<string>] | []
+  first_milestone: <string>
+  next_handoff:
+    plan_handoff: <PLAN_HANDOFF|null>
+```

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

@@ -5,16 +5,28 @@ triggers: ["create", "build", "implement", "feature", "develop"]
 ---
 # Create Workflow
 
+# CHANGED: routing — added explicit implementation owners by domain — prevents fallback routing and clarifies which specialist leads execution.
+# CHANGED: output contract — converted free-form bullets into structured YAML — makes create results consumable by downstream workflows.
+# CHANGED: skill routing — added `skill-authoring` as the canonical support skill for skill package work — lets skill creation and repair route cleanly without blind startup search.
+
 ## 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/skills guide execution.
 - Attach logs, screenshots, failing output, and relevant paths when context is incomplete.
 
 ## Skill Routing
 - Primary skills: `feature-forge`, `architecture-designer`
-- Supporting skills (optional): `lint-and-validate`, `test-master`
+- Supporting skills (optional): `skill-authoring`, `lint-and-validate`, `test-master`
+- If the task is creating or repairing a skill package, load `skill-authoring` directly before generic supporting skills.
 
 ## Workflow steps
 1. Confirm target files and contracts.
@@ -28,7 +40,21 @@ Use this for net-new implementation after design is stable.
 - Note any gaps that were not validated.
 
 ## Output Contract
-- Changed components/files
-- Behavioral impact
-- Test evidence
-- Follow-up items
+```yaml
+CREATE_WORKFLOW_RESULT:
+  primary_agent_id: "orchestrator"
+  supporting_agent_ids: ["backend-specialist", "frontend-specialist", "mobile-developer", "test-engineer"]
+  primary_skill_ids: ["feature-forge", "architecture-designer"]
+  supporting_skill_ids: ["lint-and-validate", "test-master"]
+  implemented_scope:
+    summary: "Describe the implemented increment"
+    changed_artifacts: ["<path-or-artifact>"]
+  behavioral_impact: ["Describe user-visible or system-level changes"]
+  verification:
+    checks_run: ["<command-or-test>"]
+    evidence: ["Describe the strongest verification evidence"]
+    gaps: []
+  follow_up_items: []
+  next_handoff:
+    plan_handoff: null
+```

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

@@ -5,6 +5,8 @@ triggers: ["database", "sql", "schema", "migration", "index"]
 ---
 # Database Workflow
 
+# CHANGED: output contract — converted free-form bullets into structured YAML — keeps schema and migration handoffs machine-readable across platforms.
+
 ## When to use
 Use this when data modeling, query quality, migration safety, or database performance is core to the task.
 
@@ -15,7 +17,7 @@ Use this when data modeling, query quality, migration safety, or database perfor
 - Core skill hub: `database-skills`
 - Companion skills: `database-design` (schema/migrations), `database-optimizer` (tuning/triage)
 - Mobile/local persistence companion: `drift-flutter`
-- Power bridge: `workflows/powers/database-skills`
+- Engine references are loaded on-demand through `database-skills` using `skill_validate` and targeted `skill_get_reference`.
 
 ## Context notes
 - This workflow file, active platform rules, and selected agents/skills guide execution.
@@ -24,7 +26,7 @@ Use this when data modeling, query quality, migration safety, or database perfor
 ## Skill Routing
 - Primary skills: `database-skills`, `database-design`
 - Supporting skills (optional): `database-optimizer`
-- Engine packs (sub-skills): `database-skills/postgres`, `database-skills/mysql`, `database-skills/vitess`, `database-skills/neki`, `database-skills/mongodb`, `database-skills/sqlite`, `database-skills/supabase`, `database-skills/redis`
+- Engine references: `postgres`, `mysql`, `vitess`, `neki`, `mongodb`, `sqlite`, `supabase`, `redis`
 
 ## Workflow steps
 1. Confirm data shape, access patterns, and workload size.
@@ -40,9 +42,20 @@ Use this when data modeling, query quality, migration safety, or database perfor
 - Note any gaps that were not validated.
 
 ## Output Contract
-- Schema/query changes
-- Indexing plan
-- Pagination plan
-- Migration + rollback plan
-- Query-plan evidence (`EXPLAIN` or equivalent)
-- Validation evidence
+```yaml
+DATABASE_WORKFLOW_RESULT:
+  primary_agent_id: "database-architect"
+  supporting_agent_ids: ["backend-specialist", "test-engineer"]
+  primary_skill_ids: ["database-skills", "database-design"]
+  supporting_skill_ids: ["database-optimizer"]
+  schema_changes: ["Describe schema changes"]
+  indexing_plan: ["Describe indexes and rationale"]
+  pagination_plan: null
+  migration:
+    required: false
+    plan: ["Describe migration steps"]
+    rollback: ["Describe rollback steps"]
+  evidence:
+    query_plans: ["Summarize explain or engine-native plan evidence"]
+    validation_checks: ["<command-or-test>"]
+```

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

@@ -5,9 +5,17 @@ triggers: ["debug", "bug", "error", "incident", "stack trace"]
 ---
 # Debug Workflow
 
+# CHANGED: routing — added explicit debug ownership and supporting specialists — prevents route manifest fallback to orchestrator during bug work.
+# CHANGED: output contract — converted free-form bullets into structured YAML — makes root-cause handoff deterministic.
+
 ## When to use
 Use this when behavior is failing or inconsistent.
 
+## Routing
+- Primary specialist: `@debugger`
+- Domain implementation support: `@backend-specialist`
+- Verification support: `@test-engineer`
+
 ## Context notes
 - This workflow file, active platform rules, and selected agents/skills guide execution.
 - Attach logs, screenshots, failing output, and relevant paths when context is incomplete.
@@ -28,7 +36,19 @@ Use this when behavior is failing or inconsistent.
 - Note any gaps that were not validated.
 
 ## Output Contract
-- Reproduction notes
-- Root cause summary
-- Fix summary
-- Regression checks performed
+```yaml
+DEBUG_WORKFLOW_RESULT:
+  primary_agent: debugger
+  supporting_agents: [backend-specialist?, test-engineer?]
+  primary_skills: [systematic-debugging, find-bugs]
+  supporting_skills: [monitoring-expert?, error-ux-observability?]
+  reproduction:
+    steps: [<string>]
+    expected_vs_actual: <string>
+  root_cause: <string>
+  remediation:
+    summary: <string>
+    changed_artifacts: [<path-or-artifact>]
+  regression_checks: [<command or test>]
+  follow_up_items: [<string>] | []
+```

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

@@ -5,6 +5,8 @@ triggers: ["devops", "deploy", "ci", "cd", "rollback", "infra"]
 ---
 # DevOps Workflow
 
+# CHANGED: output contract — converted free-form bullets into structured YAML — keeps rollout and rollback planning machine-readable.
+
 ## When to use
 Use this when deployment pipeline, infrastructure, or release execution is the main scope.
 
@@ -33,7 +35,15 @@ Use this when deployment pipeline, infrastructure, or release execution is the m
 - Note any gaps that were not validated.
 
 ## Output Contract
-- Deployment plan
-- Rollback conditions
-- Validation and observability checks
-- Outstanding operational risks
+```yaml
+DEVOPS_WORKFLOW_RESULT:
+  primary_agent: devops-engineer
+  supporting_agents: [security-auditor?, test-engineer?]
+  primary_skills: [devops-engineer, sre-engineer]
+  supporting_skills: [monitoring-expert?, terraform-engineer?, wrangler?]
+  deployment_plan: [<string>]
+  rollback_conditions: [<string>]
+  validation_checks: [<command or test>]
+  observability_checks: [<string>]
+  outstanding_operational_risks: [<string>] | []
+```

package/workflows/workflows/agent-environment-setup/platforms/antigravity/workflows/implement-track.md

@@ -5,9 +5,17 @@ triggers: ["track", "milestone", "delivery", "progress", "execution"]
 ---
 # Implement Track Workflow
 
+# CHANGED: routing — added explicit milestone coordination owners — prevents generic fallback and clarifies who runs long execution tracks.
+# CHANGED: output contract — converted free-form bullets into structured YAML — keeps milestone state machine-readable for resumability.
+
 ## When to use
 Use this for medium/large efforts where progress visibility is required.
 
+## Routing
+- Primary coordinator: `@orchestrator`
+- Milestone planning: `@project-planner`
+- Verification gates: `@test-engineer`
+
 ## Context notes
 - This workflow file, active platform rules, and selected agents/skills guide execution.
 - Attach logs, screenshots, failing output, and relevant paths when context is incomplete.
@@ -29,7 +37,20 @@ Use this for medium/large efforts where progress visibility is required.
 - Note any gaps that were not validated.
 
 ## Output Contract
-- Milestone board (done/in-progress/next)
-- Gate status
-- Blockers and dependencies
-- ETA confidence
+```yaml
+IMPLEMENT_TRACK_WORKFLOW_RESULT:
+  primary_agent: orchestrator
+  supporting_agents: [project-planner?, test-engineer?]
+  primary_skills: [plan-writing, feature-forge]
+  supporting_skills: [lint-and-validate?, test-master?]
+  milestones:
+    done: [<string>]
+    in_progress: [<string>]
+    next: [<string>]
+  gate_status: [<string>]
+  blockers: [<string>] | []
+  dependencies: [<string>] | []
+  eta_confidence: <low|medium|high>
+  next_handoff:
+    plan_handoff: <PLAN_HANDOFF|null>
+```

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

@@ -5,6 +5,8 @@ triggers: ["incident", "outage", "sev", "degraded", "hotfix"]
 ---
 # Incident Workflow
 
+# CHANGED: output contract — converted free-form bullets into structured YAML — keeps incident mitigation and follow-up data structured for resumability.
+
 ## When to use
 Use this for active or recent production incidents.
 
@@ -36,7 +38,15 @@ Use this for active or recent production incidents.
 - Note any gaps that were not validated.
 
 ## Output Contract
-- Incident timeline
-- Mitigation actions
-- Root cause statement
-- Follow-up prevention tasks
+```yaml
+INCIDENT_WORKFLOW_RESULT:
+  primary_agent_id: "backend-specialist"
+  escalation_agent_ids: ["debugger", "database-architect", "security-auditor", "test-engineer", "devops-engineer"]
+  primary_skill_ids: ["systematic-debugging", "sre-engineer"]
+  supporting_skill_ids: ["monitoring-expert", "security-reviewer"]
+  incident_timeline: ["Summarize sequence of impact, detection, mitigation, and recovery"]
+  mitigation_actions: ["Describe mitigation steps taken"]
+  root_cause: "Describe confirmed or best-supported root cause"
+  durable_fix: null
+  follow_up_prevention_tasks: ["Describe prevention and hardening actions"]
+```

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

@@ -5,6 +5,8 @@ triggers: ["mobile", "flutter", "ios", "android", "navigation"]
 ---
 # Mobile Workflow
 
+# CHANGED: output contract — converted free-form bullets into structured YAML — keeps mobile flow changes and readiness notes machine-readable.
+
 ## When to use
 Use this when mobile app architecture, UX behavior, or platform constraints are the focus.
 
@@ -33,7 +35,14 @@ Use this when mobile app architecture, UX behavior, or platform constraints are
 - Note any gaps that were not validated.
 
 ## Output Contract
-- Mobile flow changes
-- Platform constraints handled
-- Test coverage summary
-- Release-readiness notes
+```yaml
+MOBILE_WORKFLOW_RESULT:
+  primary_agent: mobile-developer
+  supporting_agents: [frontend-specialist?, test-engineer?]
+  primary_skills: [mobile-design, flutter-expert]
+  supporting_skills: [riverpod-3?, drift-flutter?, flutter-test-master?]
+  flow_changes: [<string>]
+  platform_constraints_handled: [<string>]
+  test_coverage_summary: [<string>]
+  release_readiness_notes: [<string>] | []
+```