docs/design/daemon-skill-batch-toggle.md
Remote Skill managers can toggle only one Skill per request. Closing several Skills therefore requires client-side request orchestration and provides no single response that records all target outcomes.
Add collection-level mutation routes:
POST /workspace/skills/enablePOST /workspaces/:workspace/skills/enableThe request body is:
{
"skillNames": ["review", "deploy", "missing"],
"enabled": false
}
skillNames is a non-empty string array with at most 100 entries. Names are
trimmed and deduplicated case-insensitively while preserving first-seen order.
The response is best-effort for expected target errors: valid targets are
validated against one status snapshot, persisted in one locked write, and
applied with one live-session refresh. Unknown, hidden, inactive-extension,
and locked targets are returned without blocking the valid targets. Unexpected
persistence and runtime-generation failures fail the whole request.
{
"enabled": false,
"activation": "applied",
"sessionsRefreshed": 2,
"sessionsFailed": 0,
"results": [
{
"skillName": "review",
"enabled": false,
"changed": true
},
{
"skillName": "deploy",
"enabled": false,
"changed": true
}
],
"errors": [
{
"skillName": "missing",
"code": "skill_not_found",
"error": "Skill not found: missing"
}
]
}
results and errors each preserve request order within their own array;
the response does not reconstruct the original mixed ordering, so clients
re-match targets by skillName.
Malformed requests still fail as a whole with HTTP 400. Workspace trust, authentication, client identity, and generation ownership use the same gates as the single-Skill route.
Advertise workspace_skill_batch_toggle separately from
workspace_skill_toggle. Clients must pre-flight the new capability before
calling the collection route. The existing single-Skill route and response
remain unchanged. The collection routes are HTTP-only: the ACP
_qwen/workspace/skills dispatch surface stays read-only, matching the
single-Skill toggle.