# Chapter 16. Building Skills and Plugins with Coding Agents (/building-ai-workers/skills-and-plugins/overview) --- type: Document title: "Chapter 16. Building Skills and Plugins with Coding Agents" description: "Package professional work as skills, written with the person who owns the rules, and ship them as an installable plugin. Taught through the open standards for skills, plugins and telemetry, then built with Claude Code and ported with Codex and OpenCode to six places where people use AI." status: stable order: 316 chapter: "16" part: III ksor: owner: team:panaversity audience: [ public ] approval: by: process:panaversity at: 2026-11-02T19:44:48Z expert_status: co-build objectives: - { id: CCDV-F.D8.S3, label: direct } - { id: CCAR-F.D3.T2, label: direct } - { id: OAI.3.5, label: direct } - { id: OAI.3.6, label: direct } - { id: CCDV-F.D2.S5, label: supporting } - { id: CCDV-F.D2.S6, label: supporting } - { id: CCAR-F.D2.T4, label: supporting } - { id: CCAR-P.D2.T5, label: supporting } word_budget: 4000 prerequisites: [ "01", "02", "03", "04", "05", "06", "07", "08", "09", "10", "11", "12", "13", "14", "15" ] build_step: "The Brightline AP plugin v0.1.0: an invoice-triage skill co-authored with the AP lead, a Monday report started by name, the due-by-Friday skill, and a pinned, read-only data connector, built with Claude Code and merged as a reviewed pull request, then packaged for OpenAI with Codex and for OpenCode with OpenCode, and used in six places" artifact: "brightline-ap with plugin/ (three skills, plugin.json, mcp.json, .claude-plugin/plugin.json, .mcp.json, CHANGELOG.md), src/triage.ts and its tests, py/brightline_ap/triage.py, the catalogs .claude-plugin/marketplace.json and .agents/plugins/marketplace.json, .codex/config.toml, opencode.jsonc, the plugin-valid check, NOTES.md and ports/ch16.md, tag ch16" lab_data: "https://github.com/panaversity/agentfactory-v2-resources/releases/latest/download/brightline-lab-ch16.zip" field_guides: [] delta_entries: [ "D-022" ] concepts: [ "16.1", "16.2", "16.3", "16.4", "16.5", "16.6", "16.7", "16.8", "16.9", "16.10" ] last_verified: 2026-11-02 generated: at: 2026-11-02T19:44:48Z by: esl-rewrite/1.2.0+ksor.1 trust_tier: unverified build_id: sha256:e1fbcb7d9a8f8b9b7cb96875022325c02c9ba4be94cef13b301cbd39a9edad85 dirty: true ksor_version: 0.0.60 --- In the last four chapters you learned to work with a coding agent and to trust what it writes. In [Chapter 12](../agentic-coding/overview.md) you directed one. In Chapters [13](../programming-fundamentals/overview.md) and [14](../structuring-programs/overview.md) 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. ![Where a team's know-how lives, and where this chapter puts it. On the left, three dashed boxes for today: in people's heads, in a policy file nobody opens, and in private prompts, each a little different. Arrows lead to the middle: one skill, written with the person who owns the rules, with every number from tested code below it. An arrow leads right to one versioned plugin the whole team installs, which reaches three AI tools, labeled any tool that follows the open standards.](img/know-how.png) *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](from-a-prompt-to-a-skill.md) to [16.4](commands-and-who-may-start-them.md), [16.6](shipping-a-version.md) and [16.9](installing-is-a-trust-decision.md). 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. ![Three failures, three different fixes. Three rows, each reading left to right. First row: a dozen private copies, and no way to tell which is current, fixed by one shared, versioned skill, built in this chapter. Second row: the approval limit was a word in a sentence, fixed by the limit in tested code, with a test that proves it, built in this chapter. Third row: nothing stopped the payment itself, or the changed bank details, fixed by a control where the money moves that checks who asks, the limit and the approval, built later in the book. A line at the bottom says no instruction, however current, can stop a payment, only a control at the action can.](img/three-fixes.png) *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](shipping-a-version.md) answers both.