[MODEL] Installed project skills and subagents are not loaded; work is done inline at large token cost

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

Preflight

  • [x] Searched existing model-labelled issues. Closest matches are #37885 (closed, different model, hallucination-focused) and #89244 (open, asymmetric rule binding). Neither covers skill/subagent harness bypass or its cost consequence.
  • [x] This report contains no sensitive information. It also deliberately contains no conversation transcript, source code, diffs, or project/ticket/host/person identifiers — the reporter has declined to share task data, and this is written to be actionable without it.

Type of Behavior Issue

Claude ignored my instructions or configuration

What You Asked Claude to Do

Complete a multi-step engineering task in a repository that installs a substantial agent harness: a router table in the project instruction file mapping task types to skills, ~40 task-specific skills, and ~17 purpose-built subagent definitions. The project instruction file states explicitly that the main thread should orchestrate and delegate heavy work (reads, searches, implementation, review) to subagents, and names the skill that owns each category of task.

What Claude Actually Did

Performed the work inline in the main context instead of loading the skill or dispatching the subagent that exists for that exact task. The harness was present, indexed and described; it was simply not used.

  1. A skill that owns a specific repetitive maintenance operation went unloaded across several units of work consisting almost entirely of that operation. The operation was hand-rolled each time.
  2. Broad repository sweeps and inventories — which a dedicated read-only explorer subagent is defined to perform and return conclusions from — were run instead as long sequences of shell commands in the main context, pulling full command output into the primary window rather than a short summary.
  3. The skills that were invoked were mostly lightweight procedural ones. The skills that would have absorbed the bulk of the token cost were the ones skipped — the inverse of a useful selection. If the failure were random, a mix would be expected.
  4. After being told directly to use the harness, Claude complied for the immediately following action and then resumed inline work as the task shifted. When later asked to author a hand-off prompt for a fresh session, it had to be told twice to express that prompt in terms of the installed skills and subagents rather than generic steps.

The bypass also produced worse output, not just a higher bill. The skill owning the hand-rolled operation encodes explicit guidance about a specific error class. Doing the operation by hand reproduced that exact error class four times in one session, each occurrence requiring rework. The skill's accumulated knowledge was inert because the skill was never loaded. So the cost was tokens, plus rework, plus reviewer time.

Expected Behavior

  1. When a task matches a skill the project declares as owning that operation, load the skill rather than improvising a method.
  2. Dispatch the defined read-only subagent for broad searches and inventories, so the main context receives conclusions instead of raw command output.
  3. Re-evaluate skill/subagent routing when the kind of work changes mid-session, not only at session start.
  4. Treat performing a skill-owned operation by hand as a violation to flag, not a free choice, when the project states that expectation.

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Sometimes (intermittent)

Steps to Reproduce

Not reduced to a minimal repro. The reporter states they have observed this pattern across multiple devices, so it is not a single-session anomaly. Suggested shape for reproduction:

  1. Use a project whose instruction file declares a router table mapping task types to skills, and which instructs the main thread to delegate heavy work to named subagents.
  2. Give Claude a long multi-step task that shifts between activity types (e.g. implement, then repetitive mechanical maintenance, then review).
  3. Observe whether the skill owning the mechanical phase is ever loaded, and whether broad searches are delegated to the read-only explorer subagent or run inline.

Claude Model

Opus

Impact

Medium - Extra work to undo changes

Recording the cost dimension explicitly, since no dropdown option captures it: the token consumption is a direct, unreimbursed financial cost to the user, and it concentrates in exactly the repetitive work the harness was built to make cheap — because that work is both high-volume and the easiest to start doing by hand.

Claude Code Version

2.1.243 (Claude Code)

Platform

Anthropic API

Additional Context

Hypotheses for triage, offered as hypotheses and not findings:

  • Skill and subagent descriptions appear to be consulted when selecting an approach at the start of a task, but not re-consulted when the kind of work changes mid-task. A session that begins as one activity and drifts into another does not seem to re-run the routing decision, so the second activity is handled by whatever method is already in hand.
  • A bias toward immediate action competes with delegation. Loading a skill or dispatching a subagent is an extra step before visible progress; running a shell command is progress now. Where guidance says both "act rather than deliberate" and "delegate heavy work", the former appears to win — especially when each individual instance of the work looks small.
  • The cost of the bypass is invisible at the decision point. Each hand-rolled step is individually cheap; the multiple exists only in aggregate, and nothing surfaces the running total at the moment the choice is made.
  • Reinforcement is asymmetric: inline work yields output immediately, while delegating yields a wait and then a summary.

Suggestions:

  • Re-evaluate routing at task-type transitions within a session.
  • Make repetition visible — an nth hand-rolled instance of the same mechanical operation is a strong signal that a skill should have been loaded.
  • Surface accumulated session cost where the per-step decision is made.

Anyone triaging who needs specifics should ask the reporter rather than assume they are recoverable from this report.

View original on GitHub ↗