Plugin Evaluation

Anyone trying to show an employer that they can do forward deployed engineering work needs something concrete to point to. A résumé line saying you understand customer problems is easy to write and hard to verify. One direct way to produce concrete evidence is to build a plugin on Anthropic's platform.

The source presents this path as especially current. Anthropic's Code with Claude conference in 2026 introduced enterprise plugin templates, which cover several industries, including HR, design, engineering, investment banking, equity research, private equity, and wealth management. A plugin built in one of these verticals gives you something a reviewer can install and try, rather than a claim you have to defend from memory.

The reason plugins are attractive is that a well-built plugin is described as a microcosm of forward deployed engineering work. Even at small scale, a plugin forces you to make the same kinds of decisions a deployed engineer makes on a real customer engagement. As you read, keep one question in mind: what does a hiring reviewer need to see in order to judge the work without having to take your word for it?

The source describes making a well-built plugin as a sequence of decisions rather than a single act of writing. Follow one plugin through those decisions and notice what each decision constrains. First, you pick a vertical, meaning a specific industry or domain you understand. Second, you identify a job-to-be-done, which is one concrete task that people in that vertical need to get finished. Third, you package the prompts, tools, and configuration that let the plugin carry out that task. Fourth, you make the package self-contained enough that someone else can install it and try it in about five minutes.

The order matters, and the diagram below traces it. The vertical comes first because it constrains every later choice. A job-to-be-done only makes sense inside a domain, and packaging only makes sense once you know which task it serves. Treating the plugin as a chain of decisions, rather than as a pile of prompts, is what turns a demo into something a reviewer can judge. The final stage of the diagram is the portfolio entry, which the source ties to evaluation evidence. That evidence is added to the shipped plugin, not left for a reviewer to infer.

Each of the three parts has a distinct role. The prompts carry the instructions that tell the underlying model what to do for the task. The tools are the capabilities the plugin can call on while doing that work. The configuration holds the settings that shape how the package behaves. Because all three travel together, the plugin can be handed to someone else as one unit, rather than as a set of loose files that only you know how to assemble.

The diagram shows containment only. It does not show how the parts interact at run time, because the source does not describe that interaction in detail, so this article does not claim a specific call order. What the containment view does establish is that a portfolio plugin should be readable as a package with these three named parts, so a reviewer can find each one quickly.

Building the package is only part of the work. The source states that a plugin produces three things: a trace, an eval set against the plugin's task, and wrapper logic that makes the plugin reliable. The source names the trace and the eval set without defining every detail of either, so treat them here as outputs you must be able to show, not as a fully specified format.

The wrapper logic is the piece the source ties to reliability. The diagram below follows the source's wording: the plugin produces the trace, the eval set, and the wrapper logic, and these outputs are what feed the evidence a reviewer can check. The word defensible in that final step reflects the source's emphasis on evidence and is not a separate technical term.