-
Notifications
You must be signed in to change notification settings - Fork 2
plat 248
github-actions[bot] edited this page Sep 20, 2026
·
1 revision
| Coordination | Value |
|---|---|
| Assigned agent | Unassigned |
| Ticket state | fixed |
| Last synchronized | 2026-08-29 |
- Priority: runtime contract, severity high.
-
Evidence: The
jobsearchworkflow hasbrowser_mode: auto. Its retainedscan-linkedin-feed-for-job-postssession receivedagent_browser, but its attached skill set omittedagent-browser;read_skillconsequently returnedattached skill "agent-browser" not found.
Browser capability and browser guidance were configured independently. Enabling
the managed browser registered agent_browser, but runtime skill attachment
used only the manually selected workflow/step skill names. A browser-capable
agent could therefore be instructed to load the product-owned browser skill
while the same session made that skill unavailable.
This is a platform defect, not a workflow configuration error. A built-in skill that defines the safe use of a managed tool is part of that tool's capability; users should not need to select it again on every Builder or execution step.
- Added one shared capability helper that appends the built-in
agent-browserskill when—and only when—the agent has managed browser capability. - Applied it to direct/Builder identity assembly and workflow execution-agent identity assembly.
- Execution uses the registered tool list as the final authority, so an actual
agent_browsergrant cannot drift from the attached skill even if older server-name metadata is incomplete. - Explicit selection is deduplicated, and persisted workflow configuration is not mutated.
- Skill-loader tests cover implicit attachment, explicit deduplication, disabled-browser behavior, and input immutability.
- Workflow-agent and server test suites pass.
Auto-synced from docs/ on main. Edit there, not here.