@cubis/foundry 0.3.75 → 0.3.77

package/workflows/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": ".agents/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": ".agents/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/skills/stitch/SKILL.md

@@ -0,0 +1,79 @@
+---
+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. |

package/workflows/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/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/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/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/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/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/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/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/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/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/generated/route-manifest.json

@@ -1,7 +1,7 @@
 {
   "$schema": "cubis-foundry-route-manifest-v1",
   "generatedAt": "1970-01-01T00:00:00.000Z",
-  "contentHash": "abcacb358643fc97",
+  "contentHash": "47cf8920e99d0258",
   "summary": {
     "totalRoutes": 40,
     "workflows": 18,
@@ -326,11 +326,15 @@
       "id": "frontend-specialist",
       "command": null,
       "displayName": "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.",
       "triggers": [
         "component",
         "react",
         "next",
+        "stitch",
+        "design-to-code",
+        "screen-to-code",
+        "ui diff",
         "ui",
         "ux",
         "css",
@@ -343,10 +347,11 @@
       "primaryAgent": "frontend-specialist",
       "supportingAgents": [],
       "primarySkills": [
-        "react",
-        "nextjs"
+        "stitch",
+        "react"
       ],
       "supportingSkills": [
+        "nextjs",
         "frontend-design",
         "performance-testing",
         "code-review",
@@ -425,7 +430,7 @@
       "id": "mobile-developer",
       "command": null,
       "displayName": "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.",
       "triggers": [
         "mobile",
         "flutter",
@@ -438,10 +443,11 @@
       "primaryAgent": "mobile-developer",
       "supportingAgents": [],
       "primarySkills": [
-        "react-native",
-        "frontend-design"
+        "stitch",
+        "react-native"
       ],
       "supportingSkills": [
+        "frontend-design",
         "expo-app",
         "swift-best-practices",
         "kotlin-best-practices",
@@ -492,7 +498,7 @@
       ],
       "supportingSkills": [
         "database-design",
-        "architecture-doc",
+        "deep-research",
         "mcp-server-builder",
         "tech-doc",
         "prompt-engineering",
@@ -695,7 +701,7 @@
       ],
       "supportingSkills": [
         "database-design",
-        "architecture-doc",
+        "deep-research",
         "mcp-server-builder",
         "tech-doc",
         "prompt-engineering",
@@ -798,7 +804,7 @@
       "primaryAgent": "researcher",
       "supportingAgents": [],
       "primarySkills": [
-        "architecture-doc",
+        "deep-research",
         "system-design"
       ],
       "supportingSkills": [
@@ -1310,6 +1316,7 @@
         "drizzle-orm",
         "database-design",
         "mcp-server-builder",
+        "stitch",
         "react",
         "nextjs",
         "frontend-design",
@@ -1639,6 +1646,7 @@
         "react-native"
       ],
       "supportingSkills": [
+        "stitch",
         "frontend-design",
         "expo-app",
         "swift-best-practices",
@@ -1686,7 +1694,7 @@
         "frontend-specialist"
       ],
       "primarySkills": [
-        "architecture-doc",
+        "deep-research",
         "system-design"
       ],
       "supportingSkills": [
@@ -1748,7 +1756,7 @@
       ],
       "supportingSkills": [
         "database-design",
-        "architecture-doc",
+        "deep-research",
         "mcp-server-builder",
         "tech-doc",
         "prompt-engineering",
@@ -1807,7 +1815,7 @@
       ],
       "supportingSkills": [
         "database-design",
-        "architecture-doc",
+        "deep-research",
         "mcp-server-builder",
         "tech-doc",
         "prompt-engineering",