I needed to see what my skills were doing
As my collection of AI skills grew, I returned to a method from UX: mapping the work so I could understand its parts and decide what to improve.
I was losing track of the AI skills I'd built. Some I'd forgotten I'd made. As I kept refining and reworking them, I wanted a way to see what each one did, how they fit together, and how I could work with them to improve them.
Without a way to review them visually, that was becoming difficult. I needed a view of the work that I could understand and use to make decisions.
Coming from a UX background, a blueprint seemed like a useful place to start. I'd used that approach many times, and recently revisiting my Sedgwick work reminded me why it had been valuable.
Returning to a familiar method
At Sedgwick, I mapped adjusters' actions alongside the information they collected and the systems that used it. The service blueprint helped explain how an assignment went out and how the completed work came back.
One connection was missing from the systems we'd mapped. We eventually found people copying information between them. Including that work in the blueprint made the handoff visible. It gave us a more complete account of how the process actually operated.
The Sedgwick case (opens in a new tab) goes into that work in more detail. Returning to it reminded me that a visual model gives me something concrete to examine: the actions, the connections, and the places where an explanation is still missing.
I wanted to bring that way of working to my skills. Having AI help read their instructions and build an editable map seemed like a logical way to approach the challenge. I could use a familiar method to examine something I was still developing.
Seeing how the skills fit together
A skill can describe a task clearly on its own while leaving questions about its place in the larger process. What does it need to begin? What does it produce? Who reviews that output? What happens before another skill or person can use it?
Those relationships matter when I'm deciding what to change. Two skills might use the same review instructions but apply different criteria. A reference from one skill to another might explain a dependency without actually passing any work between them.
The map needs to show what that connection means. Shared instructions, a completed handoff, and a possible future connection have different implications for how the work runs.
That also gives me a way to examine my own part in it. I can look at where I supply information, review an output, make a decision, or need to resolve something the instructions don't explain.
Read the diagram explanation
In the first example, two skills each refer to the same instruction. Dashed arrows indicate references, not work moving between the skills. In the second, one step produces an output, a person checks it, and the next step receives it. Solid arrows show work moving through that check. These are examples of possible relationships, not a record of a completed system.
Understanding a check before removing it
The recent review of my writing workflow supplied a concrete example. During a title update, I approved 19 revised titles in one response. That decision was then recorded against the individual articles. Counting the records as separate approvals would have exaggerated how often I'd been asked to decide.
There was still repeated work to address. Separate verification passes reconstructed parts of the same source and approval history. Where the evidence hadn't changed, a later check could reuse it and concentrate on the new work.
Other checks had a useful purpose. A separate reviewer had caught an ambiguity in a title. Checking a document after an update established whether the approved change had reached its destination intact.
I approved a simplification that brought the workflow stages together and carried the sources, review results, and approval in one edition record. The distinction between those checks helped identify what could be consolidated and what should stay.
Turning the approach into a reusable skill
Workflow Audit & Blueprint is the skill I'm preparing to release through Past Life. It examines supplied process instructions and, when available, a representative run. It separates what the instructions require, what the evidence shows happened, and what could change.
It produces a record of the events it can identify, findings tied to the evidence, and separate current and proposed maps. Those maps use Mermaid, a text format for diagrams that can be edited as the steps and connections change. For a service blueprint, the view can also separate a person's actions, the work they see, the work behind it, and the supporting systems.
To examine a process, start with its instructions, a clear beginning and endpoint, and an example of the work moving through it. When comparing skills, include the relevant instructions for each one. The map can only account for the material available; missing connections need to remain visible as questions.
If you have instructions but no completed run, the skill can review the intended process. It can't establish how many checks actually happened from those instructions alone.
The public package is still in preparation. Local tests have used fictional examples, and an outside-user trial remains ahead. I'm not attaching a time-saving figure to it.
What interests me is having a way to work through the system visually. I can examine what the skills do, question how they connect, and compare a proposed change with the current process. That gives me something I can understand and work with as I keep improving them.
