When I first looked at the Stage 4 material, I thought I had to build the skills in the order they appeared in the learning path. Create architecture. Create a PRD. Create UX. Plan the implementation. Work my way down the list.
That was the wrong place for me to start.
I already had skills that did useful work. What I didn’t have was a clear enough picture of how one step should hand off its work to the next. I started sketching the workflow and the contracts between its steps before I had settled what would run inside every box.
Draw the boxes and arrows first
For the certification project, I was trying to build a harness that could take a feature story through a useful sequence of work. The initial path was simple: plan, implement, test, verify, and log.
I needed to know what each step received and what it was expected to produce. The plan had to be usable by implementation. The implementation had to leave behind something the test step could exercise. Verification had to provide enough evidence for a person to decide whether the feature was ready. Logging had to preserve what happened so I could learn from it, and feed it back into improving the harness.
Those boundaries mattered more than choosing a particular skill for each node. If the contract stayed clear, I could replace or improve the implementation without redesigning the whole workflow. I could make progress on the structure while I was still learning what belonged inside it.
The workflow connects its steps to checks, human approvals, and an audit trail.
I could also describe the work in terms I already used with the team. A story gives us the behavior we want to change and the scenarios that help us recognize it. A UI design and an API contract describe what has to line up for that behavior to work. Those artifacts give each step something concrete to pass forward, rather than leaving the next agent to guess what I meant.
That is the idea behind the arrows between Stage 3 and Stage 4. The AI Maturity Model playlist provides the broader context, but the question I had to answer was more concrete: what does one step need from the step before it?
Then map the skills I already had
Once the workflow made sense, I could look at the existing skills and ask which ones fit the nodes. If a step had no good match, that was a real gap to address. I did not need to create a skill just because its name appeared in a course outline.
This builds on the Stage 3 work I described in Write the Skill That Builds Skills. That work gave me reusable skills and a way to improve them. Stage 4 gave me a different problem: connect those capabilities without pretending that the handoffs would take care of themselves.
I also had to be careful about the word “evaluation.” An evaluation of an individual skill tells me something about that skill. It does not automatically tell me that the full workflow passes the right information from step to step. Testing the Wrong Unit covers that distinction from the Stage 3 side. Here, the workflow contracts gave me a place to make the handoffs explicit and decide what evidence I needed at each boundary.
The order changed how I learned
I learned about the harness while it was doing work. I built the skeleton, connected steps, and ran real features through it before I felt fluent in every implementation detail. The outcome gave me something concrete to examine. Then I could ask how the guardrails, approvals, and logging worked.
That order would not suit everybody. It suited me because I had a real workflow in mind and enough experience with its individual tasks to recognize when the results were wrong. It also gave me a way to separate two questions: is this step doing its job, and does the whole sequence work?
It helped me make room for a different kind of learning, too. I did not need to understand every implementation detail before I could test whether a workflow node was in the right place. I could give the harness a real feature, examine what it produced, then investigate the runner or guardrail when I hit something I did not understand. The workflow was both a way to get work done and a structure for learning how the pieces fit.
The shift was from “Which skill do I need to build next?” to “What does this workflow need from this step?” Once I could answer the second question, the first one became much easier.
Leave a Reply