Load the user's skills via Core dependencies instead of per-request auto-sharing

[andrii-novikov]

QuickApps version

latest

What is the problem this feature will solve?

A user's skill only exists for the agent if the user invoked it. Chat puts the picked skill in custom_content.skills, Core auto-shares that resource to the per-request key, and QuickApps resolves it for that request (#549). Skills the user has but did not pick are invisible.

So as a user I:

• can't ask for my own skill in plain words. "Use my review checklist" cannot work: nothing with that name is in the agent's skill list, and only the picker can put it there.
• can't rely on the agent choosing a skill for me. The model picks skills by description all the time — but only from the agent's own. Mine are never candidates unless I already knew which one I wanted.
• lose the whole conversation when a share is revoked. Because the URL rides on every turn, Core rejects every later turn with 403 once a skill shared with me is unshared (a known gap of Invoke user skills from a chat message (phase 1) #549).

DIAL Core is adding a way for an app to reach the user's own skills as a dependency. That replaces the per-request auto-share as the way skills arrive.

What is the feature you are proposing to solve the problem?

Consume Core's dependency interface so the agent has the user's skill catalogue, and list all of it.

Expected behaviour

• The agent knows the user's skills whether or not any was invoked: each is listed for the model with its name and description, alongside the agent's own.
• Because they are listed, the user can ask for one in plain words, and the model can pick one by description — the same path the agent's own skills already use.
• Bundled reference files of any listed user skill are readable through read_skill, as they are for an invoked one.
• Access is exactly the user's own reach: their skills, the ones shared with them, and published ones — nothing more, and it follows a revoked share without breaking the conversation.
• What the listing costs in prompt budget stays bounded for a user with many skills.
• A user with no skills, and a deployment where the dependency is absent, behave exactly as today.
• Still a preview feature.

To decide in the design doc

1. What bounds the listing? SKILL_INVOCATION_MAX_SKILLS (default 10) caps invoked skills. Listing a whole catalogue needs its own answer for the user with fifty skills — a cap, a relevance rule, or listing lazily.
2. Does custom_content.skills stay the wire contract for "invoked on this message"? Loading stops depending on the auto-share, but Chat still has to say which skills the user picked. If the field stays, confirm whether the dependency path also removes the 403-on-revoked-share gap, or whether that needs a Core fix of its own.
3. When is the catalogue fetched, and how often? Today every invoked skill is re-resolved on every turn. A whole catalogue per turn is a different load profile for Core.

Dependencies

• DIAL Core: the dependency interface for an app to reach the user's skills. To be filed / linked in epam/ai-dial-core.
• Resolve skill name collisions across predefined, app and user skills #568: name collisions must be resolved first. Listing every user skill next to the agent's makes a shared manifest name ordinary rather than a deliberate clashing pick.

Builds on: #549 (closed). Related: #567 (invoking several skills from one message), #550 (invoking the app's own skills).

What alternatives have you considered?

• Keep per-request auto-sharing and treat the picker as the only way in: the current state. Leaves the agent blind to everything the user did not explicitly pick, so plain-words invocation stays impossible.
• Autoload every user skill's full manifest into the prompt rather than name and description: predictable, and blows the context budget for anyone with a real skill library.
• Have the user attach their skills to the app config: works only for an app they own, and applies the skill to every user of that app.