CST Simulation Workflow
Use this skill as the workflow and decision layer. Use the CST MCP as the execution layer.
Prefer the repository CST MCP native tools for live session control. Use the vendored cst_runtime_* or cst_toolbox_* wrappers for larger command catalogs, workspace pipelines, result export, parameter sweeps, and optimization helpers.
Operating Modes
First classify the request:
| Mode |
Use when |
Action |
| Plan only |
User asks for a scheme, script outline, or workflow |
Do not run CST; produce the setup plan and assumptions |
| New project |
User wants a new CST case |
Select a template, resolve inputs, create a run project |
| Existing project |
User provides a .cst path or asks to modify an open project |
Inspect first, then work on a copy unless explicitly told otherwise |
| Parameter sweep |
User asks for ranges, cases, or comparison |
Use sweep preview before running cases |
| Optimization |
User asks to improve S11, gain, bandwidth, coupling, etc. |
Hand off to runtime optimization workflow after confirming objective and bounds |
Standard Workflow
- Detect CST MCP availability and CST Design Environment status.
- Determine whether to create a new project, open a copy of an existing
.cst, or only generate a plan.
- Identify the simulation class and select a template when appropriate.
- Resolve missing inputs using the parameter policy.
- Present a compact defaults card before expensive solves unless the user already said to use defaults or run directly.
- Build or modify geometry, materials, coordinate system, ports/excitations, boundaries, mesh, solver, and monitors.
- Save the working project before running a solver.
- Run the solver only when the user requested execution or accepted the defaults.
- Extract result tree items and export requested data.
- Validate results against the objective and evidence requirements.
- Generate a concise report with assumptions, files, commands/tools used, result paths, and validation status.
- Close/cleanup the CST project/session and report any nonblocking residual locks or access-denied cleanup messages.
Reference Files
Read only the reference file needed for the current task:
references/workflow.md for the end-to-end workflow and mode-specific execution details.references/parameter-policy.md for required questions, defaults, derived values, and existing-project inspection.references/mcp-tool-map.md for this repository's CST MCP tool names and when to prefer native vs runtime tools.references/templates.md for V1 simulation templates and default values.references/result-validation.md for S-parameter, far-field, near-field, eigenmode, sweep, and report validation.references/cst-red-lines.md for correctness and safety rules that must not be violated.
Input Policy
Ask at most one compact clarification when critical information is missing. If the user says "directly run", "use defaults", "先默认", or equivalent, use defaults and record them in the report.
Critical inputs that usually require confirmation:
- simulation case type
- target frequency or frequency band
- new project vs existing project
- primary result objective
- whether to actually run the solver
Defaultable inputs include units, background, common metals, antenna boundaries, solver choice, monitor frequencies, mesh level, and standard result exports. See references/parameter-policy.md.
Execution Rules
- Do not overwrite a user's source
.cst project. Copy it to a run directory unless the user explicitly requests in-place edits.
- Inspect existing projects before changing them.
- Prefer CST Macro Recorder-style VBA history blocks for modeling operations when no higher-level MCP tool exists.
- Save before solving.
- Treat solver success as unverified until result files, result tree entries, or exported data confirm it.
- For long or costly solves, state the assumptions and expected outputs before running.
Result Rules
- Do not treat complex S-parameter values as dB. Convert with
20*log10(abs(S11)).
- Do not report
Abs(E) as gain. Use Realized Gain, Gain, or Directivity for far-field gain claims.
- Keep model-building/session operations separate from result-reading operations when the tool surface exposes separate modes.
- Include exact evidence paths for project files, exports, reports, and logs.
V1 Scope
Focus V1 on:
- a single new standard antenna case, especially a 2.4 GHz Wi-Fi/IoT microstrip patch antenna;
- opening an existing
.cst, inspecting it, changing parameters, and rerunning on a copy;
- S11, VSWR, far-field gain/directivity, radiation pattern, eigenmode frequency, and concise Markdown report outputs;
- parameter sweep preview/run through the CST MCP sweep tools.
Use 77 GHz 1x4 radar patch array as a demonstration template after the basic workflow is stable.
1---2name: cst-simulation-workflow3description: CST Simulation Workflow4---56# CST Simulation Workflow78Use this skill as the workflow and decision layer. Use the CST MCP as the execution layer.910Prefer the repository CST MCP native tools for live session control. Use the vendored `cst_runtime_*` or `cst_toolbox_*` wrappers for larger command catalogs, workspace pipelines, result export, parameter sweeps, and optimization helpers.1112## Operating Modes1314First classify the request:1516| Mode | Use when | Action |17| --- | --- | --- |18| Plan only | User asks for a scheme, script outline, or workflow | Do not run CST; produce the setup plan and assumptions |19| New project | User wants a new CST case | Select a template, resolve inputs, create a run project |20| Existing project | User provides a `.cst` path or asks to modify an open project | Inspect first, then work on a copy unless explicitly told otherwise |21| Parameter sweep | User asks for ranges, cases, or comparison | Use sweep preview before running cases |22| Optimization | User asks to improve S11, gain, bandwidth, coupling, etc. | Hand off to runtime optimization workflow after confirming objective and bounds |2324## Standard Workflow25261. Detect CST MCP availability and CST Design Environment status.272. Determine whether to create a new project, open a copy of an existing `.cst`, or only generate a plan.283. Identify the simulation class and select a template when appropriate.294. Resolve missing inputs using the parameter policy.305. Present a compact defaults card before expensive solves unless the user already said to use defaults or run directly.316. Build or modify geometry, materials, coordinate system, ports/excitations, boundaries, mesh, solver, and monitors.327. Save the working project before running a solver.338. Run the solver only when the user requested execution or accepted the defaults.349. Extract result tree items and export requested data.3510. Validate results against the objective and evidence requirements.3611. Generate a concise report with assumptions, files, commands/tools used, result paths, and validation status.3712. Close/cleanup the CST project/session and report any nonblocking residual locks or access-denied cleanup messages.3839## Reference Files4041Read only the reference file needed for the current task:4243- `references/workflow.md` for the end-to-end workflow and mode-specific execution details.44- `references/parameter-policy.md` for required questions, defaults, derived values, and existing-project inspection.45- `references/mcp-tool-map.md` for this repository's CST MCP tool names and when to prefer native vs runtime tools.46- `references/templates.md` for V1 simulation templates and default values.47- `references/result-validation.md` for S-parameter, far-field, near-field, eigenmode, sweep, and report validation.48- `references/cst-red-lines.md` for correctness and safety rules that must not be violated.4950## Input Policy5152Ask at most one compact clarification when critical information is missing. If the user says "directly run", "use defaults", "先默认", or equivalent, use defaults and record them in the report.5354Critical inputs that usually require confirmation:5556- simulation case type57- target frequency or frequency band58- new project vs existing project59- primary result objective60- whether to actually run the solver6162Defaultable inputs include units, background, common metals, antenna boundaries, solver choice, monitor frequencies, mesh level, and standard result exports. See `references/parameter-policy.md`.6364## Execution Rules6566- Do not overwrite a user's source `.cst` project. Copy it to a run directory unless the user explicitly requests in-place edits.67- Inspect existing projects before changing them.68- Prefer CST Macro Recorder-style VBA history blocks for modeling operations when no higher-level MCP tool exists.69- Save before solving.70- Treat solver success as unverified until result files, result tree entries, or exported data confirm it.71- For long or costly solves, state the assumptions and expected outputs before running.7273## Result Rules7475- Do not treat complex S-parameter values as dB. Convert with `20*log10(abs(S11))`.76- Do not report `Abs(E)` as gain. Use `Realized Gain`, `Gain`, or `Directivity` for far-field gain claims.77- Keep model-building/session operations separate from result-reading operations when the tool surface exposes separate modes.78- Include exact evidence paths for project files, exports, reports, and logs.7980## V1 Scope8182Focus V1 on:8384- a single new standard antenna case, especially a 2.4 GHz Wi-Fi/IoT microstrip patch antenna;85- opening an existing `.cst`, inspecting it, changing parameters, and rerunning on a copy;86- S11, VSWR, far-field gain/directivity, radiation pattern, eigenmode frequency, and concise Markdown report outputs;87- parameter sweep preview/run through the CST MCP sweep tools.8889Use 77 GHz 1x4 radar patch array as a demonstration template after the basic workflow is stable.
cai-aa