ea-change-management

Logic: AI + AI Power Tools checks. Mostly deterministic operations; the AI judges scope and when to offer a baseline.

What it is for

Use it to make a bulk or destructive change reversible, see exactly what a change did, and answer who changed what, and when. You end with a baseline taken before the change, and a comparison afterward that lists what was added, removed and changed.

ea-change-management governs EA's own baseline mechanism and the repository's change history. A baseline is a snapshot of one package's subtree, stored inside the repository. The skill teaches when to take one (and of what), how to read a comparison against it, why restoring from one is the most destructive operation in the set and how to protect against that, when the AI should offer a baseline before a risky change, how to review and prune the baselines that accumulate, and how to answer "what changed, when, and by whom" from the audit trail.

It is the safety net for the rest of AI Power Tools. Deletes through COM cannot be undone, so the skills that delete, bulk-edit, import or roll out a technology point here first.

Capabilities it uses

When to use it, and when not

Use it before a bulk edit, an XMI import, a package delete, a ruleset-driven fix or an MDG rollout that you might need to undo. Use it to find what changed in a package or the repository over a time window and who changed it, to compare the current state with a known-good snapshot, to roll a package back, and to review or prune old baselines.

The AI runs the ea-start-here session preflight first. A baseline captured against, or applied to, the wrong model is a wasted afternoon at best.

How it works

1. Decide the baseline scope. AI A baseline always covers the whole subtree under the package given. There is no partial-subtree baseline. The AI picks the narrowest package that contains the change being protected against, and reserves whole-model baselines for whole-model operations.
2. Create the baseline. AI Power Tools create_baseline with a package, a version label and notes.
3. Confirm it. AI Power Tools list_baselines for the package.
4. Make the change. (another skill, or you)
5. Compare. (AI Power Tools for the comparison, AI for reading it) compare_baseline, which is read-only.
6. Keep or revert. (AI recommends, you decide) Reverting is apply_baseline, behind the precautions below.
7. Answer "what changed and who changed it". (AI Power Tools reads, AI synthesizes) get_updates_in_range and get_user_activity.
8. Offer a baseline before a significant change. (AI, you) See "Offer once, honor a no".
9. Review and clean up accumulated baselines. (AI + AI Power Tools, you) List with sizes, name exactly what would go, delete only on your explicit yes, verify by re-listing.

Baseline strategy.

A package-level comparison against a 20-element package is something a person can read. A comparison against the whole model is not. Every baseline adds a compressed copy to the repository, so baselining large subtrees often grows it. The AI checks the cost with a size query before making it a habit. A local .qea file is a SQLite database underneath, so a query against one must use a function SQLite has; a server connection uses the database's own functions. A query EA's backend cannot run raises a blocking dialog in EA.

create_baseline returns the baseline's GUID, the package's GUID, the version, the notes, a creation time and a status of created. It reports create_baseline_failed when EA reports failure and a structured package_not_found for an unknown package. Keep the baseline GUID. The version string is yours to choose, and a dated, purposeful name (2026-09-24-pre-lifecycle-update) is what makes the cleanup pass later possible.

list_baselines returns each baseline's GUID, version, notes, date, author and name for one package. In some EA builds the date and author come back empty, so do not build logic on them. For authoritative baseline metadata the AI queries the repository directly.

Reading a compare_baseline result. compare_baseline is read-only. It does not touch model content, so it is safe to run at any time, including against a package you do not own, to answer "has anything changed since this snapshot". It also opens EA's comparison view.

The result gives the baseline's own details; the current scope (live element, attribute and connector counts for the package subtree as it stands now); the size of the snapshot (a size proxy and not a comparison); whether a structured comparison was available; and the comparison itself: whether there are changes, a count of items by status, the items, and the packages compared. Each item and each of its properties carries one of four statuses, which are EA's own buckets:

