Skip to content

feat: extend unified chat completion request with custom skills #1955 - #1956

Merged
astsiapanay merged 3 commits into
developmentfrom
feat/issue-1955
Sep 11, 2026
Merged

astsiapanay merged 3 commits into
developmentfrom
feat/issue-1955

Conversation

@astsiapanay

Copy link
Copy Markdown
Collaborator

Adds messages[*].custom_content.skills[*] to the unified chat completion request so a caller can reference an existing Skill resource per-request, the same way custom_content.attachments[*] already lets a caller reference a file. Referenced skills are auto-shared to the invoked deployment into the existing ApiKeyData.attachedSkills bucket, the same one Application-config-declared skills already use.

Applicable issues

Description of changes

  • RequestObject — new collectSkills() default method (no-op for the Anthropic Messages / OpenAI Responses adapters, which are out of scope).
  • ChatCompletionRequest — overrides collectSkills() to scan $.messages[*].custom_content.skills[*].
  • ChatUtil — new collectCustomSkills/readCustomSkill, throwing 400 on a missing/blank url (per current code-style guidance for new code, rather than silently skipping like the legacy attachment parser).
  • CollectRequestSkillsFn (new) — resolves each URL, rejects non-SKILL resource types with 400, skips public skills, and otherwise checks AccessService.hasReadAccess, sharing into attachedSkills or throwing 403.
  • DeploymentPostController — wires CollectRequestSkillsFn into the request enhancement chain alongside the existing attachment collector.
  • docs/open_api_core.yaml — new RequestSkill schema; skills array added to both user and assistant message custom content schemas.
  • Tests: ChatCompletionRequestTest (collection), CollectRequestSkillsFnTest (readable/public/denied/wrong-type/absolute-URL branches), and three new DeploymentPostControllerTest cases exercising the full handleRequestBody chain (auto-shared, 403, 400).

Checklist

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Adds messages[*].custom_content.skills[*] so callers can reference
existing Skill resources per-request, auto-shared into ApiKeyData.attachedSkills
the same way file attachments already are.
Oleksii-Klimov
Oleksii-Klimov previously approved these changes Sep 10, 2026
docs/open_api_core.yaml is a generated+merged artifact: schemas without a
real Java DTO are sourced from hand-authored fragments under
openapi-generator/src/main/resources/schemas/, and SpecMerger deletes any
top-level schema in the manual doc that isn't backed by one. The RequestSkill
schema added directly to docs/open_api_core.yaml was being dropped as
orphaned, breaking `./gradlew replaceSpec -Plint`. Add the RequestSkill
fragment and reference it from the two CustomContent fragments instead, then
regenerate the doc through the real pipeline.
@ai-dial-actions

This comment has been minimized.

@astsiapanay

astsiapanay commented Sep 10, 2026

Copy link
Copy Markdown
Collaborator Author

/deploy-review

GitHub actions run: 34491608585

Stage Status
deploy-review Success ✅
chat Success ✅

@ai-dial-actions

Copy link
Copy Markdown
Contributor

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None

@astsiapanay
astsiapanay merged commit 8668cf6 into development Sep 11, 2026
9 checks passed
@astsiapanay
astsiapanay deleted the feat/issue-1955 branch September 11, 2026 07:56
andrii-novikov added a commit to epam/ai-dial-quickapps-backend that referenced this pull request Sep 14, 2026
A skill reaches a QuickApp agent only if the app author attached it and the
model decides to call read_skill — the user has no deterministic way to say
"use this skill for this message", and no way in at all for skills from their
own catalog.

This design specifies how QuickApps consumes the custom_content.skills wire
contract agreed with DIAL Core (epam/ai-dial-core#1956): resolve each picked
skill through DialSkillResolver, register it under a collision-free
user:<name>:<hash> id, and inject a synthetic read_skill call and result after
the user message so the manifest is in context before the model's turn.

Phase 1 covers the user's own skills; picking the agent's own skills is
deferred to #550.

Claude-Session: https://claude.ai/code/session_0184dFYXFuKAjivbVvNxL2fa
andrii-novikov added a commit to epam/ai-dial-quickapps-backend that referenced this pull request Sep 14, 2026
A skill reaches a QuickApp agent only if the app author attached it and the
model decides to call read_skill — the user has no deterministic way to say
"use this skill for this message", and no way in at all for skills from their
own catalog.

This design specifies how QuickApps consumes the custom_content.skills wire
contract agreed with DIAL Core (epam/ai-dial-core#1956): resolve each picked
skill through DialSkillResolver, register it under a collision-free
user:<name>:<hash> id, and inject a synthetic read_skill call and result after
the user message so the manifest is in context before the model's turn.

Phase 1 covers the user's own skills; picking the agent's own skills is
deferred to #550.

Claude-Session: https://claude.ai/code/session_0184dFYXFuKAjivbVvNxL2fa
andrii-novikov added a commit to epam/ai-dial-quickapps-backend that referenced this pull request Sep 14, 2026
A skill reaches a QuickApp agent only if the app author attached it and the
model decides to call read_skill — the user has no deterministic way to say
"use this skill for this message", and no way in at all for skills from their
own catalog.

This design specifies how QuickApps consumes the custom_content.skills wire
contract agreed with DIAL Core (epam/ai-dial-core#1956): resolve each picked
skill through DialSkillResolver, register it under a collision-free
user:<name>:<hash> id, and inject a synthetic read_skill call and result after
the user message so the manifest is in context before the model's turn.

Phase 1 covers the user's own skills; picking the agent's own skills is
deferred to #550.

Claude-Session: https://claude.ai/code/session_0184dFYXFuKAjivbVvNxL2fa
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Extend unified chat completion request with custom skills (messages[*].custom_content.skills[*])

3 participants