Generate Requirement Drafts

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

- Stable IDs: `REQ_<SYSTEM>_001`, `REQ_<SYSTEM>_002`, ... — use **one** consistent project-wide prefix with sequential integers across all requirements, even when they derive from different subsystems

License.p

Audit 0.4.1 · source sha 9090332613b6 · 14 Oct 2026Report an issue or request a re-scan

• Publishermatlab GitHub organizationOwner of the repository this skill is read from
• Source foldermatlab/simulink-agentic-toolkit/skills-catalog/model-based-design-core/generate-requirement-draftsThe exact folder we audited
• LicenceNOASSERTIONAs the repository states it
• Commit pinned for this verdict9090332613b6A new audit runs when the source changes
• Repository statusNot archivedLast push 6 days ago
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its description: Generates draft requirements from Simulink models. Use when drafting or updating requirement artifacts from a model. Prefers Requirements Toolbox (.slreqx) when available; falls back to structured YAML.

---
name: generate-requirement-drafts
description: "Generates draft requirements from Simulink models. Use when drafting or updating requirement artifacts from a model. Prefers Requirements Toolbox (.slreqx) when available; falls back to structured YAML."
license: https://www.mathworks.com/content/dam/mathworks/license/pmrl/license.md
metadata:
  author: MathWorks
  version: "2.3"
---

# Generate Requirement Drafts

Generate draft requirements from Simulink models using the richest artifact the environment supports. All outputs are **drafts** requiring human review and approval before baselining.

## When to Use
- Drafting or updating requirements from a Simulink model
- Creating `.slreqx` or `.yaml` requirements artifacts
- Establishing model-to-requirement traceability

## When NOT to Use
- Importing requirements from an existing source of truth (ReqIF, DOORS, Word, Excel) — use Requirements Toolbox import APIs directly
- Writing or running tests — use the `testing-simulink-models` skill
- Free-form prose notes with no saved artifact
- User explicitly wants a different text format (markdown, Word)

## Output Conventions
- Default file names: `<Model>_Requirements.slreqx` or `<model>_requirements.yaml`
- Stable IDs: `REQ_<SYSTEM>_001`, `REQ_<SYSTEM>_002`, ... — use **one** consistent project-wide prefix with sequential integers across all requirements, even when they derive from different subsystems. Do not switch to per-subsystem prefixes or hierarchical decimal numbering (e.g. `CB-1.1`, `TP-1.1`).
- Follow repo conventions if `.slreqx` or `.yaml` files already exist
- When updating an existing artifact, preserve existing IDs — append new IDs, never renumber
- Every generated requirement must be marked as draft — use `"draft"` in Keywords (slreq) or `status: Draft` + `keywords: [draft]` (YAML)

## Writing Good Requirements

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:

### EARS 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\>. | A momentary trigger causes a one-time response: input events, **entering** a Stateflow state (the transition itself) |
| **State-driven** | While \<state\>, the \<system\> shall \<response\>. | Behavior that holds continuously **while in** a Stateflow state or mode — the ongoing response, not the entry transition |
| **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 |

### Examples — Model Concepts to EARS Requirements

| ❌ 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." |
| "Defrost state runs the heater at full power" | "While in the Defrost state, the system shall drive the heater at full power." |
| "Variant subsystem selects Algorithm A" | "Where the adaptive mode is enabled, the controller shall use the predictive algorithm." |

### Rules

- Write requirements using **EARS patterns** — pick the pattern that matches the model behavior
- Use block/subsystem names (e.g. `Saturation`, `BrakeLogic`) only in `Rationale`, `Description`, or provenance notes — **never** in the requirement `Summary`. (A workspace *parameter* rendered as `VarName (value)` is required in the Summary and is not a block name.)
- When referencing a numeric value, include the **workspace variable name and resolved value**: `VarName (value)`. If the model uses a literal with no variable, record the numeric literal directly
- Put the **WHY** in `Rationale`, not in the requirement statement
- One subsystem may support zero, one, or several behavioral requirements — don't force a 1:1 mapping
- For a Stateflow state or mode, separate **entering** it from **being in** it: the entry transition is event-driven (`When <trigger>, ... shall transition to <state>`), but the behavior that holds throughout the mode is state-driven (`While <state>, ... shall <response>`). When asked for a mode's behavior, prefer the `While <state>` form — do not fold it into a `When` entry statement

## Backend Decision Gate

Choose 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`):
```matlab
hasSlreq = ~isempty(which('slreq.

Excerpt, first 6,000 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

git clone https://github.com/matlab/simulink-agentic-toolkit
git -C simulink-agentic-toolkit checkout 9090332613b6

Works in

1. 2026-10-14
   !CAUTION B 89 / 100

   first audit · source 9090332613b6

Questions about Generate Requirement Drafts

• github.com/matlab/simulink-agentic-toolkit/tree/main/skills-cata — the audited source at commit 9090332613b6 and every finding aboveObserved · 14 Oct 2026

Spotted something wrong? Report a correction · Methodology