[FEATURE] Auto-mode classifier should see loaded Skill/SKILL.md content, not just CLAUDE.md

Status Open
Maintainer reply None cached
Activity 0 comments · opened Aug 11, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

Auto mode's classifier reads CLAUDE.md and conversation messages when scoring a pending action, but not the content of skills loaded via the Skill tool. Skill content lands in the transcript as a tool result, and per the documented design, result content isn't part of what the classifier ingests:

The classifier reads the conversation rather than command output

Anyone who has moved custom-instruction content out of CLAUDE.md into topic-scoped Skills (encouraged for context-window reasons) gets a blind spot: a hard rule that lives only in a skill is invisible to the classifier even while the model is following it correctly in the same turn.

Proposed Solution

Have the classifier ingest the content of any Skill currently loaded into context and/or recieve the output of the Skill tool, the same way it reads CLAUDE.md, so a custom instruction moved from CLAUDE.md into a Skill for context-budget reasons doesn't silently lose classifier enforcement.

At minimum, document the gap explicitly in auto-mode-config/permission-modes, next to the existing "boundaries you state in conversation" section, so people don't assume a skill-scoped rule carries the same enforcement weight as a CLAUDE.md line.

Alternative Solutions

Current workarounds: keep the hard rule in CLAUDE.md instead of a skill (defeats the point of splitting instructions into skills for context-budget reasons), or use permissions.deny, which blocks before the classifier is consulted but needs a tool-pattern rule rather than prose and can't express nuance a skill's written rule could (e.g. "exec is fine locally, never remote").

Priority

Medium - Would be very helpful

Feature Category

Other

Use Case Example

A personal Kubernetes skill might state: "kubectl exec is only for local containers, never remote UAT/prod pods." The model loads the skill, agrees to the rule, then is asked to debug a failing UAT pod. Since the target isn't a prod-named namespace, it doesn't trip the built-in "sensitive remote target" soft-deny. The classifier, which never saw the skill's rule, scores an interactive kubectl exec as in-line with the user's stated intent to debug, and approves it. The only prevention is the model declining despite classifier approval, which isn't guaranteed over a long or compacted conversation.

Additional Context

Related: #79558 (classifier reads conversation context, documents the Bash-only coverage gap), #74080 (classifier blind to parent-turn intent inside forked skills, different angle same root cause), #77988 (hook for instruction files incl. SKILL.md, different mechanism, adjacent goal).

View original on GitHub ↗