anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 02:05:26 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

[PR #6000] feat(skill): add per-agent filtering to skill tool description #11694

New Issue
Closed
opened 2026-02-16 18:16:37 -05:00 by yindo · 0 comments
yindo commented 2026-02-16 18:16:37 -05:00
Owner
Copy Link
Copy Source

Original Pull Request: https://github.com/anomalyco/opencode/pull/6000

State: closed
Merged: Yes

Summary

Implements per-agent skill filtering in the <available_skills> tool description, completing the feature originally proposed in #5930.

After #5930 was merged, the maintainer simplified it by removing per-agent filtering from the tool description (permissions were only checked at execution time). This PR adds the infrastructure to pass agent context to tool initialization, enabling the skill tool to filter its description based on agent permissions.

Problem

Without this change, agents see ALL skills in <available_skills>, including ones they can't use (permission = deny). This leads to:

  • Wasted tokens listing inaccessible skills
  • Agent confusion when it tries to load a denied skill
  • Poor UX when certain skills should be hidden from certain agents

Solution

Pass agent context through the tool initialization chain so the skill tool can filter <available_skills> by permissions.

Changes

Infrastructure (tool.ts, registry.ts, prompt.ts)

  • Add InitContext interface with optional agent field to Tool namespace
  • Update Tool.Info.init signature to accept (ctx?: InitContext)
  • Update ToolRegistry.tools() to accept optional agent and pass it to each tool's init()
  • Pass agent from SessionPrompt.resolveTools() to ToolRegistry.tools()

Skill Tool (tool/skill.ts)

  • Rewrite using explicit Tool.Info<typeof parameters> typing
  • Filter accessibleSkills by agent permissions in init(ctx)
  • Only skills where Wildcard.all(skill.name, permissions) !== "deny" appear in <available_skills>

Skill Registry (skill/skill.ts)

  • Add duplicate skill name detection with warning log

Behavior

With config:

{
  "permission": {
    "skill": {
      "documents-*": "deny",
      "experimental-*": "ask",
      "*": "allow"
    }
  }
}
Skill In <available_skills>? On Execute
documents-* ❌ Hidden Rejected
experimental-* ✅ Shown Prompts user
Others ✅ Shown Loads immediately

Agent-specific overrides work as expected:

# In agent frontmatter
permission:
  skill:
    "documents-*": "allow"  # This agent CAN see and use documents-* skills

Testing

  • ✅ bun run typecheck passes
  • ✅ bun test passes (320 pass, 1 skip)
  • ✅ Manually tested with multiple agents and permission patterns
  • Backwards compatible: existing tools without init(ctx) usage are unaffected
**Original Pull Request:** https://github.com/anomalyco/opencode/pull/6000 **State:** closed **Merged:** Yes --- ## Summary Implements per-agent skill filtering in the `<available_skills>` tool description, completing the feature originally proposed in #5930. After #5930 was merged, the maintainer simplified it by removing per-agent filtering from the tool description (permissions were only checked at execution time). This PR adds the infrastructure to pass agent context to tool initialization, enabling the skill tool to filter its description based on agent permissions. ## Problem Without this change, agents see ALL skills in `<available_skills>`, including ones they can't use (permission = `deny`). This leads to: - Wasted tokens listing inaccessible skills - Agent confusion when it tries to load a denied skill - Poor UX when certain skills should be hidden from certain agents ## Solution Pass agent context through the tool initialization chain so the skill tool can filter `<available_skills>` by permissions. ## Changes ### Infrastructure (`tool.ts`, `registry.ts`, `prompt.ts`) - Add `InitContext` interface with optional `agent` field to `Tool` namespace - Update `Tool.Info.init` signature to accept `(ctx?: InitContext)` - Update `ToolRegistry.tools()` to accept optional agent and pass it to each tool's `init()` - Pass agent from `SessionPrompt.resolveTools()` to `ToolRegistry.tools()` ### Skill Tool (`tool/skill.ts`) - Rewrite using explicit `Tool.Info<typeof parameters>` typing - Filter `accessibleSkills` by agent permissions in `init(ctx)` - Only skills where `Wildcard.all(skill.name, permissions) !== "deny"` appear in `<available_skills>` ### Skill Registry (`skill/skill.ts`) - Add duplicate skill name detection with warning log ## Behavior With config: ```json { "permission": { "skill": { "documents-*": "deny", "experimental-*": "ask", "*": "allow" } } } ``` | Skill | In `<available_skills>`? | On Execute | |-------|-------------------------|------------| | `documents-*` | ❌ Hidden | Rejected | | `experimental-*` | ✅ Shown | Prompts user | | Others | ✅ Shown | Loads immediately | Agent-specific overrides work as expected: ```yaml # In agent frontmatter permission: skill: "documents-*": "allow" # This agent CAN see and use documents-* skills ``` ## Testing - ✅ `bun run typecheck` passes - ✅ `bun test` passes (320 pass, 1 skip) - ✅ Manually tested with multiple agents and permission patterns - Backwards compatible: existing tools without `init(ctx)` usage are unaffected
yindo added the pull-request label 2026-02-16 18:16:37 -05:00
yindo closed this issue 2026-02-16 18:16:38 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#11694
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?