Skills are the vehicle

You’ve cleared the skills hurdle. Your people have learned to work with AI: they frame the work, give it context, review what comes back, and they’re getting time back.

It’s tempting to treat that as the finish line. It’s barely the start.

Stopping at skills

Stop there, and here’s what you get.

An organisation full of people who are individually faster. A library of a few hundred prompts, agent skills and plugins, each making one task a bit quicker. A dashboard of active users, hours saved and skills built, all heading up and to the right. And a business that, in the way it actually runs, hasn’t changed.

A thousand people saving twenty minutes a day is real. It’s just not a strategy.

Organisations stop there because skills fit how organisations are already built. A skill has one team, one budget and one owner, and its return is easy to count in minutes saved. Nobody has to agree anything with anyone else.

The return that matters doesn’t sit inside one team. In my experience, most of the time in shipping something doesn’t go on the steps a skill speeds up. It goes on the gaps between teams: waiting, rework because something got lost between product and engineering, a security finding a week before release, a feature that ships and doesn’t move the number it was meant to. Those gaps cross a line on the org chart, so often nobody owns them, and it’s nobody’s job to report on them.

1. ProductPRDSkill
2. Intent lost in the ticket
3. EngineeringBuildSkill
4. Waiting for a reviewer
5. EngineeringReviewSkill
6. Rework
7. SecuritySecuritySkill
8. Found a week before release
9. OpsReleaseSkill

Four levels of a pull request

So what do you do? Let’s look at a pull request. Simple, right?

Simple enough that most engineering teams I talk to have built an AI reviewer by now.

1. A skill

   Who: One engineerOne review

   This is the skills hurdle: an engineer learning to work with the new tech. They write a review skill and run it before asking for a human review. They catch more and wait less. Three other teams have built their own version, each with its own idea of what good looks like.

2. A workflow

   Who: One teamEvery PR

   The review runs on every pull request, alongside the tests and security scans, against the team’s conventions. Authors fix the obvious things before a human ever looks. The team’s review queue gets shorter, not just one person’s.

3. A domain capability

   Who: EngineeringShared context

   One reviewer across engineering, carrying security, platform and architecture context. Findings feed back into the standards and the platform, so the same mistake turns up in fewer teams.

4. A cross-domain initiative

   Who: ProductEngineeringThe business

   The pull request stops being an engineering-only process. Another domain joins it, and the question shifts from “is this good code?” to “is this what we actually asked for?”

The code reviewer barely changes between level one and level four. What changes is what’s connected around it, and that’s where the return comes from.

Level one is people learning to work with the tech. Every level after it is people learning to work with each other through it.

The pull request today

A code reviewer should stay a code reviewer. It checks the diff, and it’s good at that. But a pull request goes through more than code review: tests, security scans, a preview build, and eventually someone from product clicking around to see whether it does what they asked. That last step is usually manual, late, and the one that sends work back.

The game changer: the PRD

Pull requests are great and all. Faster reviews, cleaner code, fewer silly mistakes. But you can automate every step in that pipeline and still ship the wrong thing, just quicker. To change that, you have to change something about the process itself, not just speed it up.

And the thing that gets you to level four isn’t a better reviewer. It’s a document product already writes.

Most product managers have a skill of their own by now, one that turns discovery notes and customer feedback into a PRD. That PRD goes into a ticket, gets summarised into acceptance criteria, and rarely reaches the pull request. Two good skills, in two domains, that never meet.

Connect them by giving the PRD its own step in the pull request. Alongside code review, an intent check reads the PRD and the change together, so the pull request carries product’s intent as well as the code. It can flag that the change handles the happy path but misses the edge case product called out in section three, or that the feature works but doesn’t capture the metric the PRD said would prove it. Product still signs off, but they start from a list of gaps instead of a blank preview link.

1. Code reviewIs this good code?
2. TestsDoes it still work?
3. Security scanIs it safe?
4. Product manager's skillPRD
   Intent checkDoes it do what product asked for?Product
5. Sign-offProduct starts from a list of gaps.

Product owns the intent check. It’s their intent being checked, so they decide what it looks for. Engineering just hosts it in the pipeline.

From PRD to Work Pack

The PRD on its own isn’t quite enough, though. It’s one domain’s view. The Work Pack is the PRD’s intent plus everyone else’s context and constraints, with a definition of success the business recognises. If skills are the vehicle, the Work Pack is where it’s going.

The PRD gets you to level four. The Work Pack is what keeps you there once more than two domains are involved. It has one owner: whoever owns the outcome, which is often product but not always. As in the participation gap, the business writes the part above the line in plain language, and engineering and the agents own the detail underneath. Each domain adds what it knows: product the intent, security the constraints, support what happened last time. The skills underneath mostly don’t need rebuilding. They need something to work towards.

The Work Pack is also the unit you measure: not how many reviews ran, but whether it delivered what it said it would.

Above the line · the Work Pack, owned by the outcome owner

Intent

From the PRD: the problem, for whom, and why now.

Context

From support and ops: what happened last time.

Constraints

From security and legal: what can't happen.

Success

From the outcome owner: the number it should move.

---

The line

Below the line · the skills that deliver it

PRD skill

Turns discovery into intent.

Code review

Is this good code?

Intent check

Does it do what was asked?

Tests and scans

Does it work, and is it safe?

Final thought

Clearing the skills hurdle is worth doing properly. But if your AI strategy ends at a skills library and a training programme, you’ve built the vehicle and parked it.

Skills are how the work gets done. The return shows up when they’re pointed at an outcome the whole business agreed on.