A changed item lists each property with the model value and the baseline value side by side, so a criticality flip from Business-Critical to Standard is told apart from a typo fix in notes by reading the two values, and not just that the element changed. A property absent from one side is shown as none there. Identical items are counted but withheld from the item list by default, because they are the bulk of a real result. Ask for them to get the whole document. The total item count always reflects the unfiltered total, so it can exceed the number of items listed. EA omits unchanged child elements from the comparison, so "Identical" covers the compared package's own item and the unchanged properties of items that did change. A comparison that cannot run returns compare_failed.

The two GUID forms in the result are not interchangeable. Items carry the braced form ({C0CA1B4C-...}) that element lookups take. The compared-package entries carry EA's underscore form. Passing one where the other is expected matches nothing and reports no error.

If compare_baseline appears to hang, the AI looks at EA's screen. AI with computer use; otherwise you With computer use the AI reads the dialog, uses its message to correct the call 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 so processing can continue. EA reports an unrunnable query as a modal dialog that holds the connection until someone clicks OK, so every later call also appears to hang. See Shared references.

apply_baseline is destructive. It overwrites the current content of the package with the baseline's snapshot. The response always carries a warning to that effect. Every element, connector, diagram and tagged-value change in that package since the baseline was taken is discarded, including other people's work. It is not a merge and not a selective revert. It replaces the subtree wholesale.

The AI never calls it against a package it did not baseline for this purpose. On a shared repository a package-level apply can silently erase a colleague's concurrent edits, with no separate confirmation step. Before the call:

1. Take a fresh baseline of the current state first, even when sure about the revert. It is the undo for the undo.
2. Re-confirm the package and the baseline with list_baselines and get_repository_info immediately before the call. Applying the right snapshot to the wrong package, or the reverse, is the expensive mistake.
3. Coordinate with anyone else working in that package. Reads are safe anytime. This write is not.
4. After the call, verify explicitly. Query the package's contents (execute_sql or list_elements_in_package) and do not trust the response alone, in either direction.

How the operation behaves: it first runs a comparison. If EA cannot return one it reports compare_unavailable. If the package already matches the baseline it reports already_matches_baseline and does nothing. Otherwise it restores with a full-restore merge instruction, then compares again and reports success only when EA confirms no differences remain: a status of applied, with restored true. If differences remain it reports baseline_restore_not_applied and says nothing was changed, and its message points to the manual route in EA's interface (right-click the package, Package Control, Baselines, select the baseline, Restore). Taking that route is AI with computer use; otherwise you and needs the same precautions. Treat baseline_restore_not_applied as "nothing changed", not a partial success. A merge that raises reports apply_failed, and a comparison that raises reports compare_failed. Each carries the warning. Because the operation restores for real and verifies, it is also more dangerous than a simple snapshot.

Audit trail: what changed, when, by whom. Two read-only, repository-wide operations answer complementary questions.

get_updates_in_range returns one row per changed item: its kind, identifier, name, type, package and modification time. kind accepts elements (the default, which includes packages alongside ordinary elements), packages, diagrams and all. Connector-level history is not tracked, so connectors is not a valid kind. The operation shows that something changed and when, not what changed about it. For field-level differences, compare against a baseline or read the element.

get_user_activity returns one row per author: how many elements and diagrams they modified and when they were last active. The author is the EA or Windows login recorded on the item as the last editor, not a chosen display name. Present the counts as the authors of the items modified in the window. Fine to read inside your own repository for audit, but do not copy it verbatim into shared tickets, documentation or examples.

Neither operation takes a package. Both are repository-wide. For a package-scoped question, filter the rows by package afterward, or ask for a query on that package. The two combine: get_user_activity says whom to ask about a window of change, get_updates_in_range says what they touched, and compare_baseline against a snapshot from before that window says exactly what changed on each item.

Dates can be given as YYYY-MM-DD, YYYY-MM-DD HH:MM:SS, or ISO-8601 with a T separator and a Z or offset suffix. They are normalized to the form EA stores, and a bare end date covers the whole day. An unparseable date returns invalid_date_range.

