/outsystems-design-to-app

name: outsystems-design-to-app
description: '[Beta] Drive ODC Mentor to bootstrap an OutSystems app from a design source — Figma URL, screenshot/image, HTML mockup, or structured front-end code (TSX/React/HTML, the highest-fidelity input). EXPERIMENTAL — greenfield-from-design layers on top of Mentor (built for in-flow edits) and fidelity varies; treat results as draft scaffolds, NOT ship-ready apps. Authors the design into a styling-complete spec.json (real OS UI blocks, not fake CSS; tokens, data model, sample data, chart series), then drives Mentor in batches and publishes. For prose-only briefs with NO concrete design or code, this skill does not apply. Use when the user asks to "build this design as an OutSystems app", "implement this Figma in OutSystems", "design to model", "design to app", "generate a screen from this mockup", "build this screen", or provides a Figma URL / image path / HTML or TSX file and wants it turned into a live OutSystems app. Not for OutSystems 11 (O11) or Service Studio.'
license: MIT
compatibility: Ships for Claude Code, Cursor and Kiro. Requires the `outsystems` MCP server connected and authenticated, with the session-based Mentor tools available, and builds on the main `outsystems` skill for session, polling and publish rules. Mentor must be enabled on the tenant. For Figma sources, the Figma MCP server must also be connected.
metadata:
  version: "1.7.0"
  author: outsystems-r-and-d
  maturity: beta

**Beta Feature.** This skill is a Beta Feature: a non-final OutSystems capability provided to collect customer feedback. It can change significantly, including through breaking changes, or be discontinued. The first time you use this skill in a conversation, tell the user it's a Beta Feature and share <https://www.outsystems.com/legal/beta-features-agreement>.

OutSystems Design-to-App

Turn a design source (Figma, screenshot, HTML mockup, or front-end code) into a working OutSystems app via the OutSystems MCP / Mentor. The skill bridges three things a vanilla LLM does poorly on its own: **design extraction**, **OutSystems UI domain knowledge**, and **Mentor invocation discipline**. It authors an anatomy-first spec (a per-screen widget-tree of real blocks with inline styles), gates every visual element through a real OutSystems UI block, and drives Mentor in tight batches.

**Load the main `outsystems` skill before Step 1: session, polling and publish rules come from it** (read the live tool catalog, one Mentor session per task, cursor polling and waiting from a fresh context where your harness offers one, confirm before every tenant write). This skill adds only what is specific to building from a design; where the two seem to differ, the main skill wins.

Prerequisites

• **The `outsystems` MCP server connected and authenticated**, per the main `outsystems` skill.
• **Mentor enabled on the tenant** (this skill drives Mentor).
• **Figma MCP server connected** if the design source is a Figma URL (its design-context, variables and screenshot tools, whatever your toolset calls them). For HTML / image / code sources, the Figma MCP is not required.
• **A target app.** Either an existing app the user names, or a new Web app the skill creates (after confirmation) from the standard template; see Steps 1 and 5.

When NOT to use

• **Just running Mentor with a free-form prompt** (no design source, no spec discipline needed): drive Mentor directly with your prompt.
• **Building from a written brief or spec with no design or code**: this skill does not apply; build it with Mentor directly, following the main `outsystems` skill.
• **Adding non-visual features to an existing app** (logic, data, integrations, no design source): drive Mentor directly with your prompt. Adding a **screen from a design** to an existing app *is* in scope: see "Adding a screen to an existing app" under Step 1.
• **Auditing / reviewing an existing app**: drive Mentor directly with your prompt.

Keep large data off the model's tokens

Figma's design-context output, the composed `spec.json` (15–80 KB) and a Mentor run's terminal events (50–500 KB) are all large. If a large result arrives inline, save it to the working folder and re-read only what you need; if the harness already saved it to disk, pass that path on and don't read the whole file into context.

**Working folder:** keep the build's files in a `design-to-app/<APP_NAME>/` folder inside the user's current workspace (create it with the file-write tool), not directly in the home folder or a configuration folder. See Working folder below.

Procedure

The full pipeline lives in `references/workflow.md`. The Mentor flow (create the app or reference the existing one, the two batches, publish) is in Steps 5 and 6; the generic session, polling and publish rules live in the main `outsystems` skill. The summary below is what you need to keep in context.

Step 1: Identify the design source + the target app

Ask the user and wait for an explicit answer: 1. **Design source** (required unless pre-built spec provided): Figma URL, image path, HTML file, web URL (screenshot it with a browser tool, then follow the image recipe), or **structured front-end code (TSX/React/HTML)**. A code source is the **highest-fidelity input**: it already states the tree, tokens, data model, and sample data (see `references/design-capture.md`, recipe B). 2. **App name** (required): target app in the OutSystems environment 3. **App context** (optional): anything the user already knows about the existing app (a `context.md`, notes). For an existing app the skill gathers the context itself anyway (see "Adding a screen to an existing app" below), so this is a supplement, not a requirement. 4. **Pre-built spec** (optional): skip extraction and composition (Steps 2 and 3), but still finish the app lookup below and run the Step 3c checks on the supplied spec before the Step 4 go/no-go.

App lookup (the live tool catalog decides which calls do each step;