feat(claude): Add Agent Skills to JJ workflow plugin

Refactor JJ plugin to use hybrid Skills + slash commands architecture for better autonomous behavior:

**New Skills (model-invoked):**
1. Working with Jujutsu Version Control
   - Core jj concepts (change-based, automatic snapshotting, stack-based)
   - Working copy state management (@, @-, ancestors)
   - Plan-driven workflow guidance
   - When to suggest jj commands vs slash commands

2. Curating Jujutsu Commits
   - Pattern recognition for splits (test/docs/config mixed with code)
   - WIP and fixup commit detection
   - When to suggest /jj:split vs /jj:squash
   - File type pattern matching

3. Generating JJ Commit Messages
   - Conventional commit format (type, scope, description)
   - Project-specific style matching
   - Plan-to-reality conversion
   - Auto-generation from file patterns

**Plugin Updates:**
- Created skills/ directory with 3 SKILL.md files
- Updated plugin.json: added "skills": "./skills/", bumped to v0.2.0
- Updated README.md: documented Skills feature and Skills vs Slash Commands

**Architecture:**
- Skills: Claude autonomously activates based on context
- Slash commands: User explicitly invokes (/jj:commit, /jj:split, etc.)
- Hooks: Unchanged, continue providing automatic behaviors

**Benefits:**
- Proactive commit curation suggestions
- Better commit message generation
- Autonomous jj workflow understanding
- Maintained explicit user control via slash commands

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

Author: edmundmiller

config/claude/plugins/jj-workflow-plugin/.claude-plugin/plugin.json

