@cubis/foundry 0.3.83 → 0.3.84

package/workflows/skills/frontend-design-core/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: frontend-design-core
+description: Establish the design-engine execution order, canonical design-state model, and the repo-first constraints for serious frontend or mobile design work.
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "1.0"
+compatibility: Claude Code, Codex, GitHub Copilot, Gemini CLI, Antigravity
+---
+
+# Frontend Design Core
+
+## Purpose
+
+Define the design-engine control flow before any UI generation or implementation work starts. This skill resolves canonical design state, chooses the right overlays, and keeps design prep ahead of Stitch or implementation.
+
+## When to Use
+
+- Starting a design-heavy feature, redesign, or new screen set
+- Resolving `docs/foundation/DESIGN.md` and page/flow/mobile overlays
+- Turning vague UX intent into a design-engine plan before code or Stitch calls
+- Coordinating design work across web, Stitch, and Flutter/mobile outputs
+
+## Instructions
+
+1. **Treat `docs/foundation/DESIGN.md` as canonical** — Every design-heavy task starts from the canonical design system document. `.stitch/DESIGN.md` is a generated compatibility mirror only.
+2. **Resolve overlays in a fixed order** — Start with the canonical design system, then load any relevant overlay from `docs/foundation/design/pages`, `docs/foundation/design/flows`, or `docs/foundation/design/mobile`, then produce the task-specific screen brief.
+3. **Keep external research out of the runtime path** — Use only Foundry-owned normalized datasets from `workflows/design-datasets/*.json` during execution. Do not paste raw external source text into prompts.
+4. **Choose the smallest design capability set** — Use `frontend-design-style-selector` to choose the visual direction, `frontend-design-system` when the design state is missing or stale, `frontend-design-screen-brief` when the task needs a concrete screen brief, `frontend-design-mobile-patterns` for Flutter/mobile-specific adaptation, and `frontend-design-implementation-handoff` when translating the result into production code.
+5. **Do not let Stitch lead the thinking** — Stitch generation or edits happen only after the design state and screen brief are ready.
+
+## Output Format
+
+Deliver:
+
+1. Canonical design inputs used
+2. Applied overlays
+3. Design-engine capability stack selected
+4. Next action: design-system, screen-brief, Stitch, or implementation
+

package/workflows/skills/frontend-design-implementation-handoff/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: frontend-design-implementation-handoff
+description: Translate design-engine output into repo-native implementation work, preferring real components, Flutter widgets, and existing tokens over pasted generated markup.
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "1.0"
+compatibility: Claude Code, Codex, GitHub Copilot, Gemini CLI, Antigravity
+---
+
+# Frontend Design Implementation Handoff
+
+## Purpose
+
+Convert the design-engine result into implementation work that matches the repo's real stack and components instead of copying raw generated artifacts.
+
+## When to Use
+
+- After Stitch returns a screen artifact
+- After a design screen brief is approved for implementation
+- When moving from design state into Flutter, React, or another real UI stack
+
+## Instructions
+
+1. **Prefer existing components and tokens first** — Reuse the repo's real primitives before creating new visual fragments.
+2. **Translate semantics, not markup** — A generated artifact is a seed. Rebuild it in the target stack using the same hierarchy and state model.
+3. **For Flutter, map into widgets and theme tokens** — Use theme extensions, shared cards, section headers, and navigation widgets instead of porting web structure literally.
+4. **Preserve the brief's anti-slop constraints** — Distinctive typography, component rhythm, and motion rules should survive the handoff.
+5. **Leave QA hooks behind** — Ensure semantics labels, stable copy, and navigable flows are good enough for `flutter-mobile-qa` or frontend tests.
+
+## Output Format
+
+Deliver:
+
+1. Implementation plan
+2. Components/widgets to create or reuse
+3. Token/theme mapping
+4. QA-readiness notes
+