Offer once, honor a no. A baseline is a rollback point only if it is taken before the change. No operation asks the user anything, so offering is a conversational decision the AI makes. It follows the same ask-once pattern as ea-navigation-diagrams. Offering on every write is worse than offering on none, because it bloats the repository and trains people to click through.

The line of 25 elements is a stated judgment: below it, a mistake can be hand-fixed by re-running a few calls, above it reconstruction is real work. A deployment can adjust it and should state the number it uses.

How the offer works:

• The AI asks before the triggering call, stating the operation, its scope, roughly how many elements it affects, and which package or the model root would be baselined. You
• Accepting creates the baseline (the package being changed, or the model root for a repository-wide operation), confirms it with list_baselines, then proceeds.
• Declining is remembered for the rest of the session, per trigger category. A "no" to one delete_package stops further delete_package offers, but a separate bulk edit or ruleset fix still gets its own first ask. A standing preference ("stop offering to baseline") covers every category for the session. A new session starts clean.
• Two options every time: yes, baseline first, or no, proceed without one.
• delete_package reports nothing about what it removed, so the AI pulls the count first with list_package_tree and element counts. That also makes the offer concrete: "About to delete the Legacy Integrations package (14 elements, 3 diagrams). Want me to baseline it first?"

Reviewing and cleaning up baselines. Baselines accumulate, and nothing prunes them. The AI helps you see what is there and remove what is no longer needed.

1. List, with the cost. AI Power Tools list_baselines takes a single package and not a repository-wide sweep. To review a whole model, the AI collects packages with list_root_packages and list_package_tree, then calls list_baselines once per package. Payload size is the number that answers "which can I delete", so the AI adds it with a direct query. It joins the two result sets, converts bytes to KB or MB, and presents one table sorted by size, with version, notes and size.
2. Ask, naming exactly what goes. (AI, you) Version, notes and size, not just a GUID. You can confirm several at once ("delete the three oldest"), but only after seeing all three named individually. The AI never deletes more than what was shown and agreed, and never defaults to "clean up everything older than X" without that per-item listing.
3. Delete only what was confirmed. AI Power Tools A baseline is removed with a direct database delete. That is a write with no undo of its own.
4. Verify by re-listing. AI Power Tools Re-run list_baselines and confirm the deleted entries are gone. A reported write means the statement ran, not that the row removed was the row intended.

What you get

• A baseline you can find again: a dated, purposeful version label and a confirmed entry.
• A readable comparison: items added, deleted and changed, with old and new values side by side.
• A guarded rollback, with a fresh safety baseline taken first and the result read back.
• An answer to "what changed, when, and by whom", and an offer of a baseline before significant changes.
• A reviewed list of baselines with sizes, and removal of only the ones you confirmed.

Tools it relies on

• create_baseline, list_baselines, compare_baseline, apply_baseline (Baselines): snapshot, list, compare, restore. create_baseline and apply_baseline write.
• get_repository_info (Project): confirm the right repository before a baseline or an apply.
• import_xmi (Import and export), install_mdg (Managing technologies) and audit (ea_validate): the operations whose use triggers an offer. This skill's own steps do not call them.
• get_updates_in_range and get_user_activity (Audit trail): repository-wide change history by time window and by author.
• execute_sql (Direct queries): baseline size, baseline deletion, package-scoped filtering.
• list_package_tree, list_root_packages, list_elements_in_package, delete_package (Packages, Elements): scope sizing before the offer, whole-model review, post-apply verification.
• Shared references: EA UI verification and latency (ea-ui-verification.md, latency.md).

Sample prompts

