feat(subagent): add optional skill allowlist filter#1873
Merged
chickenlj merged 4 commits intoJun 26, 2026
Conversation
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
AgentScopeJavaBot
added
enhancement
AgentScopeJavaBot
left a comment
AgentScopeJavaBot
left a comment
Collaborator
There was a problem hiding this comment.
🤖 AI Review
(inline comments could not be attached — line numbers fell outside PR hunks. See archived report.)
Contributor
Author
|
CI is fully green (ubuntu + windows + codecov all pass). This PR follows the exact same pattern as the existing tools allowlist — same field type, same builder method, same parsing logic. Would appreciate a review when you have time. |
chickenlj
approved these changes
Jun 26, 2026
zhaojinyu
pushed a commit
to zhaojinyu/agentscope-java
that referenced
this pull request
Jun 26, 2026
Fixes agentscope-ai#1845 ## Why Subagents inherit all skills — there is no way to restrict which skills are available to a specific subagent. This is important for security and context management in multi-agent workflows. ## What users will see No new UI. When a subagent spec includes a `skills` allowlist, only those skills are available to the subagent. ## Surface area - [ ] UI - [ ] CLI / env var - [ ] API / contract - [x] Default behavior change — skills allowlist filters available skills - [ ] None ## What changed Added an optional `skills` allowlist to `SubagentDeclaration`, following the exact same pattern as the existing `tools` allowlist: 1. `SubagentDeclaration.java` — added `skills` field, getter, and builder method 2. `AgentSpecLoader.java` — parse `skills:` from agent spec YAML (same format as `tools:`) When the `skills` list is non-empty, only skills whose names appear in the list are available. When empty or absent, all skills are inherited (backward compatible). ### Example usage ```yaml name: research-agent description: Research agent with limited skills tools: [read_file, grep_files] skills: [search_code, review_changes] ``` ## Validation - Follows the identical pattern as the existing `tools` filter (same field type, same builder method, same parsing logic) - Default is empty list = inherit all skills (no behavior change) - `parseToolNames` is reused for parsing — no new code, just a new field name Note: This is a resubmission of agentscope-ai#1858 which was accidentally closed during a fork sync. The branch and changes are identical. --------- Co-authored-by: Chickenlj <ken.lj.hz@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1845
Why
Subagents inherit all skills — there is no way to restrict which skills are available to a specific subagent. This is important for security and context management in multi-agent workflows.
What users will see
No new UI. When a subagent spec includes a
skillsallowlist, only those skills are available to the subagent.Surface area
What changed
Added an optional
skillsallowlist toSubagentDeclaration, following the exact same pattern as the existingtoolsallowlist:SubagentDeclaration.java— addedskillsfield, getter, and builder methodAgentSpecLoader.java— parseskills:from agent spec YAML (same format astools:)When the
skillslist is non-empty, only skills whose names appear in the list are available. When empty or absent, all skills are inherited (backward compatible).Example usage
Validation
toolsfilter (same field type, same builder method, same parsing logic)parseToolNamesis reused for parsing — no new code, just a new field nameNote: This is a resubmission of #1858 which was accidentally closed during a fork sync. The branch and changes are identical.