package/workflows/skills/frontend-design-mobile-patterns/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: frontend-design-mobile-patterns
+description: Adapt the design engine to mobile and Flutter surfaces using Foundry's normalized mobile-pattern dataset and implementation-first constraints.
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "1.0"
+compatibility: Claude Code, Codex, GitHub Copilot, Gemini CLI, Antigravity
+---
+
+# Frontend Design Mobile Patterns
+
+## Purpose
+
+Translate the design engine into mobile-specific decisions that survive real Flutter implementation instead of staying as web-first UI ideas.
+
+## When to Use
+
+- Designing Flutter screens, flows, or navigation
+- Adapting a Stitch-inspired concept into a mobile-native screen brief
+- Reviewing whether a design will survive small screens and thumb-driven interaction
+
+## Instructions
+
+1. **Load `workflows/design-datasets/mobile-patterns.json` first** — Use it to shape navigation placement, card rhythm, CTA placement, and progress visibility.
+2. **Design for thumb reach and scroll rhythm** — Primary actions should stay reachable and section breaks should remain scannable on smaller screens.
+3. **Prefer Flutter-feasible patterns** — Avoid browser-specific assumptions like hover-led navigation or overly dense freeform layouts that do not translate well to Flutter widgets.
+4. **Write implementation cues, not Figma prose** — Specify scaffold usage, navigation model, card rhythm, token usage, and expected widget states.
+5. **Feed the result into `frontend-design-implementation-handoff` and `flutter-mobile-qa`** — Mobile design is not complete until implementation and QA can consume the same brief.
+
+## Output Format
+
+Deliver:
+
+1. Mobile-specific layout notes
+2. Navigation and CTA placement rules
+3. Widget/state expectations
+4. Flutter feasibility notes
+

package/workflows/skills/frontend-design-screen-brief/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: frontend-design-screen-brief
+description: Turn canonical design state plus overlays into a compact, high-signal screen brief for Stitch, frontend implementation, or Flutter/mobile work.
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "1.0"
+compatibility: Claude Code, Codex, GitHub Copilot, Gemini CLI, Antigravity
+---
+
+# Frontend Design Screen Brief
+
+## Purpose
+
+Produce the compact screen-level brief that downstream tools or engineers can execute without losing the product's visual and interaction intent.
+
+## When to Use
+
+- Preparing a Stitch generation or edit prompt
+- Creating a Flutter/mobile screen implementation brief
+- Turning a broad design system into a concrete page or flow
+
+## Instructions
+
+1. **Resolve the design state first** — Read `docs/foundation/DESIGN.md` and any relevant overlay before writing the brief.
+2. **Describe behavior, not just appearance** — Include hierarchy, interaction states, content priority, empty states, and success/failure feedback.
+3. **Keep the prompt compact** — The screen brief should be concise enough for a remote service like Stitch and concrete enough for a human implementer.
+4. **Choose platform-specific emphasis** — For Flutter/mobile, emphasize thumb reach, section staging, safe areas, and navigation patterns. For web, emphasize layout elasticity and information density.
+5. **Write acceptance constraints** — Explicitly state what must be preserved and what generic shortcuts are not acceptable.
+
+## Output Format
+
+Deliver:
+
+1. Screen goal
+2. Hierarchy and layout summary
+3. Token and component cues
+4. Interaction/motion notes
+5. Anti-slop constraints
+

package/workflows/skills/frontend-design-style-selector/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: frontend-design-style-selector
+description: Select a non-generic visual direction from Foundry's normalized design datasets and align it to the product's domain, audience, and platform.
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "1.0"
+compatibility: Claude Code, Codex, GitHub Copilot, Gemini CLI, Antigravity
+---
+
+# Frontend Design Style Selector
+
+## Purpose
+
+Choose the visual direction before any screen or component work starts so the result has a deliberate point of view instead of a generic app-template look.
+
+## When to Use
+
+- Starting a new design system or screen family
+- Improving a weak or generic UI prompt before Stitch generation
+- Choosing a consistent mood for a Flutter/mobile app
+
+## Instructions
+
+1. **Use only Foundry datasets** — Load `workflows/design-datasets/style-directions.json`, `layout-patterns.json`, and `component-motifs.json` first.
+2. **Select one primary direction and one supporting motif** — Avoid mixing many vibes. State the lead direction, supporting motif, and what should be excluded.
+3. **Tie the direction to the product domain** — State why the chosen direction fits the product audience, task density, and emotional tone.
+4. **Write anti-slop constraints** — Explicitly call out the visual clichés to avoid, such as generic wellness gradients, default dashboard cards, or unstructured glassmorphism.
+5. **Feed the result into `frontend-design-system` or `frontend-design-screen-brief`** — This skill chooses direction; it does not finish the design state by itself.
+
+## Output Format
+
+Deliver:
+
+1. Primary style direction
+2. Supporting motif
+3. Excluded clichés
+4. Typography, palette, shape, and motion intent summary
+