@@ -1,13 +1,14 @@
 {
   "name": "jj",
-  "version": "0.1.0",
+  "version": "0.2.0",
   "description": "Autonomous commit stacking and curation workflow for Jujutsu (jj) version control",
   "author": {
     "name": "emiller"
   },
   "keywords": ["jujutsu", "jj", "version-control", "workflow", "commit-stacking"],
   "license": "MIT",
   "commands": "./commands/",
+  "skills": "./skills/",
   "hooks": {
     "UserPromptSubmit": [
       {

config/claude/plugins/jj-workflow-plugin/README.md

@@ -1,10 +1,11 @@
 # Jujutsu Workflow Plugin
 
-Autonomous commit stacking and curation workflow for Jujutsu (jj) version control. This plugin provides Claude Code with specialized commands for managing commits in a jj repository using a stack-based workflow.
+Autonomous commit stacking and curation workflow for Jujutsu (jj) version control. This plugin provides Claude Code with specialized commands, Skills, and hooks for managing commits in a jj repository using a stack-based workflow.
 
 **Features:**
 
-- **Commit stacking** - `/jj:commit`, `/jj:split`, `/jj:squash`, `/jj:cleanup`
+- **Slash Commands** - `/jj:commit`, `/jj:split`, `/jj:squash`, `/jj:cleanup` for explicit user actions
+- **Agent Skills** - Autonomous JJ workflow understanding, commit curation, and message generation
 - **Git translation** - Automatic hook to suggest jj equivalents and block git commands
 - **Plan-driven workflow** - Automatic commit planning and validation hooks
 - **Auto-formatting** - Runs `jj fix` after edits to format code automatically
@@ -150,6 +151,74 @@ The plugin supports a plan-driven workflow where Claude commits intent BEFORE wo
 - **Everything undoable** - Operation log makes everything reversible
 - **Clean history** - Curate before pushing, work however you want locally
 
+## Agent Skills
+
+This plugin includes three Agent Skills that Claude autonomously uses to understand and work with jj workflows. Skills are **model-invoked** - Claude automatically activates them based on context, unlike slash commands which require explicit user invocation.
+
+### Working with Jujutsu Version Control
+
+**When activated:** When user mentions commits, changes, version control, or working with jj repositories.
+
+**What it provides:**
+- Core jj concepts and mental model (change-based, automatic snapshotting, stack-based workflow)
+- Working copy state management (`@`, `@-`, ancestors)
+- Plan-driven workflow guidance
+- When to suggest jj commands vs slash commands
+- Git-to-JJ translation knowledge
+- Best practices for jj workflows
+
+**Example:** User says "I need to commit these changes" → Claude understands jj workflow, suggests `/jj:commit`, explains plan-driven approach if applicable.
+
+### Curating Jujutsu Commits
+
+**When activated:** When working with multiple commits, WIP changes, or preparing work for sharing.
+
+**What it provides:**
+- Pattern recognition for split opportunities (tests+code, docs+code, config+code)
+- WIP and fixup commit detection
+- When to suggest `/jj:split` vs `/jj:squash`
+- File type pattern matching (test, docs, config)
+- Curation workflow guidance
+- Avoiding over-curation
+
+**Example:** User makes changes mixing test files and implementation → Claude suggests: "Your changes mix tests and implementation. Consider: `/jj:split test`"
+
+### Generating JJ Commit Messages
+
+**When activated:** When creating commits, describing changes, or when user asks for commit message help.
+
+**What it provides:**
+- Conventional commit format (type, scope, description)
+- Project-specific commit style matching
+- Plan-to-reality pattern for plan-driven workflow
+- Message writing guidelines (imperative mood, specificity, what/why)
+- Auto-generation from file patterns
+- Length and formatting best practices
+
+**Example:** User runs `/jj:commit` without message → Claude analyzes changes, generates: "feat(auth): implement JWT-based authentication"
+
+### Skills vs Slash Commands
+
+**Skills (model-invoked):**
+- Claude automatically uses when relevant
+- Provide knowledge and understanding
+- Guide workflow decisions
+- Suggest appropriate commands
+
+**Slash Commands (user-invoked):**
+- User explicitly types `/jj:commit`, `/jj:split`, etc.
+- Execute specific actions
+- Provide consistent interface
+- Work whether Skills active or not
+
+**Example workflow:**
+1. User: "I added login and some tests"
+2. **Skill activates:** Claude understands mixed changes
+3. **Skill suggests:** `/jj:split test` to separate concerns
+4. User: `/jj:split test`
+5. **Command executes:** Splits tests into separate commit
+6. **Skill activates:** Claude generates commit messages for both commits
+
 ## Integration
 
 ### Automatic Snapshotting

config/claude/plugins/jj-workflow-plugin/skills/commit-curation/SKILL.md

@@ -0,0 +1,291 @@
+---
+name: Curating Jujutsu Commits
+description: Help curate and organize commits in jujutsu repositories. Use when working with multiple commits, WIP changes, or preparing work for sharing. Suggests when to split, squash, or reorganize commits based on change patterns.
+---
+
+# Curating Jujutsu Commits
+
+## Purpose
+
+Help organize commits into clean, reviewable, atomic units before sharing. This Skill provides guidance on when and how to curate commits in a jujutsu repository.
+
+## When to Curate
+
+**Good times to suggest curation:**
+- Before sharing work (PR, pushing to remote)
+- After completing a feature with multiple incremental commits
+- When commits mix unrelated concerns
+- When you notice WIP, fixup, or temporary commits
+
+**Don't suggest curation when:**
+- Changes are simple and focused
+- Single commit addresses one concern
+- Work is still in early exploration
+- User explicitly wants incremental history
+
+## Split Pattern Recognition
+
+Suggest `/jj:split <pattern>` when commits mix concerns:
+
+### Test Files Mixed with Implementation
+
+**Pattern:** Changes include both source code and test files
+
+**Indicators:**
+- Files matching: `*test*.{py,js,ts}`, `*spec*.{py,js,ts}`, `test_*.py`, `*Test.java`
+- Mixed with implementation in same commit
+
+**Suggestion:**
+```
+Your changes include both implementation and tests. Consider splitting:
+/jj:split test
+```
+
+**Why:** Tests and implementation are easier to review separately
+
+### Documentation Mixed with Code
+
+**Pattern:** Changes include both code and documentation
+
+**Indicators:**
+- Files matching: `*.md`, `README*`, `CHANGELOG*`, `docs/**/*`
+- Mixed with code changes
+
+**Suggestion:**
+```
+Your changes mix code and documentation. Consider splitting:
+/jj:split docs
+```
+
+**Why:** Documentation and code changes reviewed by different people/processes
+
+### Configuration Mixed with Features
+
+**Pattern:** Changes include both config and feature code
+
+**Indicators:**
+- Files matching: `*.json`, `*.yaml`, `*.toml`, `*.ini`, `.env*`, `*config*`
+- Mixed with feature implementation
+
+**Suggestion:**
+```
+Your changes include configuration updates. Consider splitting:
+/jj:split config
+```
+
+**Why:** Config changes often need separate security/ops review
+
+### File Type Patterns
+
+**Common split patterns:**
+- `test` → Test and spec files
+- `docs` → Documentation (*.md, README, CHANGELOG)
+- `config` → Config files (*.json, *.yaml, *.toml)
+- `*.{ext}` → Specific file types
+- Custom glob patterns
+
+## Squash Pattern Recognition
+
+Suggest `/jj:squash` when commits should be combined:
+
+### Multiple WIP Commits
+
+**Pattern:** Sequential commits with WIP, fixup, or similar messages
+
+**Indicators:**
+- Messages like "WIP", "wip", "fixup", "temp", "checkpoint"
+- Multiple commits for same logical change
+- Sequential commits touching same files
+
+**Suggestion:**
+```
+You have multiple WIP commits for the same feature. Consider squashing:
+/jj:squash
+```
+
+**Why:** Clean up incremental work into cohesive commits
+
+### Fixup Commits
+
+**Pattern:** Later commits fix earlier commits
+
+**Indicators:**
+- Messages like "fix typo", "fix tests", "fix formatting"
+- Touching same files as recent commit
+- Small changes that belong with earlier work
+
+**Suggestion:**
+```
+This looks like a fixup for your previous commit. Consider squashing:
+/jj:squash
+```
+
+**Why:** Fixes should be part of original commit in shared history
+
+### Related Small Changes
+
+**Pattern:** Multiple small commits that logically belong together
+
+**Indicators:**
+- Same feature/scope in multiple commits
+- Commits from same work session
+- Would be clearer as single commit
+
+**Suggestion:**
+```
+These commits are closely related. Consider combining:
+/jj:squash
+```
+
+**Why:** Atomic commits easier to review and understand
+
+## Curation Workflow
+
+**Typical curation sequence:**
+
+1. **Review current stack:**
+   ```bash
+   jj log
+   ```
+
+2. **Identify mixed concerns** → Use `/jj:split <pattern>`
+
+3. **Identify WIP commits** → Use `/jj:squash`
+
+4. **Verify result:**
+   ```bash
+   jj log
+   jj diff -r <commit>
+   ```
+
+5. **Update descriptions if needed** → Use `/jj:commit` or `jj describe`
+
+## Examples
+
+### Example 1: Mixed Test and Implementation
+
+**Before:**
+```
+@ abc123: Add login feature and tests
+  - src/auth/login.py       (new)
+  - src/auth/test_login.py  (new)
+  - src/auth/config.yaml    (new)
+```
+
+**Suggest:**
+```
+Your commit mixes implementation, tests, and config. Consider:
+
+1. /jj:split test        # Separate tests
+2. /jj:split config      # Separate config
+
+Result: Three focused commits
+```
+
+### Example 2: WIP Commits
+
+**Before:**
+```
+@ abc123: WIP: fix validation
+@ def456: WIP: add validation
+@ ghi789: Add user form
+```
+
+**Suggest:**
+```
+You have two WIP commits for validation. Consider:
+
+jj edit def456           # Edit the first validation commit
+/jj:squash               # Squash abc123 into def456
+
+Result: Clean commit history
+```
+
+### Example 3: Documentation Update
+
+**Before:**
+```
+@ abc123: Implement OAuth and update README
+  - src/oauth.py    (new)
+  - README.md       (modified)
+  - docs/oauth.md   (new)
+```
+
+**Suggest:**
+```
+Your commit mixes OAuth implementation and documentation. Consider:
+
+/jj:split docs
+
+Result:
+- Commit 1: Implement OAuth (code only)
+- Commit 2: Document OAuth (docs only)
+```
+
+## Change Pattern Analysis
+
+**Analyzing current changes:**
+```bash
+jj status                    # See what's changed
+jj diff                      # Review changes
+jj log -r 'ancestors(@, 5)'  # View recent stack
+```
+
+**Questions to ask:**
+1. Do changes serve multiple purposes?
+2. Could parts be reviewed separately?
+3. Do file types suggest natural splits?
+4. Are there WIP or fixup commits?
+5. Would this be easier to understand as multiple commits?
+
+## Avoiding Over-Curation
+
+**Don't suggest curation when:**
+
+- **Single purpose changes**: All files work toward one goal
+- **Tightly coupled changes**: Splitting would break logical cohesion
+- **Already atomic**: Commit is focused and clear
+- **Early exploration**: User is still figuring things out
+
+**Examples of good single commits:**
+- "Refactor authentication module" (all auth files together)
+- "Add user profile page" (template + route + tests together)
+- "Fix memory leak in data processor" (investigation + fix together)
+
+## Integration with TodoWrite
+
+When user has TodoWrite todos:
+
+**Pattern:** One commit per major todo completion
+
+**Workflow:**
+1. Complete todo
+2. Use `/jj:commit` to describe work
+3. `jj new` for next todo
+4. Repeat
+
+**Don't suggest splitting** if commits align with todo structure (already organized)
+
+## Best Practices
+
+**Do:**
+- Suggest curation before sharing work
+- Recognize common file patterns (test, docs, config)
+- Explain why splitting helps review
+- Provide specific `/jj:split` or `/jj:squash` commands
+
+**Don't:**
+- Over-curate working commits
+- Split tightly coupled changes
+- Suggest curation during active development
+- Make curation feel mandatory
+
+## When This Skill Activates
+
+Use this Skill when:
+- User has multiple commits to organize
+- Changes mix different file types or concerns
+- User mentions preparing work for PR/sharing
+- WIP or fixup commits are present
+- User asks about organizing commits
+- Before suggesting pushing or creating PRs