I was sketching a plugin called great-publishers when I noticed the error. I had drawn four distinct "departments" on the page: books, magazines, video, and marketing.
At first, this looked like organization. It felt like a way to keep the roster tidy. But a closer look revealed a fraud. The book-cover designer does not share a register with the ad-copywriter. The video editor does not follow the same reading pattern as the magazine art director.
They were not departments of a single craft. They were four separate plugins wearing a single costume.
The Three-Strike Rule
In software, as in language, we use euphemisms to hide a failure of thought. We call it a "department" when we actually mean a "separate plugin." To tell the difference, apply the Three-Strike Rule. If a subsystem triggers any of these signals, it is not a department; it is a split.
- Strike One: The Register Shift. Personas in a true plugin share a professional dialect. A book designer and a magazine art director both operate at the publication threshold; they speak the language of form and layout. A software engineer speaks the language of logic and state. If the "department" requires a completely different vocabulary, it is a separate plugin.
- Strike Two: The Reading Pattern. Every craft has a specific protocol for consuming information before making a decision. Publishers read the manuscript and the project bible. Engineers read the codebase and the architecture docs. If the department reads from different sources using different protocols, it is a separate plugin.
- Strike Three: The Output Shape. A plugin should own one craft. This means its skills produce a consistent class of artifact. Publishers produce form-stage deliverables—covers, jacket copy, layouts. Marketers produce campaigns and ad-copy. If the output of a "department" belongs in a different directory with a different lifecycle, it is a separate plugin.
The Diagnostic Test
When you are tempted to organize a plugin into departments, run this test. If you answer "No" to any of these questions, the plugin is too large.
- Do the personas share a real-world register?
- Do they share a reading-before-deciding pattern?
- Do the skills share a workflow shape?
- Would a user installing this plugin find value in most of the personas, rather than just one or two?
The cost of ignoring this smell is the "mega-plugin." The mega-plugin is a sprawling, ambiguous mass where the orchestrator must fight through irrelevant personas to find the right tool. It is the architectural equivalent of a government department: an entity so large that its primary function is to manage its own internal bureaucracy.
The fix is architectural fission. Split the "departments" into sibling plugins. Group them into a constellation. Trust the orchestrator to compose them.
A plugin that tries to do everything eventually does nothing with precision. One craft, one plugin.