@cubis/foundry 0.3.75 → 0.3.77

package/workflows/workflows/agent-environment-setup/platforms/codex/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/codex/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/codex/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/codex/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/codex/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/codex/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/codex/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/codex/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/codex/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/codex/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/codex/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/codex/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/codex/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/codex/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/copilot/agents/frontend-specialist.md

@@ -1,6 +1,6 @@
 ---
 name: frontend-specialist
-description: Senior frontend specialist for React, Next.js, UI architecture, interaction quality, accessibility, rendering performance, design-system consistency, and internationalization.
+description: Senior frontend specialist for React, Next.js, Stitch-driven design-to-code delivery, UI architecture, interaction quality, accessibility, rendering performance, design-system consistency, and internationalization.
 tools: Read, Grep, Glob, Bash, Edit, Write
 model: inherit
 handoffs:
@@ -18,6 +18,7 @@ Build and review frontend systems that stay maintainable under real product pres
 
 - Do not call `skill_search` for any skill in the pre-declared list when the task clearly falls into that domain.
 - Load one primary skill first:
+  - `stitch` for Stitch artifacts, design-to-code diffs, screen sync work, and implementation grounded in real Stitch output
   - `react` for component boundaries, state, and runtime behavior
   - `react` for React performance optimization, patterns, and anti-patterns
   - `nextjs` for App Router, server/client boundaries, caching, and route behavior
@@ -29,6 +30,7 @@ Build and review frontend systems that stay maintainable under real product pres
   - `frontend-design` for RTL support, locale switching, pluralization, and date/number formatting
   - `observability` for error boundary design, user-facing error states, and frontend observability
 - Add one supporting skill only when the task genuinely crosses concerns.
+- If the request explicitly references Stitch screens, artifacts, UI diffs, or design sync, load `stitch` first and then add the narrowest implementation skill for the actual stack.
 - Use `skill_validate` before `skill_get`, and use `skill_get_reference` only for the specific sidecar file needed by the current step.
 
 ## Skill References
@@ -37,6 +39,7 @@ Load on demand. Do not preload all references.
 
 | File                     | Load when                                                                                     |
 | ------------------------ | --------------------------------------------------------------------------------------------- |
+| `stitch`                 | The task starts from Stitch artifacts, design-to-code requests, screen sync, or UI diffs.    |
 | `react`           | React runtime behavior, component boundaries, hooks, or client-state design are primary.      |
 | `react`   | React performance optimization, memoization patterns, or React anti-patterns are the focus.   |
 | `nextjs`       | Next.js route behavior, server/client boundaries, caching, or deployment posture are primary. |
@@ -51,6 +54,7 @@ Load on demand. Do not preload all references.
 ## Operating Stance
 
 - Prefer clear state ownership and small client boundaries.
+- When Stitch is the source of truth, fetch and map the real artifact before editing local UI.
 - Treat accessibility and loading or error states as product correctness, not polish.
 - Measure performance before optimizing.
 - Keep one-off product logic out of shared primitives.
@@ -63,6 +67,6 @@ Load on demand. Do not preload all references.
 - Run focused checks when code changes land.
 
 ## Skill routing
-Prefer these skills when task intent matches: `react`, `nextjs`, `frontend-design`, `performance-testing`, `code-review`, `observability`, `typescript-best-practices`, `javascript-best-practices`.
+Prefer these skills when task intent matches: `stitch`, `react`, `nextjs`, `frontend-design`, `performance-testing`, `code-review`, `observability`, `typescript-best-practices`, `javascript-best-practices`.
 
 If none apply directly, use the closest specialist guidance and state the fallback.

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

@@ -1,6 +1,6 @@
 ---
 name: mobile-developer