package/workflows/skills/frontend-design-system/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: frontend-design-system
+description: Build or refresh the canonical design-system state for a repo, including DESIGN.md, overlays, token language, and platform-specific adaptation notes.
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "1.0"
+compatibility: Claude Code, Codex, GitHub Copilot, Gemini CLI, Antigravity
+---
+
+# Frontend Design System
+
+## Purpose
+
+Author and refresh the project's canonical design-system state so design, Stitch generation, and implementation share the same visual language.
+
+## When to Use
+
+- `docs/foundation/DESIGN.md` is missing or stale
+- A new design direction needs to be made durable
+- Multi-screen work needs consistent tokens and component vocabulary
+- A Flutter/mobile app needs a stable design foundation before implementation
+
+## Instructions
+
+1. **Create or refresh `docs/foundation/DESIGN.md`** — This file is the source of truth for visual direction, token language, component vocabulary, and motion rules.
+2. **Write scoped overlays only when needed** — Use the page overlays directory under `docs/foundation/design/pages/`, the flow overlays directory under `docs/foundation/design/flows/`, or the mobile overlays directory under `docs/foundation/design/mobile/` when a narrower slice of the product needs additional detail.
+3. **Use semantic token naming** — Load `workflows/design-datasets/token-language.json` and preserve semantic roles instead of raw color dumps.
+4. **Preserve source metadata in the authoring process, not the final doc body** — The final design docs should be crisp and implementation-oriented, but the chosen direction should come from normalized datasets with source provenance.
+5. **Mirror to `.stitch/DESIGN.md` when Stitch flows are in scope** — The mirror should be generated from the canonical state and applicable overlays, never hand-maintained separately.
+
+## Output Format
+
+Deliver:
+
+1. Canonical design-system summary
+2. Token language
+3. Component vocabulary
+4. Overlay files created or refreshed
+5. Whether `.stitch/DESIGN.md` was updated

package/workflows/skills/generated/anthropic-skill-intake.json

