Chapter 16Chapter 16. Building Skills and Plugins with Coding Agents

In the last four chapters you learned to work with a coding agent and to trust what it writes. In Chapter 12 you directed one. In Chapters 13 and 14 you read, tested and changed its code. In Chapter 15 you reviewed its changes before they reached main. All of that work was on code.

But much of what a team knows is not in its code. It is in how the team does its work. Take Brightline's accounts payable (AP) team, the people who pay the company's bills. Ana Morales, the AP analyst, knows which checks to run on every new invoice and which invoices are urgent. She also knows that any invoice over $5,000 needs the controller's approval. None of this is written where an AI tool can find it. Some of it is in Ana's head. Some is in a policy file that nobody opens. The rest is in prompts that each person on the team wrote for themselves.

So every time someone asks an AI tool for help with invoices, they explain the job again. Each person explains it a little differently, so the AI does the job a little differently each time. And at some point, one of those private prompts is out of date.

This chapter fixes that in two steps. First, you and Ana write the job down once as a skill. A skill is a short set of instructions, kept in a folder, that an AI tool reads when it needs to do that job. Second, you package the team's skills, together with the connection to its invoice data, as a plugin. A plugin is one bundle with a version number that everyone installs, so everyone's AI follows the same instructions. Skills and plugins follow open standards, public rules that anyone may build into a product. So the same skills work in many AI tools, not just one.

Figure 16.1. From know-how scattered in heads and private prompts, to one skill written with its owner, to one plugin the whole team installs.

The plugin you start here, the Brightline AP plugin, grows in every later chapter of Part III.

The point

Write once how your team does a job, as a skill, with the person who owns its rules. Keep every number in tested code. Then release it as a versioned plugin that works in any AI tool that follows the open standards.

After this chapter you can:

• Turn work you keep explaining into a skill: a folder of instructions and files that an agent loads only when it has that work to do.
• Choose the right piece for each job: a tool the agent already has, your own tested code, a skill, a link to another system, a helper agent, or a rule that cannot be ignored.
• Build a skill with a domain expert: the expert, who knows the work, writes the rules and the cases. You write the tests, the script and the skill.
• Package and release a plugin: skills and a ready-made link to another system in one installable unit, with a version, a list of changes and a required check.
• Use one skill everywhere: build it with one coding agent and run it in products from three different makers, because they all read the same standard.
• Watch it run, and know the limit: the data a running plugin sends tells you what ran, how long it took and what it cost. It never tells you the answer was right.
• Decide whether to trust someone else's plugin: read what it runs before you install it, because it runs as you, with your permissions.

This is a co-build chapter, which means the work is split. A domain expert writes the rules a skill follows. A builder, the person who builds and packages it, does the rest. Domain experts should read the overview, 16.1 to 16.4, 16.6 and 16.9. Builders read everything and do the lab.

Why it matters

Grace runs month-end close, the work of finishing a month's accounts, at a 30-person accounting firm in Madison, Wisconsin. Over two years, the firm's staff each saved their own copy of a "month-end close" prompt in a notes app. The prompts looked alike, so nobody compared them. One copy was six months old. It still said partners approve payments "over $20,000", from before the firm cut the limit to $10,000.

In March a new hire used that copy. The AI did what it said. A $14,000 invoice was paid without a partner's approval. A criminal had changed that vendor's bank details the week before. The bank recovered part of the money. The firm's insurance company asked one question the partners could not answer: which version of the procedure was the new hire told to use?

Nobody in Grace's story was careless. Three things failed, and each needs its own fix.

First, the procedure was kept in a dozen private copies, and nothing told anyone which one was current. Copies like these drift, which means they slowly stop matching. One shared, versioned skill fixes that.

Second, the limit was a word in a paragraph. Keep it in tested code, and a test proves it. If the limit changes, one reviewed change moves it, and the checks stay red until every place that holds it agrees.

Third, nothing stopped the payment itself. No partner's approval was required before the money moved, and nobody checked the vendor's newly changed bank details. No instruction can do that, however current it is. Only a control where the money moves can do that. It checks who is asking, the limit and the approval every time.

This chapter builds the first two fixes. Chapter 23 builds the third.

Figure 16.2. Grace's three failures. A skill and tested code fix the first two. Only a control at the action fixes the third.

Brightline's limit will change one day too. On that day, what carries the change into every installed copy, and how would anyone know which version ran? 16.6 answers both.