A saved procedure is useful only when it is selected for the right request. Correct steps do not establish that those steps belong in today's work. In Northstar I separated a registered plugin from its skill guidance to address those two questions. This is about the information kept beside a procedure, rather than another tour of its program files.
The entry points to a target; guidance explains selection
TaskPluginService registers a programId in current preferences. It can attach a label, description and usage text, but its receipt says executed=False. TaskSkillService instead describes when to choose the procedure, which inputs to inspect and what to read after a failure. Its read method contains no program-start call. These are different contracts even when both refer to one procedure.
Combining them would make an explanation interaction resemble execution, or mix operational judgment into a code change. I kept the execution entry and selection guidance as separate material. Improving a paragraph does not improve the program's verification status, and successfully running a procedure does not prove that every future request should select it. The distinction makes both changes easier to review.
Automatically retain reuse guidance rather than this input text
rememberProgram looks for a companion through basedOnProgram and reuses an existing definition. A new companion describes the steps and how to inspect parameter keys. It says not to substitute saved defaults or earlier conversation values for a new request, and to verify an original outcome rather than resending completed actions. The useful memory is a method of reuse, not permission to repeat an old action.
An existing test places a synthetic private sentinel in recipe parameters and checks that generated instructions omit it. That narrow test does not certify that every label or metadata field is anonymous. Names, sites and step descriptions still need review. This publication retains the design judgment while omitting actual work text, customer identifiers and original operating inputs.
Rediscovery must not reactivate deliberately disabled guidance
Finding the same program again should not create another companion each time. An existing test disables the skill and invokes rememberProgram again; it expects the same identity and version with enabled=False. Reuse assistance should not repeatedly undo a user's explicit decision to stop using that guidance.
A plugin's enabled preference and a skill's selection switch are different records. Whether an execution capability is available and whether its explanation belongs in current context are separate decisions. A disabled explanation is not a missing program or damaged code. That distinction also affects management copy: users need to know which switch they are changing instead of seeing one vague enabled label for unrelated states.
Usage guidance does not enlarge execution permission
Guidance gives priority to the current human request and destination. An enabled writing skill must not redirect work on another service into a familiar blog. Nor may a request to prepare files silently become public publication. Instructions can explain tool choice and verification order, but cannot grant new authorization.
This matters more as the library grows. A previously authorized procedure may contain uploads or public actions that today's request does not include. Similar names are not enough to replay everything. The companion therefore directs the caller to inspect the current procedure and supply current inputs before choosing it. Reusable judgment narrows uncertainty; it should not broaden what the user asked to happen.
Separate historical automatic judgment from the current connection
Early documentation describes an embedded CLI/model choosing and reading skills. That path was later removed, so I do not describe the same model as still making decisions inside today's browser. The evidence here is the surviving guidance storage, project selection and read functions, compared with execution registration.
Existing tests also check selected-body access, exclusion of another profile's custom definition and rejection of malformed definitions. This content task did not run the original application or invoke a model. Source inspection and historical test design support one level of claim; actually executing the independent synthetic module supports another. Keeping those levels visible prevents a useful design story from becoming a false live-service report.
A custom program needs an operational handover as well
A tailored feature is difficult to maintain if only its button remains. The handover should explain starting material, stopping conditions and evidence of completion. That does not require embedding every long instruction in execution code. Preserve the link between target procedure and selection guidance, and record why each changes.
The linked module isolates registration and preference state from this design; it is neither a skill authoring service nor a real runner. I want the next operator to discover a capability with enough context to avoid pressing it blindly. Reusability includes the responsibility to reread the present request, rather than treating a saved method as a permanent order.