Plugin Structure
A plugin is a self-contained package of prompts, tools, and configuration for one specific task.
Why a Plugin Counts as Evidence
Anyone who wants 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. This article looks at one direct way to produce that evidence: building a plugin on Anthropic's platform. The source presents this path as especially current, because Anthropic's Code with Claude conference in 2026 introduced enterprise plugin templates covering several industries, including HR, design, engineering, investment banking, equity research, private equity, and wealth management.
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. Keep one question in mind as you read: what does a hiring reviewer need to see in order to judge the work without having to take your word for it?
What a Plugin Packages
A plugin is a self-contained package of prompts, tools, and configuration for one specific task.
The key phrase is self-contained package. The three named parts travel together as one unit. This matters because the plugin can be handed to someone else as a single thing, rather than as a set of loose files that only the author knows how to assemble. The definition also limits the scope: a plugin is built for one specific task, not for everything a user might want.
A portfolio plugin should be readable as a package with three named parts, so that a reviewer can find each one quickly.
Tracing the Path from Vertical to Portfolio Entry
The source describes making a well-built plugin as a sequence of decisions rather than a single act of writing. Follow one plugin through the sequence. The state of the plugin changes at each step, and the final step produces something a reviewer can evaluate.
- 1Step 1: Choose a vertical, meaning a specific industry or domain you understand.
- 2Step 2: Identify a job-to-be-done, one concrete task that people in that vertical need to get finished.
- 3Step 3: Package the prompts, tools, and configuration that let the plugin carry out that task.
- 4Step 4: Make the package self-contained enough that someone else can install it and try it in about five minutes.
- 5Step 5: Ship the plugin, which produces a trace, an eval set against its task, and wrapper logic.
- 6Step 6: Present the plugin as a portfolio entry whose eval evidence lets a reviewer check it.
The order matters. The vertical comes first because it constrains every later choice. A job-to-be-done only makes sense inside a domain, and the 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 demonstration into something a reviewer can judge.
Parts Inside the Package
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. All three sit inside the single package, as the diagram shows.
Following a Claim Back to Its Proof
Building the package is only part of the work. The source states that a shipped plugin produces three things. The trace and the eval set are the outputs you must be able to show. The wrapper logic is the piece the source ties to reliability. Eval evidence that lets you defend each plugin matters more than simply having many plugins in a portfolio.
Now trace the link in the other direction. If a reviewer asks whether your plugin can be trusted, the answer should point to a specific output, and that output should point to the task it was checked against. The diagram below follows that chain. The source names the trace and the eval set without defining every detail of either, so treat them as outputs to show rather than as a fully specified format.
Worked Example: Planning an Equity Research Plugin
The example below is generated for teaching purposes. It applies the four decisions in order. Equity research is one of the template industries the source names, but the specific job-to-be-done is an illustrative choice, not a source example.
From Vertical to Evaluable Entry
Plan one portfolio plugin that a hiring reviewer can judge without relying on the candidate's word.
- 1Choose the vertical
Pick equity research, a domain the candidate understands and one the source lists among enterprise plugin template industries.
- 2Identify the job-to-be-done
Choose one concrete task, such as turning a company's earnings update into a short summary of the main changes for a reader.
- 3Package the parts
Write the prompts that tell the model how to produce the summary, the tools the plugin can call while working, and the configuration that shapes its behavior.
- 4Make it installable
Arrange the package so that someone else can install it and try it in about five minutes, with no loose files only the author understands.
- 5Collect the outputs
Keep the trace of a run, build an eval set made of earnings updates with known correct summaries, and include the wrapper logic that supports reliability.
- 6Write the portfolio entry
Present the plugin with its eval evidence, so the reviewer can check each claim against the eval set rather than trusting the description.
A single portfolio entry that connects one vertical, one task, three named parts, and three outputs, each of which a reviewer can inspect.
Mistakes Beginners Make with Portfolio Plugins
Common mistake Building many plugins with no evaluation evidence
Why it failsThe source says eval evidence that lets you defend each plugin matters more than simply having many plugins in a portfolio.
Do this insteadBuild fewer plugins and attach an eval set and a trace to each one.
Common mistake Choosing a task before choosing a vertical
Why it failsThe vertical constrains every later choice, and a job-to-be-done only makes sense inside a domain.
Do this insteadPick the vertical first, then identify the job-to-be-done within it.
Common mistake Treating the plugin as a pile of prompts
Why it failsA pile of prompts cannot be handed over as one unit, and the reviewer cannot find each part quickly.
Do this insteadPackage the prompts, tools, and configuration together so the three named parts are easy to find.
Common mistake Describing the outputs without showing them
Why it failsA plugin without eval evidence can be demonstrated, but the candidate has less to point to when a reviewer asks why it should be trusted.
Do this insteadShow the trace, the eval set, and the wrapper logic, and link each one to the claim it supports.
Common mistake Assuming the package must be complicated to count as serious work
Planning Your Own Portfolio Plugin
What do you think happens?
Which of the four decisions comes first when making a well-built plugin?
Reveal answer
Choose a vertical
The vertical comes first because it constrains every later choice. The job-to-be-done only makes sense inside a domain, and the packaging only makes sense once you know which task it serves.
Write a one-paragraph plan for a portfolio plugin in a vertical you understand. Name the vertical, the job-to-be-done, the prompts, tools, and configuration you would package, and the eval evidence (trace, eval set, wrapper logic) you would show a reviewer. For each output, state which claim it lets a reviewer check.
Hints
- Start with the vertical, because every later choice depends on it.
- Make the job-to-be-done one concrete task, not a broad goal.
- For each output, ask: what would a reviewer need to see to check this claim without trusting me?
Key Takeaways
- A plugin is a self-contained package of prompts, tools, and configuration for one specific task.
- A well-built plugin is made through a sequence of decisions: choose a vertical, identify a job-to-be-done, package the parts, and make it installable in about five minutes.
- A shipped plugin produces a trace, an eval set against its task, and wrapper logic that supports reliability.
- Eval evidence that lets you defend each plugin matters more than simply having many plugins in a portfolio.