A Working Mental Model: Capability, Context, and Authority
The knowledge-work-plugins repository can now be read through one practical model: a plugin combines capability, context, access, and authority, but those properties do not arrive as a single package of certainty. This checkpoint connects the repository’s skills, progressive references, connector abstractions, MCP services, fallbacks, and action controls so the reader can trace one request from intent to result. The judgment it supports is simple to state and demanding to apply: a system may know how to do something, reach the relevant data, and still lack enough evidence or permission to do it safely.
One request crosses several boundaries
Start with a user intent, not with a file. Suppose the user asks for help with a work problem that requires specialized context. The plugin’s first job is to identify the kind of work. Its skill metadata and core instructions supply the capability: they define which evidence matters, what sequence to follow, and what a complete result should contain. If the task has a deeper branch, the skill can bring in a reference. At this point, the plugin has a method, but it does not yet have the user’s actual facts.
The next boundary is context. The workflow may receive a local file, a task list, a memory entry, or information the user states directly. It may also need live records from external systems. Context is not identical to knowledge. A skill can know how to prepare a sales brief without knowing which meeting the user means. It can know how to inspect a dataset without knowing the current table names. A package can contain a reference about a method without having the input needed to apply the method.
Access is the bridge to live context. A category placeholder describes the kind of service required; an MCP configuration names a concrete endpoint or server. If the connection works, the workflow can request records through the external system’s permissions and return evidence. If it does not, the workflow must move to a fallback or ask for a missing input. The connector changes what the plugin can observe, but it does not decide what the evidence means or whether an external change is authorized.
Validation sits between evidence and conclusion. The data plugin’s workflow makes this explicit by moving from question framing and schema discovery through query execution and sanity checks before presenting results. A support escalation similarly turns scattered context into a structured issue with reproduction steps, impact, a target team, and follow-up. These examples show that “retrieved” is not the same as “ready to act on.” The workflow still has to test completeness, relevance, and uncertainty.
Finally comes authority. A read-only answer can often end after evidence is interpreted and qualified. A proposal may need to show the user what would happen next. A write changes an external state and may require a connector permission, an explicit user request, or an approval step. The repository’s action patterns keep these modes distinct. A skill can suggest a change without carrying it out; a marketplace entry can keep a journey in draft; a finance workflow can require the advisor to approve write-back. Authority is the boundary that prevents capability and access from silently becoming action.