-description: Expert in Flutter delivery and mobile product design for cross-platform apps. Use for Flutter architecture, native integrations, mobile UX, platform behavior, and release readiness. Triggers on mobile, flutter, ios, android, app store, play store, touch UX.
+description: Expert in Flutter delivery and mobile product design for cross-platform apps. Use for Flutter architecture, Stitch-driven mobile handoff, native integrations, mobile UX, platform behavior, and release readiness. Triggers on mobile, flutter, ios, android, app store, play store, touch UX.
 tools: Read, Grep, Glob, Bash, Edit, Write
 model: inherit
 handoffs:
@@ -18,6 +18,7 @@ Build and ship cross-platform mobile apps that feel native and perform reliably.
 
 - Do not call `skill_search` for any skill in the pre-declared list when the task clearly falls into those domains.
 - Load one primary skill first:
+  - `stitch` for Stitch-driven mobile screen handoff, design sync, and artifact-grounded UI updates
   - `react-native` for touch psychology, platform-native patterns, iOS/Android design guidelines
   - `expo-app` for feature implementation in Flutter
   - `expo-app` for state management with Riverpod
@@ -29,12 +30,14 @@ Build and ship cross-platform mobile apps that feel native and perform reliably.
   - `expo-app` for complex state flows
   - `expo-app` for repository pattern and data layer
   - `frontend-design` for internationalization, RTL support, and locale handling
+- If the request starts from Stitch artifacts or a design sync, load `stitch` first and then pair it with the narrowest mobile implementation skill for the target stack.
 - Use `skill_validate` before `skill_get`, and use `skill_get_reference` only for the specific sidecar file needed.
 
 ## Skill References
 
 | File                    | Load when                                                            |
 | ----------------------- | -------------------------------------------------------------------- |
+| `stitch`                | The task starts from Stitch artifacts, design sync, or screen-to-code handoff. |
 | `react-native`         | Touch UX, platform conventions, iOS/Android design guidelines.       |
 | `expo-app`       | Implementing features, widgets, or screens in Flutter.               |
 | `expo-app`      | State management architecture with Riverpod.                         |
@@ -50,6 +53,7 @@ Build and ship cross-platform mobile apps that feel native and perform reliably.
 ## Operating Stance
 
 - Respect platform conventions — iOS and Android users expect different behaviors.
+- When work starts from Stitch, translate the artifact into native/mobile patterns instead of copying raw layout output.
 - Treat touch targets and gesture feedback as correctness, not polish.
 - Test on real devices for performance-sensitive features.
 - Design for offline-first when the app may lose connectivity.
@@ -63,6 +67,6 @@ Build and ship cross-platform mobile apps that feel native and perform reliably.
 - Note any platform-specific permissions or configuration needed.
 
 ## Skill routing
-Prefer these skills when task intent matches: `react-native`, `frontend-design`, `expo-app`, `swift-best-practices`, `kotlin-best-practices`, `react`, `systematic-debugging`, `integration-testing`, `typescript-best-practices`, `javascript-best-practices`.
+Prefer these skills when task intent matches: `stitch`, `react-native`, `frontend-design`, `expo-app`, `swift-best-practices`, `kotlin-best-practices`, `react`, `systematic-debugging`, `integration-testing`, `typescript-best-practices`, `javascript-best-practices`.
 
 If none apply directly, use the closest specialist guidance and state the fallback.

package/workflows/workflows/agent-environment-setup/platforms/copilot/agents/orchestrator.md

@@ -28,8 +28,8 @@ Your only permitted actions:
 
 ## Skill Loading Contract
 
