Generates draft requirements from Simulink models using Requirements Toolbox (.slreqx) or YAML. Use when drafting or updating requirement artifacts from a model.
How this skill is triggered — by the user, by Claude, or both
Slash command
/model-based-design-core:generate-requirement-draftsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Generate draft requirements from Simulink models using the richest artifact the environment supports. All outputs are **drafts** requiring human review and approval before baselining.
Generate draft requirements from Simulink models using the richest artifact the environment supports. All outputs are drafts requiring human review and approval before baselining.
.slreqx or .yaml requirements artifactstesting-simulink-models skill<Model>_Requirements.slreqx or <model>_requirements.yamlREQ_<SYSTEM>_001, REQ_<SYSTEM>_002, ….slreqx or .yaml files already exist"draft" in Keywords (slreq) or status: Draft + keywords: [draft] (YAML)Requirements must express behavioral intent (WHAT the system shall do), not restate model topology (HOW it is implemented). Put the WHY in Rationale. Use EARS (Easy Approach to Requirements Syntax) patterns:
Choose the pattern that best fits the model behavior:
| Pattern | Template | When to Use |
|---|---|---|
| Ubiquitous | The <system> shall <response>. | Always-on behavior, invariants |
| Event-driven | When <trigger>, the <system> shall <response>. | Triggered subsystems, Stateflow transitions, input events |
| State-driven | While <state>, the <system> shall <response>. | Stateflow states, mode-dependent behavior |
| Unwanted behavior | If <condition>, then the <system> shall <response>. | Error handling, safety limits, saturation |
| Optional feature | Where <feature>, the <system> shall <response>. | Variant subsystems, configurable features |
| Combined | While <state>, when <trigger>, the <system> shall <response>. | State + event combinations |
| ❌ Bad — restates implementation | ✅ Good — EARS pattern |
|---|---|
| "Saturation block limits output to [0,1]" | "If throttle command exceeds ThrottleMax (1.0) or falls below ThrottleMin (0.0), then the controller shall clamp the output to the valid range." |
| "BrakeLogic subsystem disengages controller" | "When brake pedal input exceeds BrakeThreshold (0.0), the controller shall disengage cruise control." |
| "Gain block multiplies by 2.5" | "While cruise control is active, the controller shall amplify speed error by Kp (2.5) to compute proportional correction." |
| "Stateflow chart transitions to Idle" | "When the driver presses the off button, the system shall transition to the Idle state." |
| "Variant subsystem selects Algorithm A" | "Where the adaptive mode is enabled, the controller shall use the predictive algorithm." |
Rationale or provenance notes, not in the requirement SummaryVarName (value). If the model uses a literal with no variable, record the numeric literal directlyRationale, not in the requirement statementChoose once at the start, then stay on that path.
| Situation | Backend |
|---|---|
User explicitly asks for .slreqx, traceability views, or repo already uses .slreqx | Requirements Toolbox — if probe fails, inform the user that Requirements Toolbox is unavailable; do NOT silently fall back |
User explicitly asks for .yaml, or repo already uses .yaml requirements | Structured YAML |
| No format specified — probe for Requirements Toolbox | Requirements Toolbox if probe succeeds |
| No format specified and probe fails | Structured YAML (silent fallback is OK here since user had no preference) |
Probe (run via evaluate_matlab_code):
hasSlreq = ~isempty(which('slreq.new'));
if hasSlreq, try, slreq.find(Type="Link"); catch, hasSlreq = false; end, end
disp(hasSlreq)
Understand the model — use model_overview and model_read to understand subsystems, interfaces, control logic.
Extract parameters — use model_query_params / model_resolve_params for thresholds, gains, sample times that should appear in requirement text. Record both variable names and resolved values.
Build a capture table (backend-neutral):
| Id | ParentId | Summary | Description | SourceBlock | Rationale | ASIL | Priority | Keywords |
|---|
Run the backend path (A or B below).
Review using the gate below.
.slreqx)Use when probe succeeds. For full API patterns see reference/slreq-patterns.md.
model = "CruiseControl";
load_system(model);
rs = slreq.new(model + "_Requirements");
% Add requirements with hierarchy — note behavioral "shall" statements
req = add(rs, Id="REQ_CC_001", ...
Summary="If throttle command exceeds ThrottleMax (1.0) or falls below ThrottleMin (0.0), then the controller shall clamp the output to the valid range.", ...
Description="Derived from CruiseControl/ThrottleCmd.");
req.Rationale = "Prevents invalid actuator commands that could damage the throttle body.";
req.Keywords = ["draft","auto-generated","control","safety"];
child = add(req, Id="REQ_CC_002", ...
Summary="When brake pedal input exceeds BrakeThreshold (0.0), the controller shall disengage cruise control.", ...
Description="Derived from CruiseControl/BrakeLogic.");
child.Keywords = ["draft","auto-generated","safety","brake"];
% Create traceability links: use block handle from SID (blk_X → X) for robustness
lnk = slreq.createLink(Simulink.ID.getHandle(model + ":5"), req);
slreq.createLink(Simulink.ID.getHandle(model + ":8"), child);
save(rs);
% Save all link sets
linkSets = slreq.find(Type="LinkSet");
for i = 1:numel(linkSets), save(linkSets(i)); end
Link rules:
Implementload_system) before creating links with block pathsUse when Requirements Toolbox is unavailable. For schema and field rules see reference/yaml-requirements.md.
<model>_requirements.yaml file from the capture tablestatus: Draft and include draft in keywords for every requirementasil/status/priority use valid values, IDs sequential, derived_from references valid IDs or is nullpython -c "import yaml, sys; yaml.safe_load(open(sys.argv[1])); print('OK')" path/to/requirements.yaml
| Always | Never |
|---|---|
| Mark every generated requirement as DRAFT | Emit markdown or ad hoc text when .slreqx is available and no text format was requested |
| Write requirements using EARS patterns | Restate block topology as the requirement summary |
Include parameter name + value: VarName (value) | Create both .slreqx and .yaml unless user asks for both |
| Link direction: model element → requirement | Reverse the link direction (requirement → block) |
load_system before creating traceability links | Over-link every primitive block — prefer subsystem links |
| Use only R2023a+ APIs | Silently fall back to YAML when user explicitly requested .slreqx |
| Stay consistent with existing repo format | Renumber existing requirement IDs on regeneration |
Before finishing, verify (both backends):
Id, Summary, and Descriptionslreq path only:
YAML path only:
asil and priority use valid enum values (or Unset when unknown)reference/slreq-patterns.md — Requirements Toolbox API cookbookreference/yaml-requirements.md — Structured YAML schema and field rulesreference/examples/slreq_from_model.m — End-to-end slreq examplereference/examples/requirements.yaml — Structured YAML exampleCopyright 2026 The MathWorks, Inc.
npx claudepluginhub matlab/simulink-agentic-toolkit --plugin model-based-design-coreAuthors, updates, and validates atomic functional and non-functional requirements with traceability matrices, validation packs, and explicit human-in-the-loop approvals. Use for creating or reviewing requirements as source of truth.
Drafts single Sphinx-Needs requirement artifacts (req, comp_req, hazard, safety_goal, fsr) from feature descriptions as RST directive blocks with ID and draft status, using project artefact-catalog for type-specific fields.
Authors and validates requirements using EARS patterns (Ubiquitous, State-Driven, Event-Driven, Unwanted, Optional, Complex). Provides templates, examples, decision tree, and syntax checks.