By Jerry Combs
If you've ever asked an AI assistant to help you document or untangle an Identity Manager driver, you know how the first ten minutes of every conversation go. You paste in a file, the model asks what .Driver_ means. You explain. You paste another file, it asks what Model/EdirOrphan/ is doing in a project that clearly has an eDirectory tree. You explain. Half an hour in, you've rebuilt, from scratch, the same introduction to the Designer object model you've given in the last five sessions — and you still haven't gotten to the actual question.
I got tired of that, so I built a Claude skill that does the explaining once, and I've published it on GitHub as an installable plugin: dirxml-designer-workspace.
A Claude skill is a small bundle of Markdown — a SKILL.md plus a set of reference files — that Claude loads on demand when a conversation looks like it matches. In this case, the skill tells Claude everything it needs to know to move around a Designer workspace on disk: the directory layout, what every .Type_ extension is, how metadata and _contents.xml files pair up, the DirXML Script grammar (conditions, actions, tokens), the XSLT conventions, filter and mapping structures, the User Application / RBPM layout, where GCVs and ECVs live, how packages work. Content-wise it's maybe 6,000 words across six files — not a book, not a cheat sheet, more like the onboarding document a senior IDM consultant would hand a sharp new hire. Except the "new hire" is Claude, and the onboarding happens in the first token of every conversation that mentions a .Driver_ file.
The practical effect: I can point Claude at a Designer workspace and immediately ask things like "summarize what the CyberArk driver does," "what's bound to the Subscriber's Command Transform, in order?", "which entitlements does the AD driver expose, and are they static or dynamic?" and get a useful answer on the first try, without any setup prose.
Saving ten minutes of onboarding prose per session is nice. The genuinely powerful thing is what it unlocks once Claude understands the model: meaningful comparison of two driver versions, or two whole projects, that a text diff cannot do.
Every IDM consultant reading this has done the ritual of comparing a non-prod workspace to prod before a promotion. You export both, open a diff tool, and watch it drown you in noise: object IDs renumbered, <relations> elements in a slightly different order, a .digest hash on every node, timestamps, BackReference bookkeeping. The real, substantive differences — the ones you care about — are sprinkled across tens of thousands of irrelevant diff lines like needles in hay. A lot of promotions end up going out with "yeah it looks close enough" because nobody actually has the time to read all of that carefully.
Point Claude at both workspaces with this skill loaded and the ask changes shape. You don't ask "what's different" in the textual sense — you ask "what's meaningfully different." And you get an answer at the level IDM consultants actually think at:
"In dev, the Subscriber Event Transformation has a new rule
sub-etp-IG-Only-Sync-Modethat vetoes User modifies when thedrv.ig.enable.sync.only.modeGCV is true. Prod doesn't have it. The filter in dev also flipped DirXML-EntitlementReffromsubscriber=notifytosubscriber=syncon the User class. TheSafePermissionentitlement's value query is unchanged. Schema mapping is identical. No changes to the Create or Matching policy sets. Three new GCVs at DriverSet scope, all with sensible defaults but one —drv.ca.dummy.safe.name— has different values in the two environments (IGA-TEST1in dev,IGA-PRODin prod)."
That's the level at which promotion review actually happens. Same skill, same agent, same workspace files — just a question that asks for comparison instead of description. It also covers the inverse: comparing two customer tenants looking for configuration drift, checking what a package upgrade actually changed versus what the release notes claim, validating a backup against what's running live. For a consulting practice, the economics of the difference are hard to overstate — work that used to take a billable day takes an hour, and it's a more thorough hour than most humans manage.
Three reasons this is different from just keeping a crib sheet on your desktop and pasting it into Claude at the start of every session:
It triggers automatically. The skill's description names the things that signal "this is IDM" — .ScriptPolicy_, a path under Model/EdirOrphan/, phrases like "the AD driver" or "our PRDs." When the conversation hits any of those, the skill activates. You don't have to remember to prime Claude. You also don't pay context-window cost on sessions that aren't about IDM.
It's organized for progressive disclosure. The top-level SKILL.md is lean — it gives Claude the orientation (where things live, what the hub-and-spoke driver graph looks like, how to find X). The detailed grammar for DirXML Script, the RBPM tree, the schema file format — all of that lives in references/ files that Claude opens only when it actually needs them. You're not stuffing the whole domain into every turn.
It's versioned. It lives in a Git repo. When I learn something new about how Designer handles a corner case, I write it down once and push it. Every future session benefits.
The skill ships with a worked example: a full end-to-end trace of a real CyberArk driver — the same Point Blue Tech SCIM driver we use at customer deployments. The walkthrough starts at the .Driver_ metadata file, walks the relations graph to the Subscriber and Publisher channels, resolves each policy reference by ID to its human name, reads one representative DirXML Script rule (a drv.ig.enable.sync.only.mode
That example does double duty. It teaches Claude by demonstration (here's how to actually trace a driver, not just here's the theory) and it gives you, the human, a template for how to describe any driver in any workspace. When you ask Claude to "document this driver," this is the shape of the answer you'll get back.
Three paths, depending on what you use:
.plugin file from Releases, drag it into Cowork./plugin command pointing at the repo, or symlink skills/dirxml-designer-into ~/.claude/skills/ if you want just the skill without the plugin wrapper.SKILL.md into your system prompt, give the agent read access to references/ and examples/, and it'll work. The Claude-specific frontmatter is ignored by other runtimes.This is v0.1.0 — a first release that covers the on-disk workspace model. Obvious next frontiers: reading the actual generated Documentation output, parsing packages from their .jar source, handling the newer Identity Applications (formerly UserApp / RBPM) file formats. If you work in IDM and have Claude-assisted workflows you'd like to speed up, open an issue. If you find a corner of Designer I've gotten wrong, open a PR — the skill is MIT licensed, the content is Markdown, and the repo welcomes contributions.
The larger point, for IDM consultants specifically: we sit on top of a lot of tribal knowledge that's never been written down in a form a language model can use. Designer's object model, XDS semantics, the policy execution order, the quirks of specific shims, the conventions of each vendor's package prefixes — all of that is in our heads or buried in archived PowerPoints. Writing it down as a skill is a forcing function for capturing it once, in a form that compounds every time we work. I'd encourage anyone who does this work regularly to try the same experiment with whatever corner of the domain they keep re-explaining.
Repository: github.com/jcombs-pointblue/
If you like this content and would like to see more of it, let us know in the comments or send us a message.
