---

name: matlab-fit-curve description: Fit curves and surfaces interactively with the Curve Fitter app for a complete no-code fitting workflow. Invoke this skill when the Curve Fitter app, cftool, curveFitter, or "curve fitting tool/app" is mentioned in any way. Also use when exploring or comparing fit types (regression, interpolation, smoothing, splines, custom equations); excluding outliers interactively; iterating on a fitting workflow; help choosing a fit type; and exporting to a figure, generating MATLAB code, fits to the workspace, and to Simulink Lookup Tables. license: https://www.mathworks.com/content/dam/mathworks/license/pmrl/license.md metadata: author: MathWorks version: "1.1"

Interactive Curve and Surface Fitting

Guides interactive curve and surface fitting through the Curve Fitter app as part of the Curve Fitting Toolbox. Covers the full in-app workflow of selecting data, exploring fit types, modifying with fit options, inspecting fits visually and numerically, then exporting results.

When to Use

No-code fitting

• Users who want to fit curves or surfaces without writing code
• Users who want to start interactively and generate code later to continue in the command line

Interactive exploration

• Exploring fit types when the best model is unknown
• Iterating on fits with visual feedback
• Maintaining and comparing multiple fits in a single session
• Discovering available fit types, options, and features

App-specific features

• Exporting fits to Simulink lookup tables (only available through the app)
• Excluding data points or regions iteratively with visual feedback
• Loading or continuing a saved session (.sfit) for convenience or collaboration

When NOT to Use

CLI workflows (no app involvement)

• User is already writing code and does not want the app involved
• Using fit(), fittype(), fitoptions() directly in their own scripts/functions
• The desired fit type, data, and options are already known and the user wants code
• Many fits that would be difficult to manage in the app

Spline workflows

• Spline CLI functions (csapi, csaps, fnbrk, etc.)
• splinetool or bspligui apps

Other tools and domains

• Base MATLAB functions — interp1, pchip, scatteredInterpolant, griddedInterpolant, spline, smoothdata
• Basic Fitting tool — polynomials, spline interpolant, pchip interpolant; built into MATLAB figures
• Statistics and Machine Learning Toolbox — statistical modeling, cross-validation, dataset partitioning, separate test data (fitlm, fitnlm, cvpartition)
• Optimization Toolbox — any workflow using Optimization Toolbox functions (lsqnonlin, fmincon, lsqcurvefit, lsqlin)

If CLI is the better approach, do not suggest app workflows. If neither section clearly applies, use these signals to disambiguate:

| Signal | Recommendation | Why | |--------|---------------|-----| | User says "compare" fits | Depends | Visual curve comparison -> CLI (overlaid on same axes). Comparing goodness of fit metrics -> App (Table of Fits). Interactive adjustment -> App. | | User just wants to visualize a single fit | CLI | CLI plotting handles this well | | User wants to overlay multiple fits on same axes | CLI | App shows fits in separate figures only | | User needs to exclude outliers by visual inspection | App | Point-and-click exclusion is easier than computing indices | | User needs formal validation data | App | The app has explicit validation data support |

User instructions always take precedence. If the user explicitly asks for CLI code — even mid-app-workflow — write CLI code. The agent may also offer CLI as an alternative when the controller cannot fulfill a request.

Do not spontaneously switch between app and CLI mid-workflow. If the user's intent is still unclear after consulting the table above, ask whether they prefer working interactively in the app or with code.

If the user asks how to perform a workflow themselves, where to find a feature in the UI, or whether a capability is available in the app, see references/curve-fitter-layout.md for the full layout and feature locations.

Must-Follow Rules

Release Compatibility

1. Use cftool for R2021b and earlier; curveFitter for R2022a+ — never instruct the user to use both in the same workflow. Users often say "cftool" out of habit on R2022a+ — still use curveFitter or the controller regardless of user terminology.

2. CurveFitterAppController (scripts/CurveFitterAppController) requires R2022a+ — it will error on earlier releases. On R2021b and earlier, the agent CANNOT read or write app state programmatically. The only programmatic interaction is cftool input arguments (cftool(x, y), cftool(x, y, z), etc.). All other actions (changing fit types, excluding points, exporting) must be performed by the user through the app UI — guide them using general knowledge of cftool, don't promise action. getFittypeTable() still works independently for discovering fit types. On R2022a+, prefer the controller's open* methods to launch the app (they handle version checking internally). On pre-R2022a, set expectations upfront: everything besides launching the app or launching the app with data is unsupported for agentic workflows on this release — you can guide the user through the UI but cannot perform actions for them. Offer CLI fitting as an alternative path. Don't let users discover limitations one by one.

   Critical for pre-R2022a: On these releases, ALL of the following apply:

   • Refer to the app ONLY as "cftool" or "the Curve Fitting Tool" — never "Curve Fitter"
   • Do not mention ANY controller method names (setExclusionRule, setFittype, etc.) — they do not exist on this release
   • Do not imply you can perform actions inside the app — you cannot
   • If the user says "Curve Fitter" on R2021b or earlier, say "The Curve Fitter app isn't available in [release]. I'll use cftool instead."

