@cubis/foundry 0.3.75 → 0.3.77

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/deep-research/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: deep-research
+description: Use when investigating latest vendor behavior, comparing tools or platforms, verifying claims beyond the repo, or gathering external evidence before implementation.
+allowed-tools: Read Grep Glob Bash
+context: fork
+agent: researcher
+user-invocable: true
+argument-hint: "Topic, vendor capability, or public comparison to research"
+---
+
+# Deep Research
+
+## Purpose
+
+Run a disciplined research pass before implementation when the repo alone is not enough. This skill keeps research evidence-driven: inspect the local codebase first, escalate to official docs when freshness or public comparison matters, then use labeled community evidence only when it adds practical context.
+
+## When to Use
+
+- Verifying latest SDK, CLI, API, or platform behavior
+- Comparing tools, frameworks, hosted services, or implementation approaches
+- Checking whether public docs and the local repo disagree
+- Gathering external evidence before planning a migration or new capability
+- Producing a structured research brief that hands off cleanly into implementation
+
+## Instructions
+
+1. **Define the research question before collecting sources** because vague research sprawls quickly. Restate the target topic, freshness requirement, comparison axis, and what decision the findings need to support.
+
+2. **Inspect the repo first** because many questions are already answerable from local code, configs, tests, docs, or generated assets. Do not browse externally until the local evidence is exhausted or clearly insufficient.
+
+3. **Decide whether external research is actually required** because not every task needs web evidence. Escalate only when freshness matters, public comparison matters, or the user explicitly asks to research or verify.
+
+4. **Follow the source ladder strictly** because evidence quality matters. Use official docs, upstream repositories, standards, and maintainer material as primary sources before looking at blogs, issue threads, or Reddit.
+
+5. **Capture concrete source details** because research without provenance is hard to trust. Record exact links, relevant dates, versions, and any repo files that support or contradict the external evidence.
+
+6. **Cross-check important claims across more than one source when possible** because public docs, repos, and community advice can drift. If sources disagree, say so explicitly instead of smoothing over the conflict.
+
+7. **Use Reddit and other community sources only as labeled secondary evidence** because they can surface practical gotchas but are not authoritative. Treat them as implementation color, not final truth.
+
+8. **Separate verified facts from inference** because downstream planning depends on confidence. Mark what is directly supported by repo evidence or official sources versus what you infer from patterns or secondary signals.
+
+9. **Keep the output decision-oriented** because the goal is not to dump links. Tie each finding back to the implementation, workflow, agent, or skill decision it affects.
+
+10. **Recommend the next route explicitly** because research is usually a handoff, not the end of the task. Name the next workflow, agent, or exact skill that should continue the work.
+
+11. **State the remaining gaps and risks** because incomplete research is still useful when the uncertainty is visible. Call out what you could not verify, what may have changed recently, and what assumptions remain.
+
+12. **Avoid over-quoting and over-collecting** because research quality comes from synthesis, not volume. Prefer concise summaries with high-signal citations over long pasted excerpts.
+
+13. **When the task turns into implementation, stop researching and hand off** because mixing discovery and execution usually creates drift. Deliver the research brief first, then route into the correct workflow or specialist.
+
+## Output Format
+
+Deliver:
+
+1. **Research question** — topic, freshness requirement, and decision to support
+2. **Verified facts** — repo evidence and primary-source findings
+3. **Secondary/community evidence** — labeled lower-trust supporting signals
+4. **Gaps / unknowns** — unresolved questions or contradictory evidence
+5. **Recommended next route** — direct execution, workflow, agent, or exact skill to use next
+
+## References
+
+Load only the file needed for the current question.
+
+| File | Load when |
+| --- | --- |
+| `references/source-ladder.md` | Need the repo-first and source-priority policy for official docs versus community evidence. |
+| `references/research-output.md` | Need the structured output format, evidence labeling rules, or handoff pattern. |
+| `references/comparison-checklist.md` | Comparing vendors, frameworks, or tools and need a concrete evaluation frame. |
+
+## Examples
+
+Use these when the task shape already matches.
+
+| File | Use when |
+| --- | --- |
+| `examples/01-latest-docs-check.md` | Verifying a latest capability or doc claim before implementation. |
+| `examples/02-ecosystem-comparison.md` | Comparing multiple tools or platforms with official-first sourcing. |
+| `examples/03-research-to-implementation-handoff.md` | Turning research findings into a concrete next workflow or specialist handoff. |
+
+## Claude Research Flow
+
+- Use `$ARGUMENTS` as the research topic when this skill is invoked directly.
+- Prefer official docs, upstream repos, and maintainer material before blog posts or Reddit threads.
+- If Claude hook templates are installed, let them reinforce repo-first inspection and research escalation, but keep the final research output aligned with this skill's evidence contract.
+
+## Claude Platform Notes
+
+- Use `$ARGUMENTS` to access user-provided arguments passed when the skill is invoked.
+- Reference skill-local files with `${CLAUDE_SKILL_DIR}/references/<file>` for portable paths.
+- When `context: fork` is set, the skill runs in an isolated subagent context; the `agent` field names the fork target.
+- MCP skill tools (`skill_search`, `skill_get`, `skill_validate`, `skill_get_reference`) are available for dynamic skill discovery and loading.
+- Use `allowed-tools` in frontmatter to restrict tool access for security-sensitive skills.

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/deep-research/evals/assertions.md

