matlab-build-app

# MATLAB Build App

Determine the best architecture for a MATLAB application, produce an implementation plan grounded in internal references, and execute the build. For UIFigure apps, optionally serialize into an App Designer format.

## When to Use This Skill

Use this skill when:
- User wants to build a MATLAB app, GUI, or interactive tool
- User asks "how should I build this app?" or "which approach should I use?"
- User describes an application — with or without specifying an implementation path
- User mentions: MATLAB app, GUI, uifigure, uihtml, interactive tool, dashboard, visualization app, App Designer, .mlapp, plain-text app
- User describes spatial layout needs: dashboard, control panel, sidebar, tabs, wizard, stepper, canvas, workspace
- User has already chosen a path (e.g., "build me a uihtml app") — handle directly

## When Not to Use

- The request is purely about MATLAB computation with no UI component
- The user is asking about an existing app they want to modify → read `references/editing-guide.md`
- The user wants to convert between App Designer formats (e.g., .mlapp to plain-text or vice versa) → tell them to use File > Save As in App Designer. Do NOT attempt the conversion programmatically.

## Critical Rules

- MUST ask discovery questions before recommending a path — unless the user already specified one
- MUST confirm the path choice with the user before producing the implementation plan
- MUST produce an implementation plan grounded in internal references before writing any code
- MUST write the plan to a file (`<app-name>-plan.md`) in the working directory
- NEVER recommend a path without understanding the user's constraints (unless path was pre-specified)
- NEVER apply dark mode, custom colors, or visual themes unless the user explicitly requests them
- ALWAYS present the recommendation as guidance, not a mandate — the user decides
- MUST choose archetype based on the user's primary task, not aesthetics
- NEVER treat two archetypes as equals within one app — one is always the primary container
- UIFigure app: MUST use `uigridlayout` for all structural layout — never `Position`-based sizing
- UIHTML/web app: MUST use CSS Grid or Flexbox for chrome — no absolute positioning for structural panels
- The chrome (header, sidebar, tabs, step indicator) MUST remain spatially stable
- App Designer serialization: MUST read `references/app-designer/agent-guide-shared.md` (covers ownership models, editing discipline, property rules, quoting) plus the format-specific guide (`agent-guide-mlapp.md` or `agent-guide-plaintext.md`) before building. Those docs are the single source of truth; do not attempt to edit app files without reading them first.

## Workflow

```
User request arrives
        │
        ├── Path NOT specified → Full Discovery
        │       │
        │       ▼
        │   Ask Q1-Q4 (purpose, lifespan, polish, team skills)
        │       │
        │       ▼
        │   Identify layout archetype
        │       │
        │       ▼
        │   Recommend UIFigure vs UIHTML based on Q1-Q4
        │       │
        │       ▼
        │   *** STOP: Present recommendation and WAIT for user confirmation ***
        │   (Do NOT produce a plan or read references until user says yes)
        │       │
        │       ▼
        │   Ask Q5 (FINAL): Serialization format? (UIFigure apps only)
        │       │
        │       ├── App Designer → release check, present format choice,
        │       │       continue with UIFigure references + add serialization step
        │       │
        │       └── Standalone programmatic → no extra step
        │       │
        │       ▼
        │   Produce Implementation Plan → write to <app-name>-plan.md
        │       │
        │       ▼
        │   User reviews plan → confirms or adjusts
        │       │
        │       ▼
        │   Begin building (read references per the plan)
        │
        └── Path IS specified
                │
                ├── Serialization explicit (e.g., ".mlapp app", "plain-text app")
                │       → Skip Q5, proceed with stated format
                │       → Ask only missing requirements + archetype if unclear
                │       → Produce Implementation Plan
                │
                ├── Architecture explicit but serialization not stated
                │   (e.g., "build me a uifigure app")
                │       → Still ask Q5 (serialization) before planning
                │       → Ask missing requirements + archetype if unclear
                │       → Produce Implementation Plan
                │
                └── UIHTML or standalone programmatic explicit
                        → Skip Q5 entirely (not applicable)
                        → Ask missing requirements + archetype if unclear
                        → Produce Implementation Plan
```

## Discovery Questions

Ask these conversationally — not as a rigid checklist. Gather requirements and layout intent first; ask the serialization question **last**, once you understand what the app needs to do.

### Core Questions

**1. What does the app do and who is it for?**
> What will this app do? Who will use it?

Listen for archetype signals: "dashboard", "control panel", "step-by-step", "workspace".

**2. Is this a quick tool or something you'll maintain over time?**
> Is this meant to be maintained and evolved, or is it more of a quick, proof-of-concept tool?

- **Maintained** → proceed to remaining questions; team skills matter
- **Ephemeral** → favor UIHTML app path; can skip team question

**3. How polished does the UI need to look?**
> Are standard MATLAB buttons, sliders, tables, and plots enough? Or do you need custom visuals — branded, animated, or visually richer?

- Standard controls sufficient → UIFigure app signal
- Custom visuals needed → UIHTML app signal

**4. Who will work on this app going forward?**
> Will this be maintained by people comfortable only with MATLAB, or by people also comfortable with