autoskill（auto 技能）

This skill analyzes coding sessions to extract durable preferences from corrections and approvals, then proposes targeted updates to Skills that were active during the session. It acts as a learning mechanism across sessions, ensuring Claude improves based on feedback.

The user triggers autoskill after a session where Skills were used. The skill detects signals, filters for quality, maps them to the relevant Skill files, and proposes minimal, reversible edits for review.

Session scope

By default, analyze only the current session (from SessionStart to now). This ensures fresh, relevant feedback without noise from old sessions.

To analyze patterns across multiple sessions, user must explicitly request: "analyze my last 5 sessions" or "look for patterns across this week".

When to activate

Trigger on explicit requests:

• "autoskill", "learn from this session", "update skills from these corrections"
• "remember this pattern", "make sure you do X next time"

Do NOT activate for one-off corrections or when the user declines skill modifications.

Where to apply changes

Distinguish between skill-specific behavior and project-wide conventions:

Update Skills when:

• Signal relates to how a specific skill should behave
• Preference affects skill trigger conditions or outputs
• Pattern is about the skill's decision-making process

Update CLAUDE.md when:

• Project-wide conventions (naming, file structure, architecture)
• Tool/library preferences that span multiple skills
• Team style preferences (spacing, comments, error handling)
• Domain-specific terminology used across the codebase

Example:

• "Don't add error handling for internal functions" → code-simplifier skill (how to simplify)
• "We use cn() utility for className merging" → CLAUDE.md (project convention)
• "Auth logic lives in middleware, not components" → CLAUDE.md (architecture decision)

Signal detection

Scan the session for:

Corrections (highest value)

• "No, use X instead of Y"
• "We always do it this way"
• "Don't do X in this codebase"

Repeated patterns (high value)

• Same feedback given 2+ times
• Consistent naming/structure choices across multiple files

Approvals (supporting evidence)

• "Yes, that's right"
• "Perfect, keep doing it this way"

Ignore:

• Context-specific one-offs ("use X here" without "always")
• Ambiguous feedback

Conflict resolution

When signals contradict each other, resolve using this priority order:

1. Recency: More recent signals override older ones (current session > past sessions)
2. Explicitness: Direct corrections ("No, do X instead") outweigh approvals ("looks good")
3. Repetition: Patterns repeated 3+ times outweigh single corrections
4. Confidence scoring:

- Explicit correction with "always/never": 5 points - Repeated pattern (2+ occurrences): 3 points - Single correction: 2 points - Approval/confirmation: 1 point

If contradictory signals have equal scores, ask user for clarification before proposing changes.

Example conflict:

• Session 1: "Add error handling everywhere" (2 points)
• Session 3 (current): "Don't add error handling for internal functions" (5 points - explicit + "don't")
• Resolution: Use current session's explicit rule

Signal quality filter

Before proposing any change, ask:

1. Was this correction repeated, or stated as a general rule?
2. Would this apply to future sessions, or just this task?
3. Is it specific enough to be actionable?
4. Is this new information I wouldn't already know?

Only propose changes that pass all four.

What counts as "new information"

Worth capturing:

• Project-specific conventions ("we use cn() not clsx() here")
• Custom component/utility locations ("buttons are in @/components/ui")
• Team preferences that differ from defaults ("we prefer explicit returns")
• Domain-specific terminology or patterns
• Non-obvious architectural decisions ("auth logic lives in middleware, not components")
• Integrations and API quirks specific to this stack

NOT worth capturing (I already know this):

• General best practices (DRY, separation of concerns)
• Language/framework conventions (React hooks rules, TypeScript basics)
• Common library usage (standard Tailwind classes, typical Next.js patterns)
• Universal security practices (input validation, SQL injection prevention)
• Standard accessibility guidelines

If I'd give the same advice to any project, it doesn't belong in a skill.

Mapping signals to Skills

Match each signal to the Skill that was active and relevant during the session:

Update existing Skill when:

• Signal relates to a Skill that was used in the session
• Total confidence score for that Skill ≥ 3 points
• Signal affects how the skill should behave or trigger

Propose new Skill when:

• Multiple related signals (total score ≥ 5 points) don't fit any active Skill
• Pattern spans multiple sessions with consistent behavior
• Signals describe a reusable, well-defined capability

Update CLAUDE.md instead when:

• Signals describe project conventions, not skill behavior
• Total score < 5 points for new skill creation
• Pattern is too specific to one context

Ignore signals when:

• Don't map to any Skill used in the session
• Total confidence score < 2 points
• Contradict existing, well-established patterns without strong justification

Scoring example:

• 2 explicit corrections about error handling (2×2=4 points) → Update code-simplifier
• 1 approval + 1 pattern about naming (1+3=4 points) → Needs one more signal or higher confidence
• 3 corrections about auth flow (3×2=6 points) → Could propose new auth-specialist skill

Proposing changes

For each proposed edit, provide:

File: path/to/SKILL.md
Section: [existing section or "new section: X"]
Confidence: HIGH | MEDIUM
Score: [confidence points]

Signal: "[exact user quote or paraphrase]"

Current text (if modifying):
> existing content

Proposed text:
> updated content

Rationale: [one sentence]

Group proposals by file. Present HIGH confidence changes first.

Concrete example

Session context: User corrected error handling twice during code-simplifier usage

Detected signals:

1. "Don't add try-catch blocks for internal functions" (explicit correction: 5 points)
2. Removed error handling from internal utility functions (pattern: 3 points)
3. Total: 8 points → HIGH confidence

Proposed change:

File: plugins/essentials/skills/code-simplifier/SKILL.md
Section: ## When NOT to simplify
Confidence: HIGH
Score: 8 points (5 + 3)

Signal: "Don't add try-catch blocks for internal functions" + pattern of removing such blocks

Current text:
> - Don't add error handling, fallbacks, or validation for scenarios that can't happen

Proposed text:
> - Don't add error handling, fallbacks, or validation for scenarios that can't happen
> - Don't add try-catch blocks for internal functions that are called by trusted code

Rationale: User explicitly corrected this twice; it's a specific, actionable rule for this project

Review flow

Always present changes for review before applying. Format:

## autoskill summary

Detected [N] durable preferences from this session.

### HIGH confidence (recommended to apply)
- [change 1] - Score: X points
- [change 2] - Score: X points

### MEDIUM confidence (review carefully)
- [change 3] - Score: X points

Apply high confidence changes? [y/n/selective]

Wait for explicit approval before editing any file.

Processing order when multiple updates needed

When proposing changes to multiple files:

1. Process HIGH confidence first (score ≥ 7 points)
2. Group by file to minimize context switches
3. Flag potential conflicts between proposed changes
4. CLAUDE.md updates before Skill updates (project context first)
5. Skill updates in order of usage frequency (most-used skills first)

Example order:

1. CLAUDE.md: Add cn() utility convention (HIGH, 8 points)
2. code-simplifier: Error handling rule (HIGH, 8 points)
3. code-simplifier: Variable naming pattern (MEDIUM, 4 points)
4. typescript-pro: Type annotation preference (MEDIUM, 5 points)

Applying changes

When approved:

1. Edit the target file with minimal, focused changes
2. If git is available, commit with message: chore(autoskill): [brief description]
3. Report what was changed

Rollback guidance

All autoskill changes are reversible:

If git is available:

1. Find commit: git log --grep="autoskill" --oneline
2. Revert specific commit: git revert <commit-hash>
3. Or revert all autoskill changes: git log --grep="autoskill" --format="%H" | xargs -n1 git revert

Manual rollback:

1. Each edit is minimal and focused (easy to identify)
2. Use git diff to see exact changes: git show <commit-hash>
3. Manually undo the specific section that caused issues

Prevention:

• Always commit each skill change separately (never batch)
• Use descriptive commit messages: chore(autoskill): add error handling rule to code-simplifier
• Test after each change before proceeding to next

When to ask for clarification

Use the AskUserQuestion tool when:

Ambiguous signals:

• Correction doesn't clearly specify what to do instead
• Pattern observed but unclear if intentional or coincidental
• Signal could apply to multiple skills

Contradictory feedback:

• Equal confidence scores for contradicting signals
• User's recent correction conflicts with established pattern
• Unclear which rule should take precedence

Boundary decisions:

• Uncertain whether change belongs in CLAUDE.md or Skill
• Score is near threshold (4-6 points for new skill creation)
• Signal could be project-wide convention OR skill-specific behavior

Scope uncertainty:

• Unclear if correction applies to all cases or specific context
• Signal mentions "here" or "this case" without "always/never"
• Need to verify if pattern should be generalized

Example questions:

"I detected two corrections about error handling:
1. 'Don't add try-catch for internal functions'
2. 'Always validate user input'

These seem contradictory. Should I:
- Add both rules with specific contexts?
- Apply different rules to internal vs external code?
- Something else?"

Never guess or assume - when in doubt, downgrade to MEDIUM confidence and ask.

Constraints

• Never delete existing rules without explicit instruction
• Prefer additive changes over rewrites
• One concept per change (easy to revert)
• Preserve existing file structure and tone
• When uncertain, downgrade to MEDIUM confidence and ask