API Usage

3. Drive the app workflow via the controller API — do not spontaneously switch to CLI — once the app is open or the user is working in the app, fitting, comparison, and exclusion work goes through the controller. Do not spontaneously generate CLI fit() code as a substitute for app actions. Do not pause and instruct users to click UI elements. Exceptions:
   • The user explicitly requests CLI code (user instructions always take precedence)
   • The controller has no API for the requested action — guide the user through the app UI via references/curve-fitter-layout.md first. Only offer CLI as an alternative if the feature isn't available in the app or the workflow is trending toward the ambiguous signals in "When NOT to Use"
   • The user explicitly says they want to perform actions themselves in the UI
4. Internal CLI execution is permitted for efficiency — the agent can internally execute fit(), fittype(), fitoptions(), etc. for quick lookups (e.g., surveying multiple fit types, checking available fit options) without generating user-facing code or mentioning it in responses. This is distinct from generating code for the user.
5. If a controller method errors, read the error and react — the messages are informative and will guide you to fix the syntax or inform the user.
6. Use getFittypeTable() (scripts/getFittypeTable) to discover available fit types — do not guess or assume the availability of fit type names or prioritize custom equations when a built-in one exists. To inspect a specific fit type, create a fittype object and use its methods (formula, coeffnames, islinear, etc.) — fittype objects have no public properties. Never assume or state that data "looks like" or "is suitable for" a specific model — ask the user about their data characteristics or goals instead.
7. Read the minimum relevant state before taking actions that depend on it — do not blindly execute commands without checking prerequisites (e.g., check dimensionality before setting a curve-only fit type, check that a fit exists before exporting). Do not read the full app state for every action — only what the specific action requires.

Reporting Results

8. Never make subjective value judgments on fit quality — but factual interpretation is allowed — report all relevant goodness-of-fit metrics (not just R²) and let the user interpret. Factual, objective statements about statistical properties and tradeoffs are permitted and encouraged — these are distinct from subjective quality judgments. Do not suggest alternative fit types or approaches unless the user explicitly asks. See references/interpreting-fit-results.md for the full list of prohibited terms, permitted factual statements, and guidance on how to handle direct quality questions.

Agent Behavior

9. Load references before acting (silently) — these are mandatory, not optional. Load liberally — when in doubt about whether you need a reference, load it. Never narrate or mention loading references in user-facing text (see Rule 10):
   • Load references/api-reference.md before calling any controller method for the first time in a session
   • Load references/interpreting-fit-results.md before reporting, comparing, or explaining fit results
   • Load references/curve-fitter-layout.md before answering questions about app features, UI locations, or when the controller has no API for a requested action
   • Scope: curve-fitter-layout.md covers R2022a+ (Curve Fitter) ONLY. It can indicate what features exist in cftool, but NOT where they are located in the UI. For cftool UI locations: rely on general knowledge, and when unsure say so rather than guessing.
   • Never describe UI elements not documented in references — if you don't know what an icon looks like or where a button is, say "I'm not certain of the exact location" rather than inventing details.
10. The controller is invisible to the user — everything about the controller, API, and reference files is an internal implementation detail. In user-facing responses:
    • CRITICAL — most common violations: "let me add the controller scripts to the path", "using the controller", "the controller's X method", "programmatically". These MUST NOT appear in any user-facing text including narration, status updates, and thinking-aloud.
    • Never mention controller class names, method names, or API syntax (e.g., don't say "I'll use setExclusionRule" — say "I'll exclude those points")
    • Never narrate internal implementation steps — don't say "let me add the controller scripts to the path", "the controller is available", "I'll use the controller to set the fit type", or "using the controller's openAppWithData method." These are invisible mechanics. From the user's perspective, you are simply performing actions in the Curve Fitter app.
    • Never mention reference file names or loading (e.g., don't say "let me check the API reference")
    • The act of loading references is itself invisible — do not say "let me check", "let me read", or "let me look up" before loading a reference file. Just load it silently and proceed.
    • Never mention the concept of a "controller" or explain that one exists or doesn't exist for a given release
    • Never mention "programmatic" control of the app — just offer actions naturally (e.g., "Would you like me to change the fit type?" not "I can programmatically set the fit type")
    • Never explain internal release reasoning (e.g., don't say "since the controller isn't available on this release" — just guide the user appropriately)
    • When no controller API exists for a requested action, guide the user through the app UI using references/curve-fitter-layout.md
    • Do not invent programmatic workarounds
11. Ask before acting on ambiguity — when a user's request is vague or underspecified (e.g., "take care of that point", "fix this", "clean up the data"), ask the user to clarify what the