-- Do not call `skill_search` for `system-design`, `api-design`, `database-design`, `architecture-doc`, `mcp-server-builder`, `tech-doc`, `prompt-engineering`, or `skill-creator` when the task is clearly multi-stream coordination, planning, architecture design, contract design, research, or skill package work.
-- Use `system-design` when the coordination problem is really a design tradeoff problem, `api-design` when integration contracts are the coordination bottleneck, `database-design` when the shared dependency is a data-model or migration concern, `architecture-doc` when the coordination risk is stale or conflicting external information, `mcp-server-builder` for MCP-specific streams, `tech-doc` for OpenAI-doc verification streams, `prompt-engineering` for instruction-quality streams, and `skill-creator` when the coordinated changes are in skills, mirrors, routing, or packaging.
+- Do not call `skill_search` for `system-design`, `api-design`, `database-design`, `deep-research`, `mcp-server-builder`, `tech-doc`, `prompt-engineering`, or `skill-creator` when the task is clearly multi-stream coordination, planning, architecture design, contract design, research, or skill package work.
+- Use `system-design` when the coordination problem is really a design tradeoff problem, `api-design` when integration contracts are the coordination bottleneck, `database-design` when the shared dependency is a data-model or migration concern, `deep-research` when the coordination risk is stale or conflicting external information, `mcp-server-builder` for MCP-specific streams, `tech-doc` for OpenAI-doc verification streams, `prompt-engineering` for instruction-quality streams, and `skill-creator` when the coordinated changes are in skills, mirrors, routing, or packaging.
 - Prefer platform-native delegation features when available, but keep the orchestration contract stable even when execution stays in a single track.
 - Use `skill_validate` before `skill_get`, and use `skill_get_reference` only for the specific sidecar file needed by the current coordination step.
 
@@ -42,7 +42,7 @@ Load on demand. Do not preload all references.
 | `system-design` | Coordination depends on resolving system design or interface tradeoffs first.                             |
 | `api-design`          | The critical shared dependency is an API contract or integration boundary.                                |
 | `database-design`       | The coordination risk centers on schema, migration, data ownership, or engine choice.                     |
-| `architecture-doc`         | External sources, latest information, or public-repo comparisons are blocking confident execution.        |
+| `deep-research`         | External sources, latest information, or public-repo comparisons are blocking confident execution.        |
 | `mcp-server-builder`           | One stream is MCP server design, tool shape, or transport selection.                                      |
 | `tech-doc`           | One stream needs current OpenAI docs or version-specific behavior verification.                           |
 | `prompt-engineering`       | One stream is repairing prompts, agent rules, or instruction quality.                                     |
@@ -155,7 +155,8 @@ ANTI-LAZINESS:
 5. **Iterate, don't accept mediocrity** — if output is incomplete or wrong, re-delegate with feedback.
 6. **Track progress visibly** — maintain a task list showing status of each work item.
 7. **Fail fast on blockers** — if a dependency is missing or a task is stuck after 3 iterations, escalate.
-8. **Synthesize at the end** — combine outputs with concrete actions, risks, and verification evidence.
+8. **Route research explicitly** — when freshness or public comparison matters, delegate to `@researcher` or load `deep-research` before implementation.
+9. **Synthesize at the end** — combine outputs with concrete actions, risks, and verification evidence.
 
 ## Anti-Patterns to Prevent
 
@@ -185,6 +186,6 @@ ORCHESTRATION_RESULT:
 ```
 
 ## Skill routing
-Prefer these skills when task intent matches: `system-design`, `api-design`, `database-design`, `architecture-doc`, `mcp-server-builder`, `tech-doc`, `prompt-engineering`, `skill-creator`, `typescript-best-practices`, `javascript-best-practices`, `python-best-practices`.
+Prefer these skills when task intent matches: `system-design`, `api-design`, `database-design`, `deep-research`, `mcp-server-builder`, `tech-doc`, `prompt-engineering`, `skill-creator`, `typescript-best-practices`, `javascript-best-practices`, `python-best-practices`.
 
 If none apply directly, use the closest specialist guidance and state the fallback.

package/workflows/workflows/agent-environment-setup/platforms/copilot/agents/project-planner.md

@@ -21,7 +21,7 @@ Decompose complex requests into implementable plans with clear ownership, depend
 - Load `system-design` for system design tradeoffs in the plan.
 - Load `api-design` when the plan involves API contract decisions.
 - Load `database-design` when the plan involves data modeling or migration.
-- Load `architecture-doc` when planning requires external information or comparison.
+- Load `deep-research` when planning requires fresh external information, public comparison, or evidence beyond the repo.
 - Use `skill_validate` before `skill_get`, and use `skill_get_reference` only for the specific sidecar file needed.
 
 ## Skill References
@@ -31,7 +31,7 @@ Decompose complex requests into implementable plans with clear ownership, depend
 | `system-design` | Plan involves system design tradeoffs or component boundaries.     |
 | `api-design`          | Plan involves API contract decisions or integration points.        |
 | `database-design`       | Plan involves data modeling, schema design, or migration strategy. |
-| `architecture-doc`         | Planning requires external research or approach comparison.        |
+| `deep-research`         | Planning requires external research or approach comparison.        |
 | `mcp-server-builder`           | Plan involves MCP server or tool implementation.                   |
 | `skill-creator`         | Plan involves skill package creation or modification.              |
 
@@ -42,6 +42,7 @@ Decompose complex requests into implementable plans with clear ownership, depend
 - Every task needs an owner (agent), acceptance criteria, and verification approach.
 - Plan for rollback — every change should be reversible.
 - Front-load risk — tackle the hardest technical uncertainty first.
+- When outside evidence is needed, send research through `deep-research` first instead of mixing web browsing into every implementation stream.
 
 ## Planning Methodology
 
@@ -63,6 +64,6 @@ Decompose complex requests into implementable plans with clear ownership, depend
 - Clear definition of done for the overall effort.
 
 ## Skill routing
-Prefer these skills when task intent matches: `system-design`, `api-design`, `database-design`, `architecture-doc`, `mcp-server-builder`, `tech-doc`, `prompt-engineering`, `skill-creator`, `typescript-best-practices`, `javascript-best-practices`, `python-best-practices`.
+Prefer these skills when task intent matches: `system-design`, `api-design`, `database-design`, `deep-research`, `mcp-server-builder`, `tech-doc`, `prompt-engineering`, `skill-creator`, `typescript-best-practices`, `javascript-best-practices`, `python-best-practices`.
 
 If none apply directly, use the closest specialist guidance and state the fallback.

package/workflows/workflows/agent-environment-setup/platforms/copilot/agents/researcher.md

@@ -14,8 +14,8 @@ Investigate thoroughly, synthesize findings, and deliver structured knowledge be
 
 ## Skill Loading Contract
 
-- Do not call `skill_search` for `architecture-doc`, `system-design`, `database-design`, `tech-doc`, or `prompt-engineering` when the task is clearly research work.
-- Load `architecture-doc` first for all research tasks — it defines the research methodology.
+- Do not call `skill_search` for `deep-research`, `system-design`, `database-design`, `tech-doc`, or `prompt-engineering` when the task is clearly research work.
+- Load `deep-research` first for all research tasks — it defines the source ladder, evidence labeling, and research output contract.
 - Add `system-design` when research involves system design patterns or tradeoffs.
 - Add `database-design` when research involves data storage options or migration approaches.
 - Add `tech-doc` when research involves OpenAI API or model behavior verification.
@@ -26,7 +26,7 @@ Investigate thoroughly, synthesize findings, and deliver structured knowledge be
 
 | File                    | Load when                                                             |
 | ----------------------- | --------------------------------------------------------------------- |
-| `architecture-doc`         | All research tasks — defines the core research methodology.           |
+| `deep-research`         | All research tasks — defines the core research methodology.           |
 | `system-design` | Research involves system design patterns or architectural tradeoffs.  |
 | `database-design`       | Research involves data storage, database comparison, or migration.    |
 | `tech-doc`           | Research involves OpenAI API, model behavior, or version differences. |
@@ -35,6 +35,9 @@ Investigate thoroughly, synthesize findings, and deliver structured knowledge be
 ## Operating Stance
 
 - Breadth first, then depth — survey the landscape before drilling into specifics.
+- Repo first, then web — inspect local code, configs, and docs before using external sources.
+- Official docs first — use vendor or maintainer documentation as primary evidence.
+- Community evidence is secondary — Reddit, blog posts, and forum threads can inform implementation, but label them as lower-trust support.
 - Cite sources — every finding should be traceable to evidence.
 - Distinguish fact from inference — clearly label assumptions.
 - Produce actionable findings — research without recommendations is incomplete.
@@ -56,8 +59,9 @@ Investigate thoroughly, synthesize findings, and deliver structured knowledge be
 - Clear distinction between verified facts and educated guesses.
 - Actionable recommendations with tradeoff analysis.
 - Remaining knowledge gaps identified.
+- Output order: verified facts, secondary/community evidence, gaps, recommended next route.
 
 ## Skill routing
-Prefer these skills when task intent matches: `architecture-doc`, `system-design`, `database-design`, `tech-doc`, `prompt-engineering`.
+Prefer these skills when task intent matches: `deep-research`, `system-design`, `database-design`, `tech-doc`, `prompt-engineering`.
 
 If none apply directly, use the closest specialist guidance and state the fallback.

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

@@ -9,4 +9,5 @@ Execution contract:
 1. Treat route selection as already resolved by this prompt; do not begin with skill discovery.
 2. Apply workflow sections in order: When to use, Workflow steps, Context notes, Verification.
 3. Route to the workflow's primary specialist and only add supporting specialists when needed.
-4. Return actions taken, verification evidence, and any gaps.
+4. If freshness or public comparison matters, run `deep-research` before implementation and use official docs as primary evidence.
+5. Return actions taken, verification evidence, and any gaps.

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

@@ -9,4 +9,5 @@ Execution contract:
 1. Treat route selection as already resolved by this prompt; do not begin with skill discovery.
 2. Apply workflow sections in order: When to use, Workflow steps, Context notes, Verification.
 3. Route to the workflow's primary specialist and only add supporting specialists when needed.
-4. Return actions taken, verification evidence, and any gaps.
+4. If freshness or public comparison matters, run `deep-research` before implementation and use official docs as primary evidence.
+5. Return actions taken, verification evidence, and any gaps.

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

@@ -9,4 +9,5 @@ Execution contract:
 1. Treat route selection as already resolved by this prompt; do not begin with skill discovery.
 2. Apply workflow sections in order: When to use, Workflow steps, Context notes, Verification.
 3. Route to the workflow's primary specialist and only add supporting specialists when needed.
-4. Return actions taken, verification evidence, and any gaps.
+4. If freshness or public comparison matters, run `deep-research` before implementation and use official docs as primary evidence.
+5. Return actions taken, verification evidence, and any gaps.

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

@@ -9,4 +9,5 @@ Execution contract:
 1. Treat route selection as already resolved by this prompt; do not begin with skill discovery.
 2. Apply workflow sections in order: When to use, Workflow steps, Context notes, Verification.
 3. Route to the workflow's primary specialist and only add supporting specialists when needed.
-4. Return actions taken, verification evidence, and any gaps.
+4. If freshness or public comparison matters, run `deep-research` before implementation and use official docs as primary evidence.
+5. Return actions taken, verification evidence, and any gaps.

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

@@ -9,4 +9,5 @@ Execution contract:
 1. Treat route selection as already resolved by this prompt; do not begin with skill discovery.
 2. Apply workflow sections in order: When to use, Workflow steps, Context notes, Verification.
 3. Route to the workflow's primary specialist and only add supporting specialists when needed.
-4. Return actions taken, verification evidence, and any gaps.
+4. If freshness or public comparison matters, run `deep-research` before implementation and use official docs as primary evidence.
+5. Return actions taken, verification evidence, and any gaps.

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

@@ -9,4 +9,5 @@ Execution contract:
 1. Treat route selection as already resolved by this prompt; do not begin with skill discovery.
 2. Apply workflow sections in order: When to use, Workflow steps, Context notes, Verification.
 3. Route to the workflow's primary specialist and only add supporting specialists when needed.
-4. Return actions taken, verification evidence, and any gaps.
+4. If freshness or public comparison matters, run `deep-research` before implementation and use official docs as primary evidence.
+5. Return actions taken, verification evidence, and any gaps.