@@ -0,0 +1,17 @@
+# Deep Research Eval Assertions
+
+## Eval 1: Latest Capability Verification
+
+1. **repo-first** — Starts by checking repo or local evidence before jumping to web claims.
+2. **official-first** — Uses official docs or upstream sources as the primary evidence for the capability.
+3. **secondary-labeled** — If community sources are mentioned, labels them as secondary evidence instead of presenting them as authoritative.
+4. **gaps-called-out** — Identifies unresolved uncertainty or missing confirmation.
+5. **next-route** — Ends with a concrete recommended workflow, agent, or skill to use next.
+
+## Eval 2: Tool Comparison
+
+1. **comparison-frame** — Defines the comparison axes instead of producing vague preferences.
+2. **repo-impact** — Connects the comparison back to the current repo or implementation constraints.
+3. **fact-vs-inference** — Separates verified facts from inference or interpretation.
+4. **decision-oriented** — Produces a recommendation or explicit defer condition.
+5. **no-research-sprawl** — Keeps the output concise and structured rather than dumping raw links.

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/deep-research/evals/evals.json

@@ -0,0 +1,56 @@
+[
+  {
+    "name": "latest-capability-verification",
+    "description": "Validate that the skill performs repo-first research, prioritizes official documentation, labels secondary evidence, and recommends a next route.",
+    "prompt": "Research whether the latest official Claude Code hook surface supports reinforcing route honoring before implementation. Start with the current repo state, then use official docs if needed. If community sources add useful practical context, include them but label them appropriately. End with the next workflow, agent, or skill we should use.",
+    "assertions": [
+      {
+        "id": "repo-first",
+        "description": "Starts with repo or local evidence before using external sources."
+      },
+      {
+        "id": "official-first",
+        "description": "Treats official docs or upstream sources as the primary evidence."
+      },
+      {
+        "id": "secondary-labeled",
+        "description": "Labels any Reddit or community evidence as secondary rather than authoritative."
+      },
+      {
+        "id": "gaps-called-out",
+        "description": "States any unresolved gaps, conflicts, or unknowns."
+      },
+      {
+        "id": "next-route",
+        "description": "Ends with a concrete recommended next route."
+      }
+    ]
+  },
+  {
+    "name": "tool-comparison",
+    "description": "Validate that the skill compares options with a clear frame, ties findings back to repo impact, and produces a decision-ready output.",
+    "prompt": "Compare whether our CLI should keep enforcement in Gemini command wrappers only or also add Claude hook templates. Use the repo state first, then official docs for current platform capabilities, and include community evidence only if it adds implementation nuance. Finish with a recommendation and the next route to take.",
+    "assertions": [
+      {
+        "id": "comparison-frame",
+        "description": "Defines concrete comparison axes such as repo impact, enforcement surface, and maintenance cost."
+      },
+      {
+        "id": "repo-impact",
+        "description": "Connects each option back to the current repo or bundle behavior."
+      },
+      {
+        "id": "fact-vs-inference",
+        "description": "Separates verified facts from inference or interpretation."
+      },
+      {
+        "id": "decision-oriented",
+        "description": "Produces a recommendation or explicit defer condition."
+      },
+      {
+        "id": "no-research-sprawl",
+        "description": "Keeps the answer structured instead of turning into an unfiltered dump of sources."
+      }
+    ]
+  }
+]

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/deep-research/examples/01-latest-docs-check.md

