As saved guidance grew, loading every full body at the start became cumbersome. A more subtle concern was an old instruction continuing to influence work after it had been disabled or edited. I examined Northstar's listing, reading and context-building functions separately to distinguish present selection from historical record.
Send selection metadata in the context catalog
TaskSkillService.context selects enabled entries, places identity, name, description and version in catalogue, and begins with an empty loaded array. It does not indiscriminately include full instructions and usage. A separate native form adds an exact path for reading a chosen definition. Knowing that path still differs from actually reading the body.
TaskSkillService.list can produce broader items including instruction text for management purposes. I therefore do not claim that every listing function categorically omits bodies. A data-minimization explanation needs to identify the particular output boundary. The context catalog and internal management material have different contracts, even though both are informally called a list.
Reading finds a definition that is enabled now
Read validates the supplied identity and searches the current project's list for an enabled matching item. Otherwise it raises SKILL_NOT_ENABLED_IN_PROJECT. An earlier catalog observation does not entitle a caller to keep reading disabled guidance. Existing tests also preserve an intentionally empty selection instead of silently restoring built-in defaults.
Custom-definition scope can depend on configuration: the implementation has a sharedProfiles option for shared-project behavior. I do not generalize a profile-isolation test into a universal rule for every installation. Read scope must follow the actual storage configuration. The central boundary is comparison with the currently selected and enabled definition at the time of access.
Historical context assembly compared versions as well
The historical task context builder keeps read skills in a Map and retains only the three most recent. Rereading an identity moves it to the newest position. Subsequent context includes a body only if the current catalog still contains the same identity and version. This reduces retention of a disabled or superseded instruction body as if it were current.
Three is that implementation's context-management value, not a limit on creating skills. Reading surviving source also does not establish that every conversation of a current external agent is pruned the same way. I considered the removal of the embedded judgment path alongside the retained code, separating a reusable design decision from a claim about today's full connection behavior.
Keep a read receipt in tool history instead of another body copy
The broker's skill.read result contains identity, name, version and loaded=True. A source comment explains the intention to keep bodies in currently enabled context rather than old worker results. The read remains auditable without making historical results another permanent source of instruction text.
This does not prove a model completely forgets material it has already seen. Log lifetime and conversation retention are separate concerns. What this code controls is the material reassembled for delivery and the shape of that result. The article describes the specific result that omits bodies, avoiding a broader and unsupported promise of memory deletion.
Distinguish current management metadata from the old body path
Current external MCP skills management projects identity, name, description, usage, version, source and enabled state; it omits instructions. Context identifies external control and distinguishes it from an installed or enabled embedded CLI. That evidence does not support describing the old automatic skill-selection model as running inside the current browser.
Existing tests check that a synthetic instruction body is absent from the catalog, available through an allowed read and inaccessible through malformed paths or definitions. This task read those functions and tests without running an original model. It does not claim a newly verified end-to-end body-selection experience for every external caller.
Keep the needed explanation available for a fresh read
Selective reading is not about hiding necessary information. Begin with a selection clue, read the current body and version, and make rereading possible when it changes. Writing, research and recovery guidance belong at different moments and scopes; clear connections are more useful than attaching the same long instructions to every operation.
The shared module is not a skill-context manager implementing this whole story. It isolates preference state and automatic registration respecting choices. I wanted to distinguish increasing available knowledge from increasing material delivered on every step. Designing lifetime and version together helps prevent an old explanation from appearing to be today's judgment.