@@ -0,0 +1,208 @@
+{
+  "$schema": "cubis-foundry-external-skill-intake-v1",
+  "generatedAt": "1970-01-01T00:00:00.000Z",
+  "source": {
+    "id": "anthropic-agent-skills",
+    "label": "Anthropic Agent Skills",
+    "root": "research/plugins-claude/anthropic-agent-skills/example-skills/b0cbd3df1533",
+    "notes": "Curated intake of third-party Anthropic skills. Imported as Foundry compatibility mappings only; plugin/runtime structure is not mirrored."
+  },
+  "summary": {
+    "total": 17,
+    "keep": 2,
+    "adapt": 3,
+    "reject": 8,
+    "legal-review": 4,
+    "aliasApplied": 3,
+    "adoptedAliases": 3
+  },
+  "entries": [
+    {
+      "external_id": "algorithmic-art",
+      "status": "reject",
+      "canonical_skill_id": null,
+      "source_path": "research/plugins-claude/anthropic-agent-skills/example-skills/b0cbd3df1533/skills/algorithmic-art/SKILL.md",
+      "license": "Complete terms in LICENSE.txt",
+      "reason": "Creative artifact generation is outside the lean AI developer workspace core.",
+      "source_exists": true,
+      "canonical_skill_exists": true,
+      "action": "not-imported"
+    },
+    {
+      "external_id": "brand-guidelines",
+      "status": "reject",
+      "canonical_skill_id": null,
+      "source_path": "research/plugins-claude/anthropic-agent-skills/example-skills/b0cbd3df1533/skills/brand-guidelines/SKILL.md",
+      "license": "Complete terms in LICENSE.txt",
+      "reason": "Anthropic-specific branding guidance is not portable product engineering context.",
+      "source_exists": true,
+      "canonical_skill_exists": true,
+      "action": "not-imported"
+    },
+    {
+      "external_id": "canvas-design",
+      "status": "reject",
+      "canonical_skill_id": null,
+      "source_path": "research/plugins-claude/anthropic-agent-skills/example-skills/b0cbd3df1533/skills/canvas-design/SKILL.md",
+      "license": "Complete terms in LICENSE.txt",
+      "reason": "Static art generation does not belong in the default Foundry engineering catalog.",
+      "source_exists": true,
+      "canonical_skill_exists": true,
+      "action": "not-imported"
+    },
+    {
+      "external_id": "claude-api",
+      "status": "reject",
+      "canonical_skill_id": null,
+      "source_path": "research/plugins-claude/anthropic-agent-skills/example-skills/b0cbd3df1533/skills/claude-api/SKILL.md",
+      "license": "Complete terms in LICENSE.txt",
+      "reason": "Provider-specific Claude API guidance is not a cross-platform Foundry skill.",
+      "source_exists": true,
+      "canonical_skill_exists": true,
+      "action": "not-imported"
+    },
+    {
+      "external_id": "doc-coauthoring",
+      "status": "adapt",
+      "canonical_skill_id": "tech-doc",
+      "source_path": "research/plugins-claude/anthropic-agent-skills/example-skills/b0cbd3df1533/skills/doc-coauthoring/SKILL.md",
+      "license": "Complete terms in LICENSE.txt",
+      "reason": "The structured co-authoring workflow maps cleanly onto Foundry's technical documentation skill.",
+      "source_exists": true,
+      "canonical_skill_exists": true,
+      "action": "alias-added"
+    },
+    {
+      "external_id": "docx",
+      "status": "legal-review",
+      "canonical_skill_id": null,
+      "source_path": "research/plugins-claude/anthropic-agent-skills/example-skills/b0cbd3df1533/skills/docx/SKILL.md",
+      "license": "Proprietary. LICENSE.txt has complete terms",
+      "reason": "Document-processing implementation is valuable but the source-available license requires legal review before reuse.",
+      "source_exists": true,
+      "canonical_skill_exists": true,
+      "action": "not-imported"
+    },
+    {
+      "external_id": "frontend-design",
+      "status": "keep",
+      "canonical_skill_id": "frontend-design",
+      "source_path": "research/plugins-claude/anthropic-agent-skills/example-skills/b0cbd3df1533/skills/frontend-design/SKILL.md",
+      "license": "Complete terms in LICENSE.txt",
+      "reason": "This already matches an existing Foundry skill focus and naming surface.",
+      "source_exists": true,
+      "canonical_skill_exists": true,
+      "action": "kept-no-alias-needed"
+    },
+    {
+      "external_id": "internal-comms",
+      "status": "reject",
+      "canonical_skill_id": null,
+      "source_path": "research/plugins-claude/anthropic-agent-skills/example-skills/b0cbd3df1533/skills/internal-comms/SKILL.md",
+      "license": "Complete terms in LICENSE.txt",
+      "reason": "Internal communications templates are outside the core engineering workspace scope.",
+      "source_exists": true,
+      "canonical_skill_exists": true,
+      "action": "not-imported"
+    },
+    {
+      "external_id": "mcp-builder",
+      "status": "adapt",
+      "canonical_skill_id": "mcp-server-builder",
+      "source_path": "research/plugins-claude/anthropic-agent-skills/example-skills/b0cbd3df1533/skills/mcp-builder/SKILL.md",
+      "license": "Complete terms in LICENSE.txt",
+      "reason": "Foundry already has a canonical MCP server skill with a slightly different name.",
+      "source_exists": true,
+      "canonical_skill_exists": true,
+      "action": "alias-added"
+    },
+    {
+      "external_id": "pdf",
+      "status": "legal-review",
+      "canonical_skill_id": null,
+      "source_path": "research/plugins-claude/anthropic-agent-skills/example-skills/b0cbd3df1533/skills/pdf/SKILL.md",
+      "license": "Proprietary. LICENSE.txt has complete terms",
+      "reason": "PDF processing skill may be useful later but the proprietary terms block direct intake.",
+      "source_exists": true,
+      "canonical_skill_exists": true,
+      "action": "not-imported"
+    },
+    {
+      "external_id": "pptx",
+      "status": "legal-review",
+      "canonical_skill_id": null,
+      "source_path": "research/plugins-claude/anthropic-agent-skills/example-skills/b0cbd3df1533/skills/pptx/SKILL.md",
+      "license": "Proprietary. LICENSE.txt has complete terms",
+      "reason": "Presentation-processing skill may be useful later but the proprietary terms block direct intake.",
+      "source_exists": true,
+      "canonical_skill_exists": true,
+      "action": "not-imported"
+    },
+    {
+      "external_id": "skill-creator",
+      "status": "keep",
+      "canonical_skill_id": "skill-creator",
+      "source_path": "research/plugins-claude/anthropic-agent-skills/example-skills/b0cbd3df1533/skills/skill-creator/SKILL.md",
+      "license": "Complete terms in LICENSE.txt",
+      "reason": "This maps directly to Foundry's existing skill-creation capability.",
+      "source_exists": true,
+      "canonical_skill_exists": true,
+      "action": "kept-no-alias-needed"
+    },
+    {
+      "external_id": "slack-gif-creator",
+      "status": "reject",
+      "canonical_skill_id": null,
+      "source_path": "research/plugins-claude/anthropic-agent-skills/example-skills/b0cbd3df1533/skills/slack-gif-creator/SKILL.md",
+      "license": "Complete terms in LICENSE.txt",
+      "reason": "Slack GIF generation is outside the lean engineering catalog.",
+      "source_exists": true,
+      "canonical_skill_exists": true,
+      "action": "not-imported"
+    },
+    {
+      "external_id": "theme-factory",
+      "status": "reject",
+      "canonical_skill_id": null,
+      "source_path": "research/plugins-claude/anthropic-agent-skills/example-skills/b0cbd3df1533/skills/theme-factory/SKILL.md",
+      "license": "Complete terms in LICENSE.txt",
+      "reason": "Theme application across artifacts is broader than the current Foundry engineering scope.",
+      "source_exists": true,
+      "canonical_skill_exists": true,
+      "action": "not-imported"
+    },
+    {
+      "external_id": "web-artifacts-builder",
+      "status": "reject",
+      "canonical_skill_id": null,
+      "source_path": "research/plugins-claude/anthropic-agent-skills/example-skills/b0cbd3df1533/skills/web-artifacts-builder/SKILL.md",
+      "license": "Complete terms in LICENSE.txt",
+      "reason": "Claude artifact generation is platform-specific and would add a second artifact-builder model to Foundry.",
+      "source_exists": true,
+      "canonical_skill_exists": true,
+      "action": "not-imported"
+    },
+    {
+      "external_id": "webapp-testing",
+      "status": "adapt",
+      "canonical_skill_id": "playwright-interactive",
+      "source_path": "research/plugins-claude/anthropic-agent-skills/example-skills/b0cbd3df1533/skills/webapp-testing/SKILL.md",
+      "license": "Complete terms in LICENSE.txt",
+      "reason": "The Playwright-based local webapp testing workflow aligns with Foundry's interactive browser testing skill.",
+      "source_exists": true,
+      "canonical_skill_exists": true,
+      "action": "alias-added"
+    },
+    {
+      "external_id": "xlsx",
+      "status": "legal-review",
+      "canonical_skill_id": null,
+      "source_path": "research/plugins-claude/anthropic-agent-skills/example-skills/b0cbd3df1533/skills/xlsx/SKILL.md",
+      "license": "Proprietary. LICENSE.txt has complete terms",
+      "reason": "Spreadsheet-processing skill may be useful later but the proprietary terms block direct intake.",
+      "source_exists": true,
+      "canonical_skill_exists": true,
+      "action": "not-imported"
+    }
+  ]
+}