Context Is a Product Feature, and a Liability

The knowledge-work-plugins repository treats context as part of the product, not as background decoration. This chapter focuses on two forms of context: local memory that helps Claude understand a person’s work, and live evidence assembled from several workplace systems. The practical judgment is that makes context useful is also what makes it risky: a remembered shorthand or a retrieved message can remove friction, but it can also be stale, incomplete, ambiguous, or mistaken for authority.

Memory that reduces friction

The productivity plugin makes state visible through three connected elements: a shared Markdown task list, a two-tier workplace memory system, and a local dashboard. The task list records commitments and their status. Working memory captures people, projects, terms, and preferences that Claude needs repeatedly. Deeper memory files hold more detail, while the dashboard gives the user a visual way to inspect and edit the same working state.

This design addresses a real problem in knowledge work: people rarely speak in fully expanded descriptions. They use nicknames, acronyms, project codenames, and shorthand that make sense inside their team. A request such as asking someone to prepare a familiar report for a known deal may be efficient for a colleague and opaque to a general assistant. The productivity plugin’s start workflow therefore begins by asking the user where their tasks live and then interactively decoding terms it does not understand. The memory is built from the user’s actual work rather than from generic assumptions about the organization.

The benefit comes from persistence. Once a person, project, or acronym has been clarified, later requests can refer to it naturally. The user does not have to restate the same relationships in every conversation. A task can retain its owner, context, and due date. A dashboard can expose the current state without requiring the user to reconstruct it from chat history. In this sense, memory is not a decorative profile; it is a local data layer that changes how a workflow interprets the next request.

The design also places limits on that convenience. The task file remains user-editable, and the task-management skill asks before adding commitments extracted from a meeting or conversation. The start workflow separates high-confidence findings from terms that need clarification. Those choices preserve a boundary between what Claude inferred and what the user has accepted into working memory. Without that boundary, the system could turn a tentative mention into a task, a guessed role into a fact, or a temporary project name into a permanent relationship.

stateDiagram-v2 [*] --> Uninitialized Uninitialized --> Supplied: user provides tasks or context Supplied --> Enriched: shorthand is decoded Enriched --> Grounded: current work uses memory Enriched --> Clarify: ambiguity remains Clarify --> Supplied: user answers Grounded --> Stale: people, projects, or terms change Stale --> Clarify: verify before reuse Grounded --> Used: context supports a task Used --> Stale: later change or drift

The lifecycle matters because local memory has no automatic claim to permanence or truth. A user may change teams. A project codename may be reused. An acronym may mean something different in another group.