[FEATURE] Per-skill effortLevel in skill frontmatter

Resolved 💬 3 comments Opened Mar 17, 2026 by sstraus Closed Mar 21, 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

Skills can declare model: in frontmatter to control which model executes them, but there is no equivalent for effort level. When a skill activates in the main conversation (not a subagent), it inherits the session's current effort level — typically medium on Opus 4.6.

Some skills perform work that genuinely benefits from high reasoning effort (architectural analysis, multi-step planning, cross-referencing specifications), while others are mechanical workflows (file scaffolding, running CLI commands, generating boilerplate). Today there is no way for a skill author to signal that their skill needs deeper reasoning — the user must manually say "ultrathink" or run /effort high before invoking the skill.

This is different from #31536 (per-subagent effort), which was closed because subagents don't use extended thinking. Skills execute in the main conversation context where extended thinking is fully active. The effort level directly affects thinking depth.

Proposed Solution

Add an effortLevel field to skill frontmatter:

---
name: plan
description: Transform feature descriptions into research-backed implementation plans.
model: opus
effortLevel: high
---

When CC activates a skill with effortLevel declared, it overrides the session effort level for that skill's execution, then restores the previous level afterward.

Accepted values: low, medium, high, max, inherit (default — current behavior).

Alternative Solutions

  • "ultrathink" in SKILL.md body: Does not work — CC only detects "ultrathink" in the user's direct prompt, not in skill instructions loaded into context.
  • CLAUDE_CODE_EFFORT_LEVEL env var from a hook: Does not work — the env var is read once at startup, and hooks run in child processes that cannot modify the parent's environment.
  • User runs /effort high before skill: Works but requires manual intervention and user awareness. Skill authors cannot guarantee their skill runs at the effort level it was designed for.
  • effortLevel in settings.json: Applies globally to all turns — too expensive (3x token cost) for skills that only need high effort occasionally.

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Use Case Example

A plugin skill that plans implementation of user stories. The planning phase requires cross-referencing codebase patterns, analyzing dependencies, and designing the approach — work that produces measurably better results at high effort. The same user session also runs mechanical skills (file scaffolding, git operations) that work fine at medium. Today, the user must remember to say "ultrathink" before /plan every time, or accept degraded planning quality.

Additional Context

The infrastructure likely exists: model: in skill frontmatter already overrides the session model. effortLevel: would follow the same pattern — skill-scoped override with automatic restore. The ultrathink keyword detection in user prompts proves CC already has the ability to temporarily raise effort for a single turn; this feature would let skill authors declare that need declaratively.

Related (closed, different scope): #31536 — per-subagent effort (closed because subagents lack thinking blocks; does not apply to skills in the main conversation).

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