Building for One Organization Without Losing Portability

The management plugin in knowledge-work-plugins treats creation and customization as discovery work before they become file work. This chapter focuses on how an author starts with a real problem, chooses only the components that problem needs, adapts portable workflow language to an organization’s tools, and validates the result before packaging it. The practical outcome is a way to preserve portability without pretending that an organization’s terminology, permissions, and connector semantics can be guessed from a template.

Start with the work, not the component inventory

The prescribed creation process begins by asking what the plugin should do, who will use it, what problem it solves, which tools it may need, and whether there is an existing workflow to reference. That order matters. A component inventory starts from what the platform can contain. Discovery starts from what the user is trying to accomplish and what conditions make that work difficult.

A plugin for turning meeting transcripts into notes may need one skill and no external connector. A plugin for reviewing code quality may need several skills, detailed style references, and a source-control integration. A full engineering workflow may also need an agent for autonomous ticket analysis, a hook for lifecycle context or checks, and several connector categories. These examples are not a ladder in which every package should grow toward the largest shape. They show that component choice should follow the number of distinct responsibilities and boundaries in the work.

The next phase is component planning. The management guidance asks the author to decide whether the problem needs skills, MCP servers, agents, or hooks, and to show the components that are deliberately not needed. That negative space is useful. Saying that no agent is required means the workflow is not promising an autonomous multi-step worker. Saying that no external server is needed makes the package easier to inspect and less dependent on remote availability. A minimal component plan is not a sign of a weak plugin; it can be evidence that the problem has been scoped honestly.

Design questions then make hidden assumptions explicit. For a skill, the author clarifies what user language should trigger it, what knowledge domain it covers, whether references are needed, and which tools it may use. For an agent, the author specifies when it should run, which tools it may access, and what output it should produce. For a hook, the author identifies the lifecycle event and whether the hook validates, blocks, modifies, or asks for confirmation. For an MCP server, the author defines the service type, authentication, and exposed operations.

The questions are not bureaucracy around implementation. They are a way to locate authority and state before the package exists. A skill that is supposed to read a project tracker but also update it has two different action surfaces.