ea-com

Logic: AI + AI Power Tools checks. The AI writes the script; EA's automation interface and the repository database carry it out.

What it is for

Use it to reach what no operation covers: a bulk read or an ad hoc report, a scripted change, a check of a technology from outside a session, or saving, refreshing or restarting EA. You end with the result of a Python script the AI writes and runs through EA's automation interface.

ea-com is for automation specialists. It teaches the AI to drive Sparx EA directly from a Python script through EA's COM automation interface instead of through the server. It enables four kinds of work:

• bulk reading and cross-table queries across the repository, and ad hoc reports that do not fit an existing operation,
• creating and updating elements and tagged values in a script,
• checking whether a modeling technology is loaded, enabled and which version, from outside a session,
• controlling EA's lifecycle: save, refresh, restart and reconnect.

It is a skill for scripts. It is not a second way to do routine modeling. If you are an architect and not a scripter, you will not run it yourself. You will recognize the situations where a person who scripts should be brought in.

Capabilities it uses

When to use it, and when not

Bring in someone who scripts when the work is a script that talks to EA directly and outlives the AI session: a repeatable job that runs on a schedule you set up yourself, a one-time bulk change driven from a spreadsheet, a cross-table report no operation produces, or EA lifecycle control the server does not expose.

How it works

The skill is a set of verified patterns, not a single workflow. In use it goes like this. In this skill, Engine marks a step the script carries out, which needs local code execution.

1. Decide that COM is the right tool. AI The AI applies the table above, then proposes the script. You You approve running it, because a script writes to EA with none of the server's protections.
2. Connect. Engine The script attaches to the running EA instance. It does not launch EA and does not open a project. It fails if EA is not running or no project is open, so the skill adds a retry.
3. Read. Engine The script runs queries and fetches live element objects. The skill records two traps here. A query that names a table or column that does not exist raises a blocking dialog in EA, and the call returns only after a person dismisses it, so an unattended script hangs. And a successful query that matches nothing returns an empty list with no error, which can look like "nothing there". Dismissing the dialog is AI with computer use; otherwise you: with computer use the AI reads the dialog, corrects the query from its message and dismisses it. Without computer use, you paste a screenshot of the dialog into the conversation so the AI can analyze it, then you dismiss it.
4. Check technology state. Engine One technology at a time: is it loaded, is it enabled, which version. Calls that change technologies (activate, delete, import) are documented as existing and are treated as deploy operations.
5. Create and update. (AI writes, engine executes) Packages and elements are created through EA's collections. A tagged value is set by updating the existing entry and not by adding a new one, because a stereotype's tags already exist as empty placeholders and adding one makes a duplicate that leaves the placeholder behind and makes "the value" ambiguous.
6. Bulk update. Engine A direct database statement is faster than iterating tags, and it reports nothing on success or failure, so the result must be read back.
7. Read back after every write. (engine, AI) This is the skill's central discipline: a successful call is no proof of persistence, because several calls return nothing at all on success or failure.
8. Lifecycle. Engine Save, refresh, restart. Watching EA through the restart and dismissing any dialog is AI with computer use; otherwise you. After a restart every reference a script held from before is stale, so it reconnects and re-queries. Run the restart sequence on a scratch session first.

Verification discipline. Answer any question about model state from a fresh read in the current turn, never from memory of what a script did earlier. Elements get renamed, moved and deleted, other users and scripts change the model, and EA can roll back a transaction without telling the script. Four habits follow: never assert model state from an earlier turn; persist identifiers and GUIDs and not names; treat a successful change as no proof of persistence; and after an EA restart or project reopen, reconnect and re-query.

Waiting and looking. For any call that can raise a dialog (restart, MDG Technology import, a database statement), the script waits and then the AI looks at EA AI with computer use; otherwise you, following latency.md and ea-ui-verification.md. "(Not Responding)" during a long operation is normal, so the AI waits and checks again and does not retry.

What you get

• A Python script, written to your specification, that reads or changes the repository.
• A read-back that shows what the script actually did, row counts included.
• A plain statement of which guardrails were not in force.

Tools it relies on

• Local code execution: Python 3 with the pywin32 library on the machine where EA runs, and a running EA with a project open. The whole environment is Windows only.
• EA's COM automation interface: everything the skill does.
• Shared references: latency.md, ea-ui-verification.md and westbrook-example.md.
• The skill calls no server operation. It points to ea-modeling for the server route.

A script reaches EA without the connection manager, the SQL guard, the guarded lookups, the structured error replies, the diagnostics recorder or the repository read-only mode (How tools and operations work). Those protections belong to the server and do not apply to a script.

Sample prompts

1. "Write a Python script that lists every WBABusinessApplication in the open model with its criticality tag." Attaches to EA, runs the query, and returns the list. Substitute your own stereotype and tag.
2. "From Python, tell me whether the WBA technology is loaded and enabled, and which version." Runs the three technology checks for one id.
3. "Why does my script hang when it queries a table called stereotypes?" Explains the blocked dialog: EA is waiting for a click, how to find the dialog, and to query the elements table instead.
4. "Set businessOwner on these 40 elements from a CSV, and make sure there are no duplicate tag entries afterwards." Updates the existing entries, then reads back and checks for duplicates.
5. "Write a script that saves, restarts EA, reconnects, and then re-checks that the technology is loaded." The AI tests the restart sequence on a scratch session first, and reconnects and re-queries rather than reuse old objects.

Recommended models

Ratings are guidance based on the kind of reasoning the skill needs, not measured benchmarks. Because a script writes to EA with none of the server's protections, take a baseline first (ea-change-management).

Checking accuracy and completeness

1. Read back every write. After the script runs, query the rows it touched through the script and through execute_sql, and compare with the intended values and row counts. Red flag: a script that reports success from a return value, because several calls return nothing at all.
2. No duplicate tag entries. After a tag update, ask for a query that lists any element carrying the same tag name more than once. Correct: none that is new. Red flag: a new duplicate, which means a tag was added where it should have been updated.
3. Same answer through two routes. Run the same query through the script and through execute_sql. Correct: the rows match. Red flag: a difference, which points to the wrong table or a stale connection.
4. Query method. Review the script: it must use the call that runs a query against the repository, and column names must be checked with describe_table first. Red flag: unvalidated table or column names.
5. Look at EA after the run. Confirm no dialog is left open and EA is responding. Red flag: a script that ran to completion on an unvalidated query may have been waiting on a dialog.
6. Identifiers, not names. Correct: the script persists and compares GUIDs or identifiers. Red flag: lookups by element name, which can collide.
7. Scratch first, then confirm cleanup. Test on a scratch package. Afterward, confirm by query that the package, its elements and their tag entries are gone.

Limitations

• Windows only, and EA must be running with a project open. A script attaches to a running EA and does not start it. The assistant can start EA and open the model first. AI with computer use; otherwise you See Limitations and known issues.
• No server protections apply. A bad database statement is not rejected. Deletes through COM cannot be undone. Back up with a baseline first.
• Technology-changing calls change the live session. A technology removal takes effect only after a restart.
• Verified on EA 17. The traps were found against EA 17 builds. Re-check them on your build.
• A failed write can look like success. EA can accept a call and not persist the change. Read back.
• A script that holds a reference across an EA restart or project reopen is working with a stale object.