1. "Take a baseline of the Westbrook Consumer Banking package called pre-restructure, with a note that it's before we split the vendor-system subtree." Creates the baseline, then lists to confirm.
2. "What changed in Consumer Banking since that baseline?" Compares, then summarizes added, deleted and changed items with old and new values.
3. "I'm about to retag 38 elements' lifecycle in Consumer Banking. Anything I should do first?" Offers a baseline because the count is above 25, naming the scope, and creates it on yes.
4. "Who was editing the model on 23 September, and what did they touch?" Reads user activity and updates for that day, filtered to a package if asked, with a reminder not to paste raw logins into shared documents.
5. "Roll Consumer Banking back to the pre-restructure baseline." Takes a fresh baseline of the current state first, re-confirms package and baseline, asks about concurrent editors, applies, then reads the package back.
6. "How much space are our baselines taking, and what can we delete?" Lists baselines per package with sizes, proposes the largest stale ones by name, deletes only the ones you confirm, and re-lists.

Recommended models

Ratings are guidance based on the kind of reasoning the skill needs, not measured benchmarks.

Checking accuracy and completeness

1. The baseline exists and is the right one. After create_baseline, list_baselines for the same package shows the new version and notes, and the GUID from the create matches a listed entry. Complete: ask for a direct size query of the stored baselines as a cross-check.
2. The comparison matches a known change. Make a controlled change (add one element, edit one tag), compare, and confirm one "Model only" and one "Changed" item, and that the changed property lists the old and new values. Red flag: no structured comparison available, or a parse error.
3. Scope check. The current element counts in the result match list_elements_in_package (recursive) for the same package. Red flag: a mismatch, which means the comparison targeted something other than intended.
4. Restore fidelity. After apply_baseline, the response says restored, and independently a second compare_baseline reports no changes, element counts equal the baseline's counts, and a name-level query matches. baseline_restore_not_applied and already_matches_baseline are reported as such.
5. A safety baseline was taken first. Before every apply_baseline, the transcript shows a create_baseline of the current state and a list_baselines re-confirmation. Red flag: an apply with neither.
6. Offers follow the table. Over a session, every delete_package, import_xmi and MDG rollout was preceded by an offer, no offer was made for a small single-element edit, and a declined category was not asked again.
7. Audit queries agree with a count. get_updates_in_range for a window matches a count of the items modified in that window (plus packages). Red flag: a zero result for a window you know had changes, which is a reason to check the date format.
8. Cleanup was per item. Each deleted baseline was named with version, notes and size, and confirmed, and list_baselines afterward lacks exactly those entries.

Limitations

• apply_baseline discards later work wholesale, including other people's. It is not a merge and not selective, and an undo exists only if a fresh baseline was taken first.
• The server cannot enforce the precautions. Baselining first, confirming identifiers and coordinating with colleagues are habits the AI follows. A caller that skips them is not stopped.
• list_baselines date and author can be empty in some EA builds. Use a direct query for authoritative metadata.
• get_updates_in_range and get_user_activity are repository-wide and take no package filter. Connector history is not supported, and neither operation reports field-level changes.
• Baseline size and baseline deletion use a direct database statement. Deletion is a raw write with no undo, and EA's open session can go stale after it.
• list_baselines takes one package. Reviewing a whole model means one call per package.
• Baselines grow the repository. The cost is per snapshot and per subtree.
• A hang is usually a modal dialog, not a slow operation. EA raises one for any query its backend cannot run, and it holds the connection until dismissed. Look at the screen before retrying. With computer use the AI reads the dialog, corrects the call and dismisses it. Without it, you take a screenshot of the dialog and paste it into the conversation so the AI can analyze it, then you dismiss the dialog so processing can continue.
• The two GUID forms in a comparison are not interchangeable, and a mismatch fails silently.
• Baselines are not version control. They live inside the repository and travel and fail with it. They do not replace backups.
• Author values are personal identifiers. Treat the user activity output accordingly.
• Windows only, with EA running. The server attaches to a running EA. Starting EA and opening the model is a separate step (ea-start-here).