Skills Auto-Activation via Hooks (Does It Solve the Problem?)

After I published Claude Skills: The Controllability Problem, a reader pointed me to an interesting community solution: using hooks to auto-activate skills based on file patterns.

The approach comes from Code Pulse’s Medium article and their GitHub showcase repo. It’s clever automation. But does it solve the core controllability problem?

How It Works

The solution uses Claude Code’s hooks system to trigger skill activation based on context:

Define activation rules

In skill-rules.json:

{
  "backend-dev-guidelines": {
    "fileTriggers": {
      "pathPatterns": ["src/**/*.ts", "backend/**/*.ts"]
    }
  }
}

Install a hook

That runs on every prompt submission:

{
  "hooks": {
    "UserPromptSubmit": [{
      "type": "command",
      "command": ".claude/hooks/skill-activation-prompt.sh"
    }]
  }
}

The hook checks context

When you submit a prompt, the script reads your open files, matches them against the rules, and suggests the relevant skill.

Example: You open src/api/users.ts and type “refactor this endpoint”. The hook detects the .ts file in src/, checks the rules, and prompts Claude with: “Looks like you’re editing /src/api/users.ts - load backend-dev-guidelines skill?”

What It Solves (And What It Doesn’t)

The hooks approach addresses a real frustration: skills that sit dormant because Claude doesn’t realize they’re relevant. You’ve written comprehensive guidelines, but Claude doesn’t activate them because your prompt didn’t semantically match. Hooks fix this with file-based triggers: working in src/api/**? Backend guidelines load automatically.

The hooks approach solves the right problem for context selection but leaves gaps for workflow control.

What works well:

• Domain-specific guidelines load automatically: Working in src/api/**? Backend patterns load. In src/components/**? Frontend guidelines appear. Context matches your location.
• Deterministic file-based triggers: Unlike pure semantic matching, file paths give you predictable rules. You know which skills are candidates when you open a file.
• Progressive disclosure: Skills load based on relevance, not dumped in CLAUDE.md upfront. Better signal-to-noise ratio.

Where explicit controls still matter:

• Can’t force-invoke when rules don’t match: Planning phase with no files open? Hooks won’t fire. You need architectural analysis but there’s no file path trigger.
• Can’t prevent when rules do match: Quick typo fix in src/api/auth.ts? Hook triggers backend-dev-guidelines (10k tokens). You didn’t need it, but the rule matched.
• No session overrides: Can’t say “skip skills this session” or “only use this specific skill right now” when you know the context better than the rules.

Semantic triggering works for context selection. Explicit controls matter for workflow orchestration. The hooks solution improves the former but doesn’t replace the need for the latter.

— The distinction

What We Actually Need

The hooks approach works well for its use case (context/tool selection), but product-level features would improve both patterns:

For semantic context selection (where Skills + hooks work):

• Invocation logging: Show which skills activated, why, and at what token cost
• Conditional logic as first-class config: Define activation rules in .claude/config.json instead of maintaining shell scripts
• Session overrides: “Skip skills this session” when you know you don’t need them

For workflow orchestration (where explicit controls matter):

• Explicit invocation: claude --skill=analysis to force a skill when rules don’t match
• Disable flags: --disable-skill=web-search to prevent specific skills for a session
• Sequencing guarantees: Declare “run these skills in this order” for multi-step workflows

The distinction matters: hooks solve the context selection problem, but Claude Code still needs explicit controls for workflow orchestration. Both patterns have legitimate use cases.

The Pragmatic Take

For context/tool selection, hooks + skills are the right pattern. Large codebase with domain boundaries (monorepo, microservices, feature areas)? Backend guidelines for src/api/**, frontend patterns for src/components/**, database skills per environment? This is exactly what semantic triggering with file-based rules solves.

The real win: conditional context loading. Instead of dumping everything in CLAUDE.md or letting skills sit dormant, hooks let you say “only load this 10k token skill when working in these directories”. Team onboarding improves (guidelines load automatically), context stays lean (progressive disclosure), and token usage drops.

Setup effort is minimal:

• Drop in the hook scripts (chmod +x)
• Define your rules in skill-rules.json
• Update .claude/settings.json to wire up the hooks

For workflow orchestration, slash commands remain the better choice. Multi-step processes (build → test → deploy), explicit sequencing (analyze → refactor → review), or guaranteed invocation when you know better than the rules? You need explicit controls, not semantic matching.

The patterns complement each other:

• Skills + hooks: Context selection (which guidelines? which tools?)
• Slash commands: Workflow execution (run this now, in this order)

Try It If You’re Curious

Credit to Code Pulse for documenting this pattern and sharing the showcase repo. If you’re struggling with dormant skills and your codebase maps cleanly to directories, their approach is worth trying.

The key insight: match the pattern to the problem. Context selection (which guidelines? which tools?) benefits from semantic triggering. Workflow orchestration (do this, then that) needs explicit controls. Hooks solve the former. We still need product features for the latter.

The right tool for the right problem. Semantic triggering for context selection, explicit controls for workflow orchestration. Both have their place.