@cubis/foundry 0.3.75 → 0.3.77

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/skills_index.json

@@ -193,6 +193,38 @@
       "databases"
     ]
   },
+  {
+    "id": "deep-research",
+    "package_id": "deep-research",
+    "catalog_id": "deep-research",
+    "kind": "skill",
+    "name": "deep-research",
+    "canonical": true,
+    "canonical_id": "deep-research",
+    "deprecated": false,
+    "replaced_by": null,
+    "aliases": [],
+    "category": "core-operating",
+    "layer": "core-operating",
+    "maturity": "incubating",
+    "tier": "experimental",
+    "tags": [
+      "core-operating",
+      "deep",
+      "deep research",
+      "deep-research",
+      "research"
+    ],
+    "path": ".github/skills/deep-research/SKILL.md",
+    "description": "Use when investigating latest vendor behavior, comparing tools or platforms, verifying claims beyond the repo, or gathering external evidence before implementation.",
+    "triggers": [
+      "deep-research",
+      "deep research",
+      "deep",
+      "research",
+      "core-operating"
+    ]
+  },
   {
     "id": "django-drf",
     "package_id": "django-drf",
@@ -1747,6 +1779,32 @@
       "workflow-specialists"
     ]
   },
+  {
+    "id": "stitch",
+    "package_id": "stitch",
+    "catalog_id": "stitch",
+    "kind": "skill",
+    "name": "stitch",
+    "canonical": true,
+    "canonical_id": "stitch",
+    "deprecated": false,
+    "replaced_by": null,
+    "aliases": [],
+    "category": "workflow-specialists",
+    "layer": "workflow-specialists",
+    "maturity": "incubating",
+    "tier": "experimental",
+    "tags": [
+      "stitch",
+      "workflow-specialists"
+    ],
+    "path": ".github/skills/stitch/SKILL.md",
+    "description": "Use when implementing or updating UI from Google Stitch artifacts, screen-to-code handoff, design-to-code diffs, or syncing an existing screen with the latest Stitch output through Cubis Foundry MCP.",
+    "triggers": [
+      "stitch",
+      "workflow-specialists"
+    ]
+  },
   {
     "id": "stripe-integration",
     "package_id": "stripe-integration",

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/stitch/SKILL.md

@@ -0,0 +1,92 @@
+---
+name: stitch
+description: Use when implementing or updating UI from Google Stitch artifacts, screen-to-code handoff, design-to-code diffs, or syncing an existing screen with the latest Stitch output through Cubis Foundry MCP.
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "1.0"
+compatibility: Claude Code, Codex, GitHub Copilot
+---
+# Stitch
+
+## Purpose
+
+Turn Google Stitch artifacts into production-ready UI changes without guessing the design. This skill is for real Stitch-driven implementation and update work: fetch the latest Stitch artifacts through Cubis Foundry MCP, map them into the repo's actual stack and design system, and apply minimal, accessible changes.
+
+## When to Use
+
+- Implementing a new screen from Stitch artifacts
+- Updating an existing screen from refreshed Stitch output
+- Performing design-to-code diffs against local UI
+- Translating Stitch artifacts into React, Next.js, React Native, Flutter, SwiftUI, or another project framework
+- Auditing whether the local screen still matches the current Stitch version
+
+## Instructions
+
+1. **Verify Stitch is reachable before relying on it**. Check `stitch_get_status` and `mcp_gateway_status` first. If Stitch is misconfigured or unavailable, say so clearly and do not invent screen details. See `references/platform-setup.md`.
+
+2. **List enabled Stitch tools before choosing a workflow**. Use `stitch_list_enabled_tools` or the Stitch passthrough namespace to confirm which real upstream tools are available in the current environment.
+
+3. **Normalize the request into a concrete implementation brief**. If the prompt is vague, restate the target screen, destination route or component, framework, responsive expectations, and reuse constraints before editing anything. This follows the same prompt-sharpening idea used in Stitch-first design workflows, but the output here should stay implementation-oriented.
+
+4. **Pull Stitch artifacts before planning implementation**. Fetch the actual screen artifact, code, metadata, and image/snapshot when available. Do not reconstruct the UI from a natural-language guess.
+
+5. **Map Stitch output into the repo's real stack**. Re-express the artifact in the project's framework, routing model, state layer, styling system, and component primitives. Do not paste generated output blindly. See `references/implementation-patterns.md`.
+
+6. **Prefer local component reuse over one-off markup**. If the project already has buttons, cards, typography, layout shells, tokens, or navigation primitives, use them instead of cloning raw Stitch structure.
+
+7. **Keep diffs minimal when updating an existing screen**. Compare the local implementation against the latest Stitch artifact and patch only the changed structure, spacing, copy, tokens, states, and assets. Preserve validated business logic and local architecture. See `references/update-diff-workflow.md`.
+
+8. **Use existing local exports or prior implementations as a diff baseline**. If the repo already contains the target screen or a prior Stitch-derived implementation, compare against that first. Refresh from Stitch when the task requires live parity; otherwise use the local baseline to reduce churn.
+
+9. **Preserve accessibility and interaction states**. Maintain semantic structure, keyboard flow, focus treatment, labels, contrast, loading/error/empty states, and responsive behavior while translating the design.
+
+10. **Call out unavoidable drift explicitly**. If the repo's design system, data model, or framework constraints prevent a literal Stitch match, explain the exact deviation and why it was necessary.
+
+11. **Ask only targeted clarification questions**. Ask when the artifact is ambiguous, multiple Stitch screens plausibly match, or the repo has competing destination surfaces. Otherwise proceed with the best repo-grounded implementation.
+
+## Output Format
+
+Deliver:
+
+1. **Artifact summary** — which Stitch artifact or screen was used
+2. **Implementation plan** — target files, framework mapping, and any deviations
+3. **Code changes** — minimal production-ready implementation or patch
+4. **Diff notes** — what changed relative to the prior local UI, if applicable
+5. **Verification** — accessibility, responsive behavior, and any remaining gaps
+
+## References
+
+Load only what the current task requires.
+
+| File | Load when |
+| --- | --- |
+| `references/platform-setup.md` | Need to verify Stitch availability, gateway status, profile setup, or secure credential expectations. |
+| `references/implementation-patterns.md` | Need guidance for mapping Stitch artifacts into web/mobile stacks and existing design systems. |
+| `references/update-diff-workflow.md` | Updating an existing implementation from revised Stitch artifacts or running a UI diff workflow. |
+
+## Examples
+
+Use these when the task closely matches the example shape.
+
+| File | Use when |
+| --- | --- |
+| `examples/01-new-screen.md` | Creating a new screen from Stitch output. |
+| `examples/02-update-existing-screen.md` | Patching an existing screen from updated Stitch artifacts. |
+| `examples/03-mobile-handoff.md` | Translating Stitch into a mobile framework or native stack. |
+| `examples/04-prompt-enhancement.md` | Turning a vague Stitch request into a concrete implementation brief before coding. |
+| `examples/05-design-sync-loop.md` | Running an iterative Stitch refresh-and-patch loop for an existing product surface. |
+
+## Copilot Stitch Flow
+
+- Treat the user prompt itself as the skill argument. Restate the target screen, framework, and reuse constraints before editing code.
+- Pull extra context from the mirrored references when needed, for example `#file:references/platform-setup.md` and `#file:references/update-diff-workflow.md`.
+- Keep the task inline: verify Foundry gateway access from workspace `.vscode/mcp.json`, fetch the Stitch artifact, then apply a minimal repo-native patch without assuming subagents or custom tool restrictions.
+
+## Copilot Platform Notes
+
+- Skill files are stored under `.github/prompts/` (prompt files) and `.github/instructions/` (instruction files).
+- Copilot does not support subagent spawning — all skill guidance executes within the current conversation context.
+- User arguments are provided as natural language input in the prompt, not through a `$ARGUMENTS` variable.
+- Frontmatter keys `context`, `agent`, and `allowed-tools` are not supported; guidance is advisory only.
+- Reference files can be included via `#file:references/<name>.md` syntax in Copilot Chat.

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/stitch/evals/assertions.md

@@ -0,0 +1,45 @@
+# Stitch Eval Assertions
+
+## Eval 1: New Screen From Stitch Artifact
+
+This eval checks the default Stitch-first implementation loop for a new web screen: verify availability, inspect enabled tools, fetch the real artifact, then map it into the current stack and design system.
+
+### Assertions
+
+| # | Type | What it checks | Why it matters |
+| --- | --- | --- | --- |
+| 1 | contains | `stitch_get_status` | A Stitch workflow that does not verify reachability first can fabricate screen details or assume the wrong profile. |
+| 2 | contains | `mcp_gateway_status` | Cubis Foundry is the client-facing runtime, so the skill must confirm the MCP gateway is healthy before depending on Stitch passthrough tools. |
+| 3 | contains | `stitch_list_enabled_tools` | Stitch environments can expose different upstream capabilities; the skill should discover those instead of hardcoding an assumed toolset. |
+| 4 | pattern | `PageShell|Card|Button|design system|token` | The implementation must reuse the repo's existing primitives or tokens rather than dumping raw generated markup into production. |
+| 5 | pattern | `responsive|mobile|desktop|accessib` | Production-ready Stitch usage still has to preserve accessibility and responsive behavior. |
+
+### What a passing response looks like
+
+- Starts with Stitch and gateway preflight instead of guessing the artifact.
+- Mentions enabled Stitch tool discovery before choosing a retrieval path.
+- Maps the design into the existing Next.js route and shared primitives.
+- Calls out responsive and accessibility verification as part of the implementation.
+
+---
+
+## Eval 2: Minimal-Diff Stitch Sync For Existing Screen
+
+This eval checks the update workflow: use the latest Stitch artifact as a diff source, preserve working local logic, and patch only the changed UI surface in a mobile implementation.
+
+### Assertions
+
+| # | Type | What it checks | Why it matters |
+| --- | --- | --- | --- |
+| 1 | contains | `stitch_get_status` | The skill must verify that the refreshed Stitch artifact is actually reachable before claiming design parity. |
+| 2 | contains | `stitch_list_enabled_tools` | Tool discovery matters for update flows too, especially when comparing local UI against the current Stitch surface. |
+| 3 | pattern | `minimal diff|patch only|changed only|diff` | Refreshing from Stitch should not default to a full rewrite when an implementation already exists. |
+| 4 | pattern | `analytics|feature flag|business logic|preserve` | Existing instrumentation and product logic are usually validated already and should survive the UI sync. |
+| 5 | pattern | `React Native|mobile|component|accessib|token` | The final patch must respect the target mobile stack and retain design-system and accessibility quality. |
+
+### What a passing response looks like
+
+- Treats Stitch as the source of truth for changed UI details, not for reauthoring the whole screen.
+- Preserves analytics hooks, feature flags, and business logic.
+- Describes a targeted patch path in React Native or another mobile stack.
+- Mentions accessibility, component reuse, and design-token consistency in the final implementation notes.

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/stitch/evals/evals.json

@@ -0,0 +1,68 @@
+[
+  {
+    "id": "stitch-eval-01",
+    "name": "New screen from Stitch artifact",
+    "description": "Validate that the skill starts with Stitch and gateway preflight, pulls real Stitch artifacts, and maps them into the existing web stack instead of copying raw generated output.",
+    "prompt": "Implement a new account overview screen for a Next.js app from the latest Google Stitch artifact. The app already has `PageShell`, `Card`, `Button`, and tokenized typography primitives. Put the screen at `/account`, support desktop and mobile layouts, and keep the implementation aligned with the existing design system instead of pasting raw generated markup.",
+    "assertions": [
+      {
+        "type": "contains",
+        "value": "stitch_get_status",
+        "description": "Must verify Stitch availability before relying on any artifact details."
+      },
+      {
+        "type": "contains",
+        "value": "mcp_gateway_status",
+        "description": "Must check Cubis Foundry MCP gateway status so the skill confirms Stitch passthrough is actually reachable."
+      },
+      {
+        "type": "contains",
+        "value": "stitch_list_enabled_tools",
+        "description": "Must inspect enabled Stitch tools before choosing which upstream artifact workflow to use."
+      },
+      {
+        "type": "pattern",
+        "value": "PageShell|Card|Button|design system|token",
+        "description": "Must map the Stitch output into the repo's existing primitives or token system rather than cloning raw one-off markup."
+      },
+      {
+        "type": "pattern",
+        "value": "responsive|mobile|desktop|accessib",
+        "description": "Must preserve responsive behavior and accessibility as part of the production implementation."
+      }
+    ]
+  },
+  {
+    "id": "stitch-eval-02",
+    "name": "Minimal-diff Stitch sync for existing screen",
+    "description": "Validate that the skill treats refreshed Stitch output as a diff input, preserves local business logic, and translates the update into the destination mobile stack.",
+    "prompt": "Update an existing React Native settings screen from refreshed Google Stitch output. Preserve analytics hooks, feature flags, and business logic already in the app. Only patch the visual and structural differences between the current local screen and the latest Stitch artifact, and keep the final result accessible and consistent with the app's existing components.",
+    "assertions": [
+      {
+        "type": "contains",
+        "value": "stitch_get_status",
+        "description": "Must start with Stitch reachability checks before claiming parity with the latest artifact."
+      },
+      {
+        "type": "contains",
+        "value": "stitch_list_enabled_tools",
+        "description": "Must confirm which Stitch passthrough tools are enabled for the current environment."
+      },
+      {
+        "type": "pattern",
+        "value": "minimal diff|patch only|changed only|diff",
+        "description": "Must frame the work as a minimal patch against the existing implementation rather than a full rewrite."
+      },
+      {
+        "type": "pattern",
+        "value": "analytics|feature flag|business logic|preserve",
+        "description": "Must explicitly preserve validated local logic while updating only the UI surface."
+      },
+      {
+        "type": "pattern",
+        "value": "React Native|mobile|component|accessib|token",
+        "description": "Must translate the Stitch artifact into the destination mobile stack with accessibility and design-system awareness."
+      }
+    ]
+  }
+]

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/stitch/examples/01-new-screen.md

@@ -0,0 +1,13 @@
+# Example: New Screen From Stitch
+
+Prompt shape:
+
+> Use Stitch to find the "Billing Overview" screen, fetch the latest artifacts, and implement it in my Next.js app using the existing design system. Keep accessibility and responsive behavior intact.
+
+Expected workflow:
+
+1. Confirm Stitch is available with `stitch_get_status` and `stitch_list_enabled_tools`.
+2. Fetch the target screen artifact.
+3. Identify the destination route, layout shell, and shared components in the repo.
+4. Implement the screen with project tokens/components instead of raw generated markup.
+5. Summarize any intentional deviations from Stitch.

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/stitch/examples/02-update-existing-screen.md

@@ -0,0 +1,13 @@
+# Example: Update Existing Screen
+
+Prompt shape:
+
+> Re-fetch the "Profile Settings" Stitch screen and patch my existing implementation in `app/settings/profile/page.tsx`. Only update the parts that changed.
+
+Expected workflow:
+
+1. Pull the refreshed Stitch artifact first.
+2. Compare the local screen against the latest design.
+3. Apply a minimal diff to structure, tokens, copy, or states.
+4. Preserve working local logic and component boundaries.
+5. Report what changed and any remaining drift.

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/stitch/examples/03-mobile-handoff.md

@@ -0,0 +1,13 @@
+# Example: Mobile Handoff
+
+Prompt shape:
+
+> Use Stitch to implement the "Trip Details" screen in React Native. Match the design intent, but keep it idiomatic to the existing mobile app.
+
+Expected workflow:
+
+1. Verify Stitch availability and fetch the target artifact.
+2. Map the layout into the app's mobile navigation and component structure.
+3. Reuse tokens, spacing, and shared mobile primitives.
+4. Preserve safe areas, touch targets, text scaling, and loading/error states.
+5. Document any differences between the Stitch source and the mobile implementation.

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/stitch/examples/04-prompt-enhancement.md

@@ -0,0 +1,21 @@
+# Example: Prompt Enhancement Before Implementation
+
+Prompt shape:
+
+> Use Stitch to make the dashboard better and more polished.
+
+Improved internal brief before touching code:
+
+1. Target surface: existing dashboard landing page.
+2. Framework: preserve the repo's current web stack and component primitives.
+3. Scope: refresh layout structure, spacing, hierarchy, and states from the latest Stitch artifact.
+4. Reuse constraints: keep existing navigation, data plumbing, and validated business logic.
+5. Quality bar: preserve accessibility, responsive behavior, and token usage.
+
+Expected workflow:
+
+1. Rewrite the vague request into a concrete implementation brief like the one above.
+2. Verify Stitch availability with `stitch_get_status`, `mcp_gateway_status`, and `stitch_list_enabled_tools`.
+3. Fetch the matching Stitch artifact instead of guessing which screen the user meant.
+4. Patch the local dashboard with minimal diffs.
+5. Summarize the exact changes and any unavoidable drift from Stitch.

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/stitch/examples/05-design-sync-loop.md

@@ -0,0 +1,16 @@
+# Example: Iterative Design Sync Loop
+
+Prompt shape:
+
+> Re-sync the account settings screen from Stitch, patch only the UI diff, and leave the saved form logic intact.
+
+Expected workflow:
+
+1. Verify the Foundry gateway and Stitch tool availability first.
+2. Identify the existing local settings screen and use it as the current diff baseline.
+3. Fetch the latest Stitch artifact for the matching settings screen.
+4. Compare local UI structure, spacing, copy, states, and assets against the refreshed Stitch artifact.
+5. Apply the smallest patch that restores visual parity while preserving the repo's routing, validation, and submission logic.
+6. Report what changed in this pass and what the next Stitch refresh should check if the screen evolves again.
+
+This pattern is intentionally iterative: treat each Stitch refresh as a controlled sync pass, not a full rewrite.

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/stitch/references/implementation-patterns.md

@@ -0,0 +1,20 @@
+# Stitch Implementation Patterns
+
+## Web stacks
+
+- Translate layout intent first: shell, sections, cards, navigation, and hierarchy.
+- Reuse the repo's token layer, typography scale, spacing system, and component primitives.
+- Prefer existing app-shell conventions, routing boundaries, and data-loading patterns over literal generated structure.
+- Preserve semantic HTML and keyboard/focus behavior.
+
+## Mobile stacks
+
+- Preserve layout rhythm, states, and information hierarchy rather than copying web-specific markup.
+- Map Stitch components into platform-native primitives such as React Native components, Flutter widgets, or SwiftUI views.
+- Respect platform navigation, safe areas, typography scaling, and gesture behavior.
+
+## Design system mapping
+
+- Convert raw visual values into the project's design tokens.
+- Reuse shared primitives before introducing new component variants.
+- If a missing primitive blocks fidelity, add the smallest reusable abstraction instead of a screen-local workaround.

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/stitch/references/platform-setup.md

@@ -0,0 +1,46 @@
+# Stitch Platform Setup
+
+## Verification order
+
+1. Run `stitch_get_status` to confirm the active profile, URL, env-var alias, and scope.
+2. Run `mcp_gateway_status` to confirm the Cubis Foundry gateway sees Stitch as available.
+3. Run `stitch_list_enabled_tools` to confirm the enabled upstream Stitch tools.
+
+If any of those fail, stop treating Stitch as authoritative input.
+
+## Credential expectations
+
+- Stitch credentials are machine-scoped and should come from `~/.cbx/credentials.env` or an already-exported environment variable.
+- Project files and generated MCP config should never contain raw API keys.
+- The gateway path is the default client-facing path. The local client should connect to `cubis-foundry`, then use the Stitch passthrough tools exposed through that server.
+
+## Client-specific verification
+
+Use the platform runtime surface that actually owns the `cubis-foundry` registration:
+
+- Codex:
+  - project: `.vscode/mcp.json`
+  - global: `~/.codex/config.toml`
+- Claude Code:
+  - project: `.mcp.json`
+  - global: `~/.claude/mcp.json`
+- GitHub Copilot:
+  - project: `.vscode/mcp.json`
+  - global: `~/.copilot/mcp-config.json`
+- Gemini CLI:
+  - project: `.gemini/settings.json`
+  - global: `~/.gemini/settings.json`
+- Antigravity:
+  - project: `.gemini/settings.json`
+  - global: `~/.gemini/settings.json`
+
+For every platform, the expected secure model is the same:
+
+- client config points at `cubis-foundry`
+- `cbx_config.json` stores the Stitch env-var alias only
+- `~/.cbx/credentials.env` or the live shell environment stores the actual key
+
+## Secure fallback behavior
+
+- If Stitch is configured but unavailable, continue only with a repo-grounded fallback and call out that the implementation is not verified against live Stitch artifacts.
+- If a task explicitly requires live Stitch parity, stop and report the configuration/runtime issue instead of guessing.

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/stitch/references/update-diff-workflow.md

@@ -0,0 +1,23 @@
+# Stitch Update and Diff Workflow
+
+## Recommended sequence
+
+1. Fetch the latest Stitch artifact for the target screen.
+2. Identify the current local implementation files before editing anything.
+3. Compare structure, copy, spacing, tokens, states, assets, and responsive behavior.
+4. Patch only the deltas that come from Stitch.
+5. Re-check accessibility and regression risk after the patch.
+
+## Minimal-diff rules
+
+- Keep existing data flow, component ownership, and test seams unless Stitch requires a structural change.
+- Avoid replacing an entire screen when a smaller patch will preserve local stability.
+- Preserve local fixes that are unrelated to the new Stitch diff.
+
+## Report drift explicitly
+
+If you keep a local deviation from Stitch, document:
+
+- what differs
+- why the local version stays different
+- whether the difference is architectural, product-driven, or temporary

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

@@ -26,8 +26,9 @@ Use this for net-new implementation after design is stable.
 ## 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`, `react`, `react`, `nextjs`, `frontend-design`, `frontend-design`, `frontend-design`, `performance-testing`, `skill-creator`, `stripe-integration`, `ci-cd-pipeline`, `frontend-design`
+- 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
 
@@ -49,7 +50,7 @@ CREATE_WORKFLOW_RESULT:
   primary_agent: orchestrator
   supporting_agents: [backend-specialist?, frontend-specialist?, mobile-developer?, test-engineer?]
   primary_skills: [<dominant-language-skill>]
-  supporting_skills: [<framework-specific-skills-used>]
+  supporting_skills: [stitch?, <framework-specific-skills-used>]
   implemented_scope:
     summary: <string>
     changed_artifacts: [<path-or-artifact>]

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

@@ -8,7 +8,7 @@ triggers: ["mobile", "flutter", "ios", "android", "navigation"]
 
 ## When to use
 
-Use this for mobile app development, Flutter architecture, native integrations, or platform-specific behavior.
+Use this for mobile app development, Flutter architecture, Stitch-driven mobile screen handoff, native integrations, or platform-specific behavior.
 
 ## Routing
 
@@ -24,8 +24,9 @@ Use this for mobile app development, Flutter architecture, native integrations,
 ## Skill Routing
 
 - Primary skills: `expo-app`, `react-native`
-- Supporting skills (optional): `frontend-design`, `expo-app`, `expo-app`, `expo-app`, `expo-app`, `expo-app`, `expo-app`, `expo-app`, `expo-app`, `expo-app`, `swift-best-practices`, `kotlin-best-practices`
+- Supporting skills (optional): `stitch`, `frontend-design`, `expo-app`, `expo-app`, `expo-app`, `expo-app`, `expo-app`, `expo-app`, `expo-app`, `expo-app`, `expo-app`, `swift-best-practices`, `kotlin-best-practices`
 - Start with `expo-app` for feature implementation and `react-native` for UX patterns. Add framework-specific Flutter skill when applicable. Add `frontend-design` for multi-language support.
+- When the request starts from Stitch artifacts or a design sync, load `stitch` first and then pair it with `react-native` plus the narrowest mobile implementation skill for the target stack.
 
 ## Workflow steps
 
@@ -50,7 +51,7 @@ MOBILE_WORKFLOW_RESULT:
   primary_agent: mobile-developer
   supporting_agents: [frontend-specialist?, test-engineer?]
   primary_skills: [expo-app, react-native]
-  supporting_skills: [frontend-design?, expo-app?, expo-app?, <flutter-specific>?]
+  supporting_skills: [stitch?, frontend-design?, expo-app?, expo-app?, <flutter-specific>?]
   implementation:
     platforms: [ios, android]
     architecture_decisions: [<string>]

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

@@ -30,9 +30,9 @@ Use this when joining a new project, exploring an unfamiliar codebase, or prepar
 
 ## Skill Routing
 
-- Primary skills: `architecture-doc`, `system-design`
+- Primary skills: `deep-research`, `system-design`
 - Supporting skills (optional): `system-design`, `database-design`, `typescript-best-practices`, `javascript-best-practices`, `python-best-practices`
-- Start with `architecture-doc` for systematic exploration and `system-design` for architecture mapping. Add `system-design` for undocumented systems.
+- Start with `deep-research` for systematic exploration and `system-design` for architecture mapping. Add `system-design` for undocumented systems. Prefer repo evidence first; use external sources only when setup or dependency behavior cannot be confirmed locally.
 
 ## Workflow steps
 
@@ -55,7 +55,7 @@ Use this when joining a new project, exploring an unfamiliar codebase, or prepar
 ONBOARD_WORKFLOW_RESULT:
   primary_agent: researcher
   supporting_agents: [code-archaeologist?, backend-specialist?, frontend-specialist?]
-  primary_skills: [architecture-doc, system-design]
+  primary_skills: [deep-research, system-design]
   supporting_skills: [system-design?, database-design?]
   project_overview:
     purpose: <string>

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

@@ -24,8 +24,8 @@ Use this when a task spans multiple domains (backend + frontend, security + infr
 ## Skill Routing
 
 - Primary skills: `system-design`, `api-design`
-- Supporting skills (optional): `database-design`, `architecture-doc`, `mcp-server-builder`, `tech-doc`, `prompt-engineering`, `skill-creator`
-- Start with `system-design` for system design coordination and `api-design` for integration contracts. Add supporting skills based on the coordination challenge.
+- Supporting skills (optional): `database-design`, `deep-research`, `mcp-server-builder`, `tech-doc`, `prompt-engineering`, `skill-creator`
+- Start with `system-design` for system design coordination and `api-design` for integration contracts. Add `deep-research` before implementation when the coordination challenge depends on fresh external facts or public comparison.
 
 ## Workflow steps
 

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

@@ -36,13 +36,13 @@ Use this when starting a new feature, project, or significant change that needs
 ## Skill Routing
 
 - Primary skills: `system-design`, `api-design`
-- Supporting skills (optional): `database-design`, `architecture-doc`, `mcp-server-builder`, `tech-doc`, `prompt-engineering`, `skill-creator`
-- Start with `system-design` for system design and `api-design` for API contracts. Add `database-design` when data modeling is central, `architecture-doc` when external knowledge is needed.
+- Supporting skills (optional): `database-design`, `deep-research`, `mcp-server-builder`, `tech-doc`, `prompt-engineering`, `skill-creator`
+- Start with `system-design` for system design and `api-design` for API contracts. Add `database-design` when data modeling is central, `deep-research` when fresh external knowledge or public comparison is needed.
 
 ## Workflow steps
 
 1. Clarify scope, success criteria, and constraints.
-2. Research existing patterns and dependencies.
+2. Research existing patterns and dependencies, starting in-repo and escalating to `deep-research` only when outside evidence is required.
 3. Decompose into tasks with ownership and dependencies.
 4. Define interfaces, contracts, and failure modes.
 5. Produce acceptance criteria for each milestone.
@@ -62,7 +62,7 @@ PLAN_WORKFLOW_RESULT:
   primary_agent: project-planner
   supporting_agents: [orchestrator?, backend-specialist?, frontend-specialist?, database-architect?]
   primary_skills: [system-design, api-design]
-  supporting_skills: [database-design?, architecture-doc?, mcp-server-builder?]
+  supporting_skills: [database-design?, deep-research?, mcp-server-builder?]
   plan:
     scope_summary: <string>
     tasks:

package/workflows/workflows/agent-environment-setup/platforms/gemini/commands/accessibility.toml

@@ -7,6 +7,8 @@ Execution contract:
 2. Confirm the request fits the workflow's "When to use" section.
 3. Execute according to "Workflow steps" and apply "Context notes".
 4. Complete "Verification" checks and report concrete evidence.
+5. If freshness, public comparison, or explicit research needs appear, pause implementation and load `deep-research` or route to the researcher posture first.
+6. For outside evidence: repo first, official docs next, Reddit/community only as labeled secondary evidence.
 
 If command arguments are provided, treat them as additional user context.
 '''

package/workflows/workflows/agent-environment-setup/platforms/gemini/commands/backend.toml

@@ -7,6 +7,8 @@ Execution contract:
 2. Confirm the request fits the workflow's "When to use" section.
 3. Execute according to "Workflow steps" and apply "Context notes".
 4. Complete "Verification" checks and report concrete evidence.
+5. If freshness, public comparison, or explicit research needs appear, pause implementation and load `deep-research` or route to the researcher posture first.
+6. For outside evidence: repo first, official docs next, Reddit/community only as labeled secondary evidence.
 
 If command arguments are provided, treat them as additional user context.
 '''

package/workflows/workflows/agent-environment-setup/platforms/gemini/commands/create.toml

@@ -7,6 +7,8 @@ Execution contract:
 2. Confirm the request fits the workflow's "When to use" section.
 3. Execute according to "Workflow steps" and apply "Context notes".
 4. Complete "Verification" checks and report concrete evidence.
+5. If freshness, public comparison, or explicit research needs appear, pause implementation and load `deep-research` or route to the researcher posture first.
+6. For outside evidence: repo first, official docs next, Reddit/community only as labeled secondary evidence.
 
 If command arguments are provided, treat them as additional user context.
 '''

package/workflows/workflows/agent-environment-setup/platforms/gemini/commands/database.toml

@@ -7,6 +7,8 @@ Execution contract:
 2. Confirm the request fits the workflow's "When to use" section.
 3. Execute according to "Workflow steps" and apply "Context notes".
 4. Complete "Verification" checks and report concrete evidence.
+5. If freshness, public comparison, or explicit research needs appear, pause implementation and load `deep-research` or route to the researcher posture first.
+6. For outside evidence: repo first, official docs next, Reddit/community only as labeled secondary evidence.
 
 If command arguments are provided, treat them as additional user context.
 '''

package/workflows/workflows/agent-environment-setup/platforms/gemini/commands/debug.toml

@@ -7,6 +7,8 @@ Execution contract:
 2. Confirm the request fits the workflow's "When to use" section.
 3. Execute according to "Workflow steps" and apply "Context notes".
 4. Complete "Verification" checks and report concrete evidence.
+5. If freshness, public comparison, or explicit research needs appear, pause implementation and load `deep-research` or route to the researcher posture first.
+6. For outside evidence: repo first, official docs next, Reddit/community only as labeled secondary evidence.
 
 If command arguments are provided, treat them as additional user context.
 '''

package/workflows/workflows/agent-environment-setup/platforms/gemini/commands/devops.toml

@@ -7,6 +7,8 @@ Execution contract:
 2. Confirm the request fits the workflow's "When to use" section.
 3. Execute according to "Workflow steps" and apply "Context notes".
 4. Complete "Verification" checks and report concrete evidence.
+5. If freshness, public comparison, or explicit research needs appear, pause implementation and load `deep-research` or route to the researcher posture first.
+6. For outside evidence: repo first, official docs next, Reddit/community only as labeled secondary evidence.
 
 If command arguments are provided, treat them as additional user context.
 '''