AI skills and human skills: why a skills library needs an architect

Before AI Power Tools builds a reporting database from the Westbrook Bank reference model, it stops and shows you three application components. Each is classified Business-Critical. Each is scoped to a financial-privacy regulation. Each has a business owner and a technical owner named. None has a stereotype.

That last fact is the problem. The reporting database is built from stereotyped elements, so these three will not appear in it, or in any report built on it. Somebody classified them deliberately, and no report would ever have shown them. This is the governance gate in the reporting database skill, and the next question is how many of those you have.

What the skill did

A skill is a written procedure the AI follows: the phases, the checks, the known defects, what to verify before saying “done”. This one lists every element without a stereotype before it builds anything, because that is where a report quietly under-reports. Where the evidence supports a stereotype, it suggests one and shows the evidence. Where the modeling language defines nothing that could apply to that kind of element, it says so and points at extending the language rather than inventing a suggestion. It applies a stereotype only in that narrow case and only with your approval. It does not clean the model.

What it cannot decide

Look at what is left once the tool has done its part.

• Is an application component with this tag set a business application in your MDG, or something else, such as an interface or a piece of infrastructure?
• Were the stereotypes left off by accident, or because these three were meant to sit outside reporting, perhaps on their way to retirement?
• Can the Business-Critical tag itself be trusted? Who set it, and when?
• If your language has no stereotype that fits, is that a gap in the metamodel the organization should close, or three people being careless?

The tool has no basis for any of these. They are decisions about your modeling language and your estate. Automation checks completeness. People own correctness.

What an architect does at the gate

The sequence is plain, and every step is a person.

1. Open the three components and read the owner fields and notes. Somebody wrote a reason, or did not.
2. Ask the named owners why these three carry no stereotype. The answer is usually in someone’s memory, not in the repository.
3. Ask the natural next question: how many others like these exist in your own repository?
4. Decide. Apply a stereotype, extend the modeling language so one exists, or exclude the elements on purpose and record why. The build keeps a record of what was excluded and why, so the decision survives.
5. Rebuild, so the reconciliation reflects the decision.

None of that is difficult for a person who knows the estate. All of it is impossible for a tool that does not.

The same boundary runs through the library

Every skill stops where judgment starts, and the library lists the stopping point beside each one.

• The model hygiene skill finds orphans. Whether an orphan is dead or simply not yet connected is yours to say.
• The MDG build skill builds an MDG from a source model. Whether that source model is the standard or an accident is yours.
• The diagram composition skill lays out a diagram that reads as deliberate. What to leave off it is yours.
• The stakeholder reporting skill rolls the model up into business terms. What to say about completeness is yours, because a roll-up by business owner looks equally authoritative whether the field is filled in on 12% of applications or 100%.

The reporting build makes the same point against itself. Every build counts its own output back against the repository, and on the reference model every check passes. That proves the database matches the repository. It says nothing about whether the repository is right. A self-consistent database that quietly under-reports is the characteristic failure of this whole category, and reconciliation catches the build’s mistakes, not the model’s.

Why a skills library needs an architect

A skill compresses the procedural part of experience: the order of steps, the checks, the traps. That is worth having, and it is why the library is the value in AI Power Tools and the tooling is the easy part. But procedure is the portion of an expert’s work that can be written down. The remainder is knowing which question matters, what the standard really requires versus what is habit, and whether a clean-looking answer deserves to be believed.

The skills are good at the first kind of work, and that is the point of them. They are not designed to do the second kind, and the library says so by listing the judgment beside every skill.

You can see the distinction in how the tool ships. AI Power Tools ships its skills as written procedures that Claude and GitHub Copilot both follow. A skill is someone else’s method written down. Handed to a competent architect it makes them faster. Handed to someone who does not know the estate, it produces output that looks finished, and finished-looking output gets accepted.

What that means for your team

Knowing the architecture well enough to make the call, and knowing what to ask next, is the part no download supplies. It is what our Foundations courses build on your own repository, and what mentoring makes stick afterward. The skills library lists each skill beside the judgment it depends on. The gate itself is shown on the reporting and Power BI page; the Governance page puts it in a wider conformance practice.

Questions people ask