14 — Output Styles and Plugins — Persona, Verbosity, and Bundled Customization

"Theming and add-ons" was how I lumped output styles and plugins together, and the conflation hid two different axes. The split that fixed it: output styles adapt the agent's persona and verbosity by modifying its core system prompt, while plugins are a packaging format that bundles many customizations into one installable unit. [1][2] Styles change _how_ the agent talks; plugins change _what_ the agent comes with. They're different axes, and conflating them is how I missed both for a while.

The framing that clicked is to read styles as a system-prompt switch and plugins as a distribution format. An output style isn't a skin — it actually modifies the system prompt that frames every response, shifting the agent's behavior [1]. A plugin isn't a feature — it's a box that holds features (slash commands, agents, skills, hooks, MCP servers) so they can be installed, shared, and versioned together [2]. Once I saw them that way, the question "which style?" became about what kind of collaborator I wanted, and the question "which plugin?" became about what bundle of capabilities a workflow needed.

Output styles: switching persona and verbosity

The roadmap names the built-in styles and what each does to the agent's behavior [1]:

• Standard — the default coding mode. Direct, task-focused, minimal commentary.
• Explanatory — adds educational insight into implementation choices. The agent doesn't just make the change; it explains _why_ the change is shaped that way.
• Learning — a collaborative mode where Claude places TODO(human) markers to encourage hands-on contribution. It deliberately leaves parts for me to fill in, treating the session as a teaching exercise rather than a done-for-you edit.

The mechanism is what made it click for me: these aren't post-processing filters on the output. They modify the system prompt, so the change runs deep — the agent reasons differently in Learning mode, not just phrases things differently. That's why a style is a real behavioral switch, worth picking deliberately per session type. Explanatory when I'm learning a new codebase; Learning when I want to build the skill myself; Standard when I just want the change made.

Plugins: a packaging format for customization

If styles are a behavior switch, plugins are a distribution format. A plugin bundles multiple customizations — slash commands, specialized agents, skills, hooks, and MCP servers — into a single installable unit [2]. The roadmap frames them as a standardized way to distribute complex AI workflows across projects or within a team, so every developer has the same tools and coding standards.

The reason this matters is shareability. Individually, a hook, a skill, and an MCP server are each configured separately and live in different places. A plugin packages them together: install one plugin and a whole workflow lands — the commands it adds, the subagents it defines, the hooks it wires, the tools it exposes. For a team standardizing on "how we do deploys" or "how we run security reviews," a plugin is the artifact that carries that standard. They're discoverable through marketplaces and installable via the /plugin command [2].

Code intelligence: a plugin worth flagging

One specific plugin category deserves a mention because it changes what the agent can _perceive_. Code Intelligence plugins extend the CLI's native search by integrating with the Language Server Protocol (LSP), giving Claude the same IDE-level awareness modern editors have — go-to-definition, find-references, hover types [3][4]. Without it, the agent searches code like grep: text matches. With it, the agent searches code like an IDE: symbol-aware navigation.

The payoff is precision in the explore phase. "Find everywhere this function is called" is a fundamentally different query when the agent understands the symbol versus when it's matching a string. For large or strongly-typed codebases, a code-intelligence plugin meaningfully improves the quality of the research the loop does before it edits anything.

How I use this

The habit these notes left me with is two separate choices per session. First, the _style_: Standard for ordinary work, Explanatory when I'm in an unfamiliar area and want the reasoning surfaced, Learning when I'm building a skill and want to fill in parts myself. Second, the _plugins_: a small set that I install once and share with the team — a code-intelligence plugin for symbol-aware search being the one I notice most — and I resist collecting plugins the way I resist collecting MCP servers, because every command and agent they add is context the model carries. Styles change how the agent talks to me; plugins change what it comes with. Picking both deliberately is the whole job.

References

[1] Anthropic, "Output styles," Claude Code Docs, 2025. [Online]. Available: https://code.claude.com/docs/en/output-styles#output-styles

[2] Anthropic, "Discover and install prebuilt plugins through marketplaces," Claude Code Docs, 2025. [Online]. Available: https://code.claude.com/docs/en/discover-plugins

[3] Anthropic, "Code intelligence," Claude Code Docs, 2025. [Online]. Available: https://code.claude.com/docs/en/discover-plugins#code-intelligence

[4] Microsoft, "Language Server Protocol," 2025. [Online]. Available: https://microsoft.github.io/language-server-protocol/