Anylogic

Quick Start

Prerequisites:

• A local AnyLogic installation or exported AnyLogic model artifacts
• Read/write access to the target model directory
• Bash access for install discovery and local binary probing
• A backup or VCS checkpoint before changing .alp, .alpx, or related XML files

Tools Used: Read, Write, Edit, Bash, Grep, Glob

Basic Usage:

User: "Add a statechart transition to this AnyLogic agent"
Agent:
1. Detects model format and local install surface
2. Reads the relevant model files before editing
3. Updates statechart or parameter-expression XML surgically
4. Verifies references, expressions, and runnable command surface

What I Do

• Discover local AnyLogic installations and likely executable paths with scripts/discover-anylogic.sh on bash-based environments
• Inspect model layouts and distinguish .alp single-file models from .alpx multi-file models
• Edit parameter defaults and parameter expressions in model files with minimal, targeted changes
• Build or revise statechart structures by updating the model definition files rather than inventing unsupported GUI automation
• Prepare and run documented local-binary workflows for experiment execution and standalone export when the installed edition supports them
• Summarize what the local binary appears to expose versus what still requires manual IDE interaction
• Keep scope explicit when the requested action is not documented or cannot be confirmed from the local installation

When to Use Me

Use this skill when you:

• Create or revise AnyLogic statecharts in existing model files
• Change parameter expressions, defaults, formulas, or experiment inputs
• Probe a local AnyLogic installation to see what binary surfaces are available
• Run or export AnyLogic experiments from the command line
• Inspect .alp or .alpx model structure before making edits
• Need a safe workflow for XML-backed AnyLogic model changes
• Want the agent to avoid overpromising GUI automation that the local install cannot prove

Workflow

Step 1: Discover the local surface first

Run the install-discovery helper before making capability claims. The helper is bash-first, so treat macOS/Linux discovery as primary and Windows path matches as hints unless the user provides a Windows-native command surface.

bash @skills/anylogic/scripts/discover-anylogic.sh

Use the output to answer three questions:

1. Is AnyLogic installed locally?
2. Which executable or app bundle is present?
3. Is there evidence for runnable run/export/help surfaces?

If discovery finds no installation, continue only with file-level model analysis and clearly state that binary-backed actions are unverified.

Step 2: Identify the model format and edit surface

Look for these patterns before editing:

• .alp → single XML model file
• .alpx or split XML files → multi-file model representation that is safer for targeted edits
• experiment-specific files or generated Java/export artifacts

Read the model cluster first. Do not edit blind. Prefer the smallest possible change set that preserves XML structure and existing naming.

Step 3: Handle parameters and expressions surgically

For parameter work:

• Locate the exact parameter node or file section first
• Change only the intended default, expression, or experiment input binding
• Preserve expression syntax, units, and referenced names
• Re-read surrounding XML after edits

Step 4: Handle statecharts as model-definition edits

For statecharts:

• Find the existing statechart container, states, events, and transitions
• Match the surrounding XML/structure pattern already used by the model
• Add or update only the necessary state, transition, trigger, or action block
• Preserve IDs, names, and symbol references consistently

Treat runtime statechart APIs as execution-time helpers, not as a substitute for editing the model definition.

Step 5: Run only documented or locally-proven binary actions

After discovery, use only surfaces that are documented or locally observable. Common safe categories are:

• probe/help output
• experiment run commands
• export/build commands

Do not claim full IDE GUI automation unless the local installation or user-provided tooling proves it.

Capability Boundaries

This skill is intentionally conservative.

In scope:

• installation discovery
• model-file inspection
• statechart and parameter-expression edits in .alp / .alpx structures
• documented run/export flows
• capability summaries tied to the local install
• bash-based install discovery with explicit limits on cross-platform certainty

Out of scope unless proven locally:

• arbitrary GUI automation inside the IDE
• undocumented binary flags
• schema-free bulk rewrites of model XML
• claiming edition-specific features without evidence

Quick Reference

Examples

Example 1: Discover local capability before acting

User: "What can my installed AnyLogic binary do?"
Agent: Runs the discovery script, reports candidate executable paths, notes any observed help output, and separates confirmed capabilities from assumptions.

Result: The user gets a grounded summary of installation paths, likely edition clues, and command-line surfaces without pretending the IDE is scriptable in ways that were not observed.

Example 2: Update a parameter expression

User: "Change the arrival-rate parameter expression to use `baseRate * seasonalMultiplier`"
Agent: Reads the relevant model files, finds the exact parameter definition, edits only the expression-bearing node, and re-reads the surrounding XML.

Result: The expression changes without unrelated XML churn.

Example 3: Extend a statechart

User: "Add a transition from Idle to Busy when queueSize > 0"
Agent: Reads the agent/statechart definition, finds the existing Idle and Busy nodes, inserts the smallest matching transition block, and reports unresolved symbol or ID requirements.

Result: The statechart change is expressed as a model-definition update instead of an invented GUI macro.

Minimal .alp State and Transition Fragments

These fragments show the smallest matching block shape for the two patterns the skill targets. Treat them as illustrative — actual .alp content varies by AnyLogic version, but the structural cues (state container, transition to / trigger / action, ID-style attributes) are stable.

State definition (inside a <Statechart> or <Agent> block):

<State
    name="Idle"
    id="1700000000001">
  <Entry>
    <Code>queueSize = 0;</Code>
  </Entry>
  <Exit>
    <Code>// no-op</Code>
  </Exit>
</State>

Transition definition (sibling to the states it connects):

<Transition
    from="1700000000001"
    to="1700000000002"
    trigger="queueSize &gt; 0">
  <Action>
    <Code>activeAgent = true;</Code>
  </Action>
</Transition>

When patching:

• Preserve the existing id scheme — referenced by from / to.
• Keep name strings identical to what other states/events reference.
• Match the surrounding XML's indentation and attribute ordering.
• For arrow comparisons (>) in triggers, use the XML entity > — raw > breaks parsing.

Common Errors

References

Related Skills

• skill-helper - Validate and improve this skill
• markdown-editor - Edit markdown-based skill documentation
• python-core - Build deeper XML or automation helpers if a future version needs them