Feature: Skill usage analytics and statistics

Feature Request

Problem

When using custom skills in Claude Code, there's no way to track:

• Which skills are being used and how often
• Whether skills are effective (success/failure rates)
• What triggers skill invocations (slash command, auto-detection, user request)
• How long skills take to execute
• Which skills might need improvement or deprecation

This makes it difficult to evaluate the value of custom skills and improve them over time.

Proposed Solution

1. Automatic Usage Logging

Log skill invocations to ~/.claude/analytics/skill-usage.jsonl:

{
  "timestamp": "2026-01-26T10:30:00Z",
  "skill": "ui-testing",
  "version": "1.2.0",
  "trigger": "slash_command",
  "project": "/path/to/project",
  "duration_sec": 180,
  "outcome": "completed"
}

2. CLI Command for Statistics

claude --skill-stats

# Output:
Skill Usage Statistics (last 30 days)
=====================================
ui-testing       │ 12 invocations │ 92% success │ avg 3.2 min
claudeception    │ 8 invocations  │ 100% success │ avg 0.5 min
commit           │ 45 invocations │ 98% success │ avg 0.2 min

Top triggers:
- Slash command: 65%
- Auto-detection: 25%  
- User request: 10%

3. Optional Detailed View

claude --skill-stats ui-testing --detailed

# Shows:
- Invocation timeline
- Common contexts (file types, project types)
- Failure reasons
- Average duration trend

Implementation Ideas

1. Logging: Hook into skill invocation to log start/end times and outcomes
2. Outcome detection: Infer success/failure from:

• Skill explicitly reporting completion
• No immediate retry or correction from user
• Follow-up message sentiment (optional/advanced)

1. Storage: Simple JSONL file, rotated monthly
2. Privacy: All local, no telemetry; user can disable with --no-skill-analytics

Additional Context

• Skills can come from global (~/.claude/skills/) or project (.claude/skills/) locations
• Version info available in skill YAML frontmatter
• Could integrate with proposed skill update notifications (#20969)

Alternatives Considered

• Hook-based DIY logging: Possible but fragile and requires manual setup
• Skill self-reporting: Adds boilerplate to every skill
• External analytics tool: Over-engineered for this use case

Native support would be cleaner and more reliable.