@@ -0,0 +1,12 @@
+# Example: Latest Docs Check
+
+## User Request
+
+> Research whether Claude Code hooks can reinforce route honoring before we add new workflow rules.
+
+## Expected Shape
+
+1. Inspect the repo's current Claude rule and hook support first.
+2. Verify the current official Claude docs for hooks, event names, and config format.
+3. Separate those verified facts from any community commentary about hook effectiveness.
+4. End with the recommended next route, for example `@researcher` continuing the research or `/create` applying the validated hook template changes.

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/deep-research/examples/02-ecosystem-comparison.md

@@ -0,0 +1,12 @@
+# Example: Ecosystem Comparison
+
+## User Request
+
+> Compare whether our CLI should keep Gemini command enforcement only, or add another platform-native hook layer for Claude as well.
+
+## Expected Shape
+
+1. Start with repo constraints and current platform bundle behavior.
+2. Compare the official platform capabilities using primary docs.
+3. Add any useful community evidence as clearly labeled secondary input.
+4. Produce a recommendation tied to the repo: which platform gets which enforcement surface, and why.

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/deep-research/examples/03-research-to-implementation-handoff.md

@@ -0,0 +1,12 @@
+# Example: Research To Implementation Handoff
+
+## User Request
+
+> Research the latest Codex, Claude, and Gemini MCP behavior, then tell me the next route to update our workflow rules safely.
+
+## Expected Shape
+
+1. Gather repo evidence first.
+2. Verify current official docs for each platform.
+3. Summarize verified facts, secondary evidence, and gaps.
+4. End with a precise next route such as `/plan` for a policy change or `skill-creator` for skill/rule packaging work.

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/deep-research/references/comparison-checklist.md

@@ -0,0 +1,57 @@
+# Comparison Checklist
+
+Use this when evaluating tools, frameworks, APIs, or platforms.
+
+## 1. Scope the Comparison
+
+Define:
+
+- what is being compared
+- whether the comparison is about implementation fit, operational cost, or product capability
+- what time horizon matters: immediate migration, medium-term maintenance, or long-term platform fit
+
+## 2. Compare on Stable Axes
+
+Use a short set of dimensions:
+
+- integration fit with the current repo
+- maturity and maintenance signal
+- official documentation quality
+- configuration complexity
+- ecosystem and tooling support
+- operational constraints
+- migration cost
+
+Do not compare on vague criteria like "better DX" without concrete evidence.
+
+## 3. Capture Repo Impact
+
+Tie each option back to the current codebase:
+
+- what code would change
+- which workflows or agents would own the work
+- what risks are specific to this repo
+- whether new MCP tools or skills would be required
+
+## 4. Separate Product Claims from Team Constraints
+
+An option can be technically stronger and still be a worse fit for the repo.
+
+Keep these separate:
+
+- product capability
+- ecosystem quality
+- team familiarity
+- migration blast radius
+- existing architecture constraints
+
+## 5. Decision Frame
+
+Finish with one of:
+
+- recommend option A
+- recommend option B
+- defer decision pending one missing verification
+- keep current approach because switching cost outweighs gain
+
+If the evidence is mixed, say what would change the recommendation.

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/deep-research/references/research-output.md

@@ -0,0 +1,69 @@
+# Research Output Contract
+
+## Required Sections
+
+### 1. Research question
+
+State:
+
+- the exact topic
+- why research was necessary
+- whether freshness or public comparison mattered
+- the decision this research is meant to support
+
+### 2. Verified facts
+
+List the strongest findings first.
+
+For each fact:
+
+- state the claim in one sentence
+- cite the source class: repo, official docs, upstream repo, standard
+- include the relevant link or file path
+- include date/version when it matters
+
+### 3. Secondary / community evidence
+
+Only include this when it adds signal the primary sources did not provide.
+
+For each item:
+
+- label it as secondary evidence
+- state what practical signal it adds
+- avoid presenting it as settled fact
+
+### 4. Gaps / unknowns
+
+Document:
+
+- unresolved conflicts
+- missing official confirmation
+- assumptions that still need validation
+- risks if the team proceeds anyway
+
+### 5. Recommended next route
+
+Research should end with one clear recommendation:
+
+- direct execution
+- a specific workflow like `/plan` or `/create`
+- a specialist like `@researcher` or `@frontend-specialist`
+- an exact skill like `stitch` or `deep-research`
+
+Keep this recommendation concrete enough that the next step does not need another routing pass.
+
+## Compression Rules
+
+- Prefer 5 strong findings over 20 weak ones.
+- Do not paste long quotes from docs when a citation plus summary will do.
+- If multiple sources say the same thing, summarize once and cite the strongest source.
+- If research found nothing reliable, say that directly.
+
+## Handoff Pattern
+
+When handing off to implementation or planning, include:
+
+- the decision summary
+- the highest-confidence constraints
+- the unresolved risks
+- the next route to take

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/deep-research/references/source-ladder.md

@@ -0,0 +1,81 @@
+# Source Ladder
+
+## Goal
+
+Use the smallest amount of external research that still produces a decision-ready answer. Keep the evidence traceable and ordered by trust.
+
+## 1. Repo / Local Evidence First
+
+Start by inspecting:
+
+- application code and tests
+- README files and internal docs
+- generated workflow or skill assets
+- lockfiles, config files, and package manifests
+- existing integration code and migration history
+
+If the repo already answers the question, stop there. Do not browse externally just because web research feels safer.
+
+## 2. Primary External Sources
+
+Use these next:
+
+- official vendor docs
+- upstream repositories and release notes
+- standards bodies and reference specs
+- maintainer-authored examples
+
+Prefer sources that expose:
+
+- exact feature names
+- current version constraints
+- config formats
+- dates or changelog context
+
+When the topic is time-sensitive, capture the date you verified the source and the version or doc page involved.
+
+## 3. Secondary / Community Sources
+
+Use these only after primary evidence:
+
+- Reddit threads
+- issue comments
+- independent blog posts
+- forum discussions
+- third-party comparison articles
+
+Community evidence is useful for:
+
+- practical gotchas
+- migration pain points
+- missing-doc workarounds
+- real-world adoption patterns
+
+Community evidence is not enough on its own for authoritative claims about product behavior, supported configuration, or security guarantees.
+
+## 4. Conflict Handling
+
+When sources disagree:
+
+1. Prefer repo evidence for the current codebase state.
+2. Prefer official docs over community claims for product behavior.
+3. Prefer newer dated material when the sources cover the same feature.
+4. If the conflict remains unresolved, report it as a gap instead of guessing.
+
+## 5. Evidence Labels
+
+Use these labels in research output:
+
+- **Verified fact** — backed by repo evidence or a primary source
+- **Secondary evidence** — backed only by community or indirect sources
+- **Inference** — reasoned conclusion not directly stated by a source
+- **Gap** — could not be verified confidently
+
+## 6. Stop Conditions
+
+Stop researching when:
+
+- the decision is already clear
+- new sources only repeat the same point
+- the remaining uncertainty is small and clearly documented
+- the task should move into implementation or planning

package/workflows/workflows/agent-environment-setup/platforms/claude/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": ".claude/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": ".claude/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/claude/skills/stitch/SKILL.md

@@ -0,0 +1,93 @@
+---
+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.
+allowed-tools: Read Grep Glob Bash Edit Write
+context: fork
+agent: frontend-specialist
+user-invocable: true
+argument-hint: "Stitch screen, design artifact, or UI diff to implement"
+---
+
+# 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. |
+
+## Claude Stitch Flow
+
+- Use `$ARGUMENTS` as the requested Stitch screen or implementation brief when this skill is invoked directly.
+- Resolve any extra guidance from `${CLAUDE_SKILL_DIR}/references/platform-setup.md`, `${CLAUDE_SKILL_DIR}/references/implementation-patterns.md`, and `${CLAUDE_SKILL_DIR}/references/update-diff-workflow.md`.
+- Start with Foundry gateway + Stitch status checks, then hand the concrete implementation work to the frontend-specialist fork only after the target artifact and destination surface are clear.
+
+## Claude Platform Notes
+
+- Use `$ARGUMENTS` to access user-provided arguments passed when the skill is invoked.
+- Reference skill-local files with `${CLAUDE_SKILL_DIR}/references/<file>` for portable paths.
+- When `context: fork` is set, the skill runs in an isolated subagent context; the `agent` field names the fork target.
+- MCP skill tools (`skill_search`, `skill_get`, `skill_validate`, `skill_get_reference`) are available for dynamic skill discovery and loading.
+- Use `allowed-tools` in frontmatter to restrict tool access for security-sensitive skills.

package/workflows/workflows/agent-environment-setup/platforms/claude/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.