diff --git a/skills/code-exploration/SKILL.md b/skills/code-exploration/SKILL.md
new file mode 100644
index 0000000..d546cb9
--- /dev/null
+++ b/skills/code-exploration/SKILL.md
@@ -0,0 +1,73 @@
+---
+name: code-exploration
+description: Navigate and understand unfamiliar codebases to locate relevant code. Use when you need to find files, methods, or classes related to a bug or feature, search for error messages, or understand code structure before making changes.
+---
+
+# Code Exploration
+
+Systematically explore a codebase to find relevant files and understand the code structure.
+
+## Finding Related Files
+
+Use targeted search strategies to locate relevant code:
+
+### 1. Grep for Keywords
+
+Search for relevant identifiers:
+```bash
+grep -r "method_name" .
+grep -r "ClassName" .
+grep -r "error message text" .
+```
+
+**Search for:**
+- Method names mentioned in the issue
+- Class names
+- Error messages
+- Keywords from the problem description
+- File names or paths mentioned
+
+### 2. Identify All Related Files
+
+Create a comprehensive list:
+- Files containing the methods/classes mentioned
+- Test files for those components
+- Configuration files that might affect behavior
+- Documentation files explaining the feature
+
+### 3. Analyze Code Structure
+
+For each relevant file:
+- Read the implementation
+- Understand dependencies and imports
+- Note related methods and classes
+- Identify potential fix locations
+
+## Proposing Fix Locations
+
+### 1. List Candidate Locations
+
+Propose specific files and methods where the fix might belong:
+- Primary location (most likely)
+- Secondary locations (less likely but possible)
+- Related areas that might need updates
+
+### 2. Explain Your Reasoning
+
+For each candidate location:
+- Why this location is relevant
+- What code would need to change
+- How it connects to the issue
+- Potential side effects
+
+### 3. Select the Most Likely Location
+
+Based on your analysis, choose the primary fix location and explain why it's the best choice.
+
+## Best Practices
+
+- Use `grep` with appropriate flags (`-r` for recursive, `-i` for case-insensitive)
+- Search the entire codebase, not just obvious locations
+- Look at test files to understand expected behavior
+- Check recent commits that touched related code (`git log --follow <file>`)
+- Consider both direct and indirect relationships
diff --git a/skills/code-implementation/SKILL.md b/skills/code-implementation/SKILL.md
new file mode 100644
index 0000000..29824ff
--- /dev/null
+++ b/skills/code-implementation/SKILL.md
@@ -0,0 +1,85 @@
+---
+name: code-implementation
+description: Implement code changes with focus and discipline. Use when making the actual code edits to fix a bug or implement a feature. Emphasizes minimal changes, focused modifications, and clean implementation.
+---
+
+# Code Implementation
+
+Implement code changes with precision and minimal scope.
+
+## Principles
+
+### 1. Minimal Changes
+
+Make the smallest possible change that fixes the issue:
+- Don't refactor unrelated code
+- Don't fix other bugs you notice
+- Don't add extra features
+- Focus solely on the issue at hand
+
+### 2. Focused Modifications
+
+Edit only the files necessary for the fix:
+- Primary fix location
+- Related code that must change to support the fix
+- Tests (if required by project)
+
+### 3. Clean Implementation
+
+Write code that matches the project's style:
+- Follow existing code conventions
+- Match indentation and formatting
+- Use similar patterns to surrounding code
+- Add comments only where needed
+
+## Implementation Process
+
+### 1. Open the Target File
+
+Navigate to the exact location identified in your analysis:
+```bash
+# View the file first
+cat -n path/to/file.py
+
+# Then edit
+# Use your file editing tools
+```
+
+### 2. Make the Change
+
+Implement the fix according to your plan:
+- Follow the solution approach from fix analysis
+- Make surgical edits to the specific lines
+- Don't modify more than necessary
+
+### 3. Verify Syntax
+
+Check that your changes are syntactically correct:
+- For Python: `python -m py_compile file.py`
+- For other languages: use appropriate syntax checkers
+- Ensure no import errors or typos
+
+## Example
+
+**Before:**
+```python
+def parse_date(date_string):
+    return datetime.strptime(date_string, "%m/%d/%Y")
+```
+
+**After (minimal fix):**
+```python
+def parse_date(date_string):
+    try:
+        return datetime.strptime(date_string, "%m/%d/%Y")
+    except ValueError:
+        return datetime.fromisoformat(date_string)
+```
+
+## What NOT to Do
+
+- ❌ Don't refactor unrelated code "while you're at it"
+- ❌ Don't fix additional bugs you notice
+- ❌ Don't add extra error handling beyond what's needed
+- ❌ Don't change formatting of untouched code
+- ❌ Don't add features not mentioned in the issue
diff --git a/skills/code-issue-analysis/SKILL.md b/skills/code-issue-analysis/SKILL.md
new file mode 100644
index 0000000..fbe7687
--- /dev/null
+++ b/skills/code-issue-analysis/SKILL.md
@@ -0,0 +1,64 @@
+---
+name: code-issue-analysis
+description: Analyze bug reports and feature requests to understand code issues. Use when starting work on a bug fix or feature implementation to parse issue descriptions, identify technical details, extract requirements, and clarify the problem statement. Essential first step before making code changes.
+---
+
+# Code Issue Analysis
+
+Systematically analyze bug reports and feature requests to extract actionable requirements and technical details.
+
+## Reading and Clarifying the Problem
+
+When presented with an issue description, follow this structured analysis:
+
+### 1. Extract Code and Config Snippets
+
+If the issue contains code or configuration examples:
+- Identify coding conventions and best practices demonstrated
+- Note file structures and naming patterns
+- Recognize configuration patterns and standards
+
+### 2. Identify Technical Details
+
+Highlight and document:
+- **Error messages**: Exact text of exceptions, warnings, or error output
+- **Method names**: Functions, classes, or methods mentioned
+- **Variable names**: Specific identifiers referenced
+- **File names**: Paths and filenames involved
+- **Stack traces**: Full stack trace information if provided
+- **Technical keywords**: Domain-specific terminology
+
+### 3. Clarify the Problem Statement
+
+Rewrite the issue in clear, unambiguous terms:
+- What is the current behavior?
+- What is the expected behavior?
+- What is the gap between them?
+- Under what conditions does the issue occur?
+
+### 4. Extract Reproduction Steps
+
+Document the sequence to reproduce the issue:
+1. Preconditions (environment, data, configuration)
+2. Actions to take
+3. Expected outcome
+4. Actual outcome
+
+If reproduction steps aren't explicit, infer them from the description.
+
+### 5. Identify Testing and Fix Considerations
+
+Note any best practices mentioned for:
+- How to test the issue
+- Requirements for a valid fix
+- Backward compatibility needs
+- Edge cases to consider
+- Performance implications
+
+## Output
+
+Produce a clear analysis containing:
+- **Problem summary**: One-paragraph clear statement
+- **Technical details**: Bulleted list of methods, files, errors
+- **Reproduction steps**: Numbered sequence
+- **Testing requirements**: Constraints and considerations for validation
diff --git a/skills/code-verification/SKILL.md b/skills/code-verification/SKILL.md
new file mode 100644
index 0000000..be34dd7
--- /dev/null
+++ b/skills/code-verification/SKILL.md
@@ -0,0 +1,103 @@
+---
+name: code-verification
+description: Verify code changes work correctly and don't break existing functionality. Use after implementing changes to test the fix, run related tests, and ensure no regressions. Critical final step before submitting changes.
+---
+
+# Code Verification
+
+Thoroughly test your implementation to ensure correctness and no regressions.
+
+## Verification Steps
+
+### 1. Run Your Reproduction Script
+
+First, verify your fix solves the original problem:
+```bash
+python reproduce_issue.py
+```
+
+**Expected outcome**: The script should now pass or show correct behavior.
+
+If it still fails:
+- Review your implementation
+- Check if you edited the right location
+- Verify your changes are syntactically correct
+- Debug the issue further
+
+### 2. Test Edge Cases
+
+Extend your reproduction script with additional test cases:
+- Boundary conditions
+- Null/empty inputs
+- Unusual but valid inputs
+- Previously working cases (regression check)
+
+**Example:**
+```python
+# Test original functionality still works
+assert parse_date("12/25/2023") == expected_date_1
+
+# Test new functionality
+assert parse_date("2023-12-25") == expected_date_2
+
+# Test edge cases
+assert parse_date("2023-12-25T00:00:00") == expected_date_3
+```
+
+### 3. Run Existing Tests
+
+Run the repository's test suite for related code:
+
+```bash
+# Run all tests
+pytest
+
+# Or run specific test file
+pytest tests/test_date_parser.py
+
+# Or run tests for specific function
+pytest -k test_parse_date
+```
+
+**What to check:**
+- Tests for the function you modified
+- Tests for functions that call your function
+- Integration tests that use your component
+
+### 4. Fix Any Test Failures
+
+If tests fail:
+1. Read the failure message carefully
+2. Understand what the test expects
+3. Determine if:
+   - Your fix broke valid functionality (fix your code)
+   - The test expectations are outdated (understand why before changing)
+   - The test itself has issues (rare)
+
+### 5. Verify No Regressions
+
+Ensure existing functionality still works:
+- Run the full test suite if possible
+- Manually test related features
+- Check that your changes don't affect unrelated code paths
+
+## Final Verification Checklist
+
+Before considering the work complete:
+
+- [ ] Reproduction script passes
+- [ ] Edge cases handled
+- [ ] Related tests pass
+- [ ] No new test failures introduced
+- [ ] Manual testing of affected functionality
+- [ ] Code review of your changes (self-review)
+- [ ] Verify minimal scope (didn't change too much)
+
+## If Tests Keep Failing
+
+Debug systematically:
+1. Add print statements to understand execution flow
+2. Check if you're testing the right code (imports, paths)
+3. Verify test environment is set up correctly
+4. Re-read the issue requirements
+5. Consider if your solution approach needs adjustment
diff --git a/skills/fix-analysis/SKILL.md b/skills/fix-analysis/SKILL.md
new file mode 100644
index 0000000..df76675
--- /dev/null
+++ b/skills/fix-analysis/SKILL.md
@@ -0,0 +1,73 @@
+---
+name: fix-analysis
+description: Analyze and plan code fixes before implementation. Use after understanding the issue and exploring the code to articulate the problem clearly, identify the root cause, and plan the solution approach. Bridges analysis and implementation.
+---
+
+# Fix Analysis
+
+Clearly articulate the problem and solution before writing code.
+
+## State the Problem Clearly
+
+### 1. What is the Problem?
+
+Write a concise statement:
+- Current behavior (what happens now)
+- Expected behavior (what should happen)
+- Root cause (why the problem occurs)
+
+**Example:**
+"The `parse_date()` function fails when given dates in ISO 8601 format because it only handles MM/DD/YYYY format. This causes ValueError exceptions when processing international data."
+
+### 2. Where is the Problem Located?
+
+Specify exact locations:
+- File: `src/utils/date_parser.py`
+- Function/Class: `parse_date()` function
+- Line numbers: Lines 45-52
+
+### 3. How Does the Test Reproduce It?
+
+Explain how your reproduction script demonstrates the issue:
+- What inputs trigger the problem
+- What the script does
+- What output shows the bug
+
+## Plan the Fix
+
+### 1. Consider Best Practices
+
+Before implementing, consider:
+- **Backward compatibility**: Will this break existing code?
+- **Edge cases**: What unusual inputs should be handled?
+- **Performance**: Will this impact speed or memory?
+- **Testing**: How will we verify this works?
+- **Code style**: Does it match project conventions?
+
+### 2. Describe the Solution
+
+Explain how you'll fix the problem:
+- What code will change
+- What new logic or conditions are needed
+- How this addresses the root cause
+- Why this approach is best
+
+**Example:**
+"Add support for ISO 8601 format by using the `dateutil.parser` library, which handles multiple date formats. Keep existing MM/DD/YYYY support for backward compatibility. Add format detection logic to try ISO 8601 first, then fall back to the original parser."
+
+### 3. Identify Side Effects
+
+Consider what else might be affected:
+- Other functions that call this code
+- Tests that might break
+- Documentation that needs updates
+- Related functionality that might need similar fixes
+
+## Output
+
+Produce a clear fix plan containing:
+- Problem statement (1-2 sentences)
+- Exact location (file, function, lines)
+- Solution approach (paragraph)
+- Implementation steps (bulleted list)
+- Testing strategy (how to verify)
diff --git a/skills/prompt-refactor/SKILL.md b/skills/prompt-refactor/SKILL.md
new file mode 100644
index 0000000..3fef60e
--- /dev/null
+++ b/skills/prompt-refactor/SKILL.md
@@ -0,0 +1,193 @@
+---
+name: prompt-refactor
+description: Decompose monolithic prompts into modular, reusable skills. Use this skill when you need to refactor a large prompt template into a skills-based architecture, analyze prompt structure, or convert phase-based instructions into independent skill modules. Ideal for improving prompt maintainability and reusability.
+---
+
+# Prompt Refactor
+
+Decompose monolithic prompts into modular, reusable skills for better maintainability and reusability.
+
+## When to Use This Skill
+
+Use this skill when you need to:
+- Convert a monolithic prompt into skills-based architecture
+- Analyze a prompt's structure and identify factorizable components
+- Create modular, reusable skill modules from phase-based instructions
+- Refactor benchmark prompts or evaluation templates
+
+## Workflow
+
+### Step 1: Analyze the Prompt Structure
+
+First, understand the prompt's organization and identify distinct phases or workflows.
+
+**Run the analysis script:**
+
+```bash
+python3 scripts/analyze_prompt.py <path_to_prompt_file>
+```
+
+This will identify:
+- Distinct phases or sections
+- Workflow patterns
+- Suggested skill decomposition
+
+**Manual analysis (if script doesn't work):**
+
+Look for:
+- Numbered phases or steps (e.g., "Phase 1. READING:", "Step 2: Analysis")
+- Section headers (## Headers)
+- Distinct responsibilities or concerns
+- Sequential workflows
+- Reusable patterns
+
+### Step 2: Identify Skill Boundaries
+
+Group related instructions into cohesive skills based on:
+
+**Single Responsibility**: Each skill should have one clear purpose
+- ✅ Good: "code-issue-analysis" - analyzes bug reports
+- ❌ Bad: "analyze-and-fix" - mixes analysis and implementation
+
+**Reusability**: Skills that could be useful beyond this specific prompt
+- ✅ High reusability: "test-creation", "code-exploration"
+- ⚠️ Medium reusability: "swebench-verification" (domain-specific but reusable)
+- ❌ Low reusability: Single-use, context-specific instructions
+
+**Independence**: Skills should minimize dependencies on other skills
+- ✅ Independent: Can be used standalone
+- ⚠️ Weak dependency: References another skill optionally
+- ❌ Strong dependency: Cannot function without another skill
+
+### Step 3: Design Each Skill
+
+For each identified skill, plan:
+
+**1. Frontmatter (metadata)**
+- `name`: Concise, descriptive identifier (lowercase-with-dashes)
+- `description`: What it does AND when to use it (this is crucial for triggering)
+
+**2. Skill body structure**
+- Overview: 1-2 sentences
+- Key instructions: Specific, actionable steps
+- Examples: Concrete illustrations where helpful
+- References: Link to bundled resources if needed
+
+**3. Bundled resources** (if applicable)
+- `scripts/`: Automation scripts for deterministic tasks
+- `references/`: Detailed documentation, patterns, best practices
+- `assets/`: Templates or boilerplate files
+
+See `references/skill-design-patterns.md` for detailed guidance on skill design.
+
+### Step 4: Create the Skills
+
+For each skill identified:
+
+**Initialize the skill structure:**
+
+```bash
+python3 /path/to/skill-creator/scripts/init_skill.py <skill-name> --path ./skills/
+```
+
+**Customize the skill:**
+1. Update frontmatter (name, description)
+2. Write the skill body based on the original prompt's content
+3. Add any necessary bundled resources
+4. Remove unused example files
+
+**Validate the skill:**
+
+```bash
+python3 /path/to/skill-creator/scripts/quick_validate.py ./skills/<skill-name>
+```
+
+### Step 5: Create the Refactored Prompt
+
+Create a new prompt that leverages the skills:
+
+**Instead of inline instructions:**
+```jinja2
+Phase 1. READING: read the problem and reword it in clearer terms
+   1.1 If there are code or config snippets...
+   1.2 Highlight message errors...
+```
+
+**Use skill references:**
+```jinja2
+Use the code-issue-analysis skill to understand the problem.
+
+Use the test-creation skill to create reproduction scripts.
+
+Use the code-fix-verification skill to validate your changes.
+```
+
+**Template structure:**
+
+```jinja2
+{# Context setup #}
+Repository: {{ instance.repo_path }}
+Issue: {{ instance.problem_statement }}
+
+{# Skill-based workflow #}
+Follow this workflow:
+
+1. Analyze the issue (use code-issue-analysis skill)
+2. Explore the codebase (use code-exploration skill)  
+3. Create reproduction test (use test-creation skill)
+4. Implement fix (use code-implementation skill)
+5. Verify solution (use code-fix-verification skill)
+
+{# Domain-specific constraints #}
+Constraints:
+- Don't modify test files
+- Dependencies already installed
+- Make minimal changes
+```
+
+### Step 6: Test and Iterate
+
+**Test the refactored prompt:**
+1. Run it on sample instances
+2. Verify skills trigger correctly
+3. Check that the workflow is clear
+4. Compare results with original prompt
+
+**Iterate based on results:**
+- If skills don't trigger: Improve descriptions in frontmatter
+- If workflow is unclear: Add more guidance in prompt
+- If skills overlap: Refine skill boundaries
+- If missing functionality: Create additional skills
+
+## Best Practices
+
+### Do:
+- ✅ Keep skills focused and single-purpose
+- ✅ Write comprehensive descriptions (they control triggering)
+- ✅ Test each skill independently
+- ✅ Maintain backward compatibility when refactoring existing prompts
+- ✅ Document skill dependencies explicitly
+
+### Don't:
+- ❌ Create skills that are too granular (skill-per-sentence)
+- ❌ Create skills that are too broad (one-skill-does-everything)
+- ❌ Duplicate content across multiple skills
+- ❌ Forget to update skill descriptions (they're critical for triggering)
+- ❌ Create circular dependencies between skills
+
+## Resources
+
+### scripts/analyze_prompt.py
+
+Analyzes a prompt file and identifies:
+- Phases and sections
+- Workflow patterns
+- Suggested skill decomposition
+
+### references/skill-design-patterns.md
+
+Detailed guidance on effective skill design, including:
+- Progressive disclosure patterns
+- Skill granularity guidelines
+- Bundled resource organization
+- Common antipatterns to avoid
diff --git a/skills/prompt-refactor/references/skill-design-patterns.md b/skills/prompt-refactor/references/skill-design-patterns.md
new file mode 100644
index 0000000..7933aba
--- /dev/null
+++ b/skills/prompt-refactor/references/skill-design-patterns.md
@@ -0,0 +1,252 @@
+# Skill Design Patterns
+
+Comprehensive guidance for designing effective skills when refactoring prompts.
+
+## Skill Granularity Guidelines
+
+### Too Granular (Antipattern)
+
+❌ **Problem**: Creating a skill for every sentence or minor instruction
+
+**Example:**
+- `read-issue-title` skill
+- `identify-error-message` skill
+- `note-file-name` skill
+
+**Why it's bad**: Excessive overhead, context bloat, triggers are unclear
+
+### Too Broad (Antipattern)
+
+❌ **Problem**: One skill that does everything
+
+**Example:**
+- `fix-everything` skill that handles analysis, testing, implementation, and verification
+
+**Why it's bad**: No modularity, can't reuse parts, hard to maintain
+
+### Just Right ✅
+
+**Sweet spot**: Each skill represents a coherent, reusable capability
+
+**Examples:**
+- `code-issue-analysis` - Complete issue analysis workflow
+- `test-creation` - Reproduction script creation and validation
+- `code-exploration` - Codebase navigation and understanding
+
+**Characteristics:**
+- Clear, single purpose
+- Independently useful
+- Appropriate abstraction level
+- 50-300 lines of guidance (typically)
+
+## Progressive Disclosure in Skills
+
+Skills should layer information efficiently:
+
+### Level 1: Metadata (Always in Context)
+
+```yaml
+---
+name: code-issue-analysis
+description: Analyze bug reports and feature requests from issue descriptions. Use when starting work on a code issue to understand requirements, identify affected components, and plan the implementation approach.
+---
+```
+
+**Key**: Description must be comprehensive enough to trigger correctly
+
+### Level 2: Skill Body (Loaded When Triggered)
+
+```markdown
+# Code Issue Analysis
+
+## Quick Start
+Read the issue and identify:
+- Problem statement
+- Expected vs actual behavior
+- Affected components
+```
+
+**Keep**: Core workflow, essential instructions
+
+**Move out**: Detailed examples, edge cases, comprehensive references
+
+### Level 3: Bundled Resources (Loaded As Needed)
+
+```markdown
+## Detailed Analysis
+
+For complex issues, see:
+- references/analysis-frameworks.md - Structured analysis methods
+- references/common-patterns.md - Frequent bug patterns
+```
+
+**Contains**: Deep dives, extensive examples, reference material
+
+## Skill Boundary Patterns
+
+### Pattern 1: Sequential Workflow Phases
+
+When prompt has clear phases (Phase 1, 2, 3...), create skills per phase:
+
+**Original prompt structure:**
+```
+Phase 1: Analysis
+Phase 2: Exploration
+Phase 3: Implementation
+Phase 4: Verification
+```
+
+**Refactored skills:**
+- `code-issue-analysis` (Phase 1)
+- `code-exploration` (Phase 2)
+- `code-implementation` (Phase 3)
+- `code-verification` (Phase 4)
+
+**When to use**: Clear sequential workflows with distinct purposes
+
+### Pattern 2: Responsibility-Based
+
+Group by technical responsibility rather than workflow order:
+
+**Example:**
+- `test-infrastructure` - All testing-related guidance
+- `code-quality` - Standards, style, best practices
+- `git-workflow` - Version control procedures
+
+**When to use**: When concerns cut across workflow phases
+
+### Pattern 3: Domain-Specific
+
+Create skills for domain-specific knowledge:
+
+**Example:**
+- `swebench-conventions` - SWE-bench specific rules
+- `python-testing` - Python test patterns
+- `conda-environment` - Conda environment management
+
+**When to use**: Domain knowledge reusable across multiple prompts
+
+### Pattern 4: Hybrid
+
+Combine patterns as needed:
+
+**Example:**
+- Core workflow skills (Pattern 1)
+- Supporting domain skills (Pattern 3)
+- Cross-cutting concern skills (Pattern 2)
+
+## Skill Dependencies
+
+### Independent Skills (Preferred)
+
+```yaml
+---
+name: test-creation
+description: Create reproduction scripts for bugs...
+---
+```
+
+Can be used standalone, no dependencies.
+
+### Weak Dependencies (Acceptable)
+
+```markdown
+# Code Verification
+
+Verify your fix works:
+1. Run reproduction test
+2. Run related tests
+3. Check for regressions
+
+Optionally use the test-creation skill if you don't have a reproduction script yet.
+```
+
+References another skill optionally, works without it.
+
+### Strong Dependencies (Avoid)
+
+```markdown
+# Code Fix (Antipattern)
+
+This skill requires:
+1. Running code-exploration first
+2. Having completed issue-analysis
+3. Created tests with test-creation
+
+Without these, this skill cannot work.
+```
+
+❌ Tightly coupled, hard to use independently.
+
+## Skill Descriptions (Critical!)
+
+The description field controls when skills trigger. Make them comprehensive:
+
+### Weak Description ❌
+
+```yaml
+description: Analyzes code issues
+```
+
+**Problem**: Vague, won't trigger reliably
+
+### Better Description ✅
+
+```yaml
+description: Analyze bug reports and feature requests from issue descriptions. Use when starting work on a code issue to understand requirements, identify affected components, and plan the implementation approach. Includes methods for parsing stack traces, identifying error patterns, and extracting technical details.
+```
+
+**Why better**:
+- States what it does
+- States when to use it
+- Includes key capabilities
+- Uses triggering keywords
+
+## Common Antipatterns
+
+### 1. Instruction Duplication
+
+❌ **Problem**: Same instructions in multiple skills
+
+**Solution**: Move common instructions to a shared skill or reference doc
+
+### 2. Overly Generic Skills
+
+❌ **Problem**: "helper" or "utility" skills with no clear purpose
+
+**Solution**: Be specific about what the skill accomplishes
+
+### 3. Implementation Details in Prompts
+
+❌ **Problem**: Prompt contains detailed instructions that should be in skills
+
+**Solution**: Move detailed guidance to skills, keep only workflow in prompt
+
+### 4. Skills That Are Too Specific
+
+❌ **Problem**: `django-3.2-test-runner` only works for Django 3.2
+
+**Solution**: Create `python-test-runner` with Django-specific variants in references
+
+### 5. Missing Triggering Context
+
+❌ **Problem**: Skill has great content but poor description, never triggers
+
+**Solution**: Write comprehensive descriptions with triggering keywords
+
+## Refactoring Checklist
+
+When decomposing a prompt into skills:
+
+- [ ] Each skill has a single, clear purpose
+- [ ] Skills are independently reusable
+- [ ] Descriptions include WHAT and WHEN
+- [ ] No circular dependencies
+- [ ] No instruction duplication
+- [ ] Appropriate granularity (not too fine, not too coarse)
+- [ ] References used for detailed content
+- [ ] Scripts used for deterministic operations
+- [ ] Assets used for templates/boilerplate
+- [ ] Original prompt functionality preserved
+- [ ] Skills tested independently
+- [ ] Refactored prompt tested end-to-end
diff --git a/skills/prompt-refactor/scripts/analyze_prompt.py b/skills/prompt-refactor/scripts/analyze_prompt.py
new file mode 100755
index 0000000..b81c08d
--- /dev/null
+++ b/skills/prompt-refactor/scripts/analyze_prompt.py
@@ -0,0 +1,180 @@
+#!/usr/bin/env python3
+"""
+Analyze a prompt and identify components that can be factored into skills.
+
+This script helps decompose monolithic prompts into modular, reusable skills.
+"""
+
+import re
+from pathlib import Path
+from typing import Dict, List
+
+
+def identify_phases(prompt_text: str) -> List[Dict[str, str]]:
+    """
+    Identify distinct phases or sections in a prompt.
+    
+    Returns a list of dicts with 'title', 'content', and 'type' keys.
+    """
+    phases = []
+    
+    # Pattern 1: Numbered phases (e.g., "Phase 1. READING:")
+    phase_pattern = r'(?:Phase|Step)\s+(\d+)\.\s+([A-Z\s]+):(.*?)(?=(?:Phase|Step)\s+\d+\.|$)'
+    matches = re.finditer(phase_pattern, prompt_text, re.DOTALL | re.IGNORECASE)
+    
+    for match in matches:
+        phase_num = match.group(1)
+        phase_name = match.group(2).strip()
+        phase_content = match.group(3).strip()
+        
+        phases.append({
+            'title': f"{phase_name}",
+            'number': phase_num,
+            'content': phase_content,
+            'type': 'phase'
+        })
+    
+    # Pattern 2: Section headers (e.g., "## Section Title")
+    if not phases:
+        section_pattern = r'#{1,3}\s+(.+?)(?:\n|$)(.*?)(?=#{1,3}\s+|$)'
+        matches = re.finditer(section_pattern, prompt_text, re.DOTALL)
+        
+        for match in matches:
+            section_title = match.group(1).strip()
+            section_content = match.group(2).strip()
+            
+            if section_content:
+                phases.append({
+                    'title': section_title,
+                    'content': section_content,
+                    'type': 'section'
+                })
+    
+    return phases
+
+
+def identify_workflows(phases: List[Dict[str, str]]) -> List[Dict[str, str]]:
+    """
+    Group related phases into cohesive workflows.
+    
+    A workflow is a set of related steps that accomplish a higher-level goal.
+    """
+    workflows = []
+    
+    # Simple heuristic: each phase is a workflow step
+    # In more complex cases, you might group phases by semantic similarity
+    
+    current_workflow = {
+        'name': 'main_workflow',
+        'steps': phases
+    }
+    workflows.append(current_workflow)
+    
+    return workflows
+
+
+def suggest_skills(phases: List[Dict[str, str]]) -> List[Dict[str, str]]:
+    """
+    Suggest skills based on identified phases and their characteristics.
+    """
+    skills = []
+    
+    for phase in phases:
+        title = phase['title']
+        content = phase['content']
+        
+        # Determine skill type based on phase name and content
+        skill_type = 'workflow'
+        reusability = 'high'
+        
+        # Keywords that suggest different skill types
+        if any(kw in title.lower() for kw in ['test', 'testing', 'verification']):
+            skill_type = 'testing'
+        elif any(kw in title.lower() for kw in ['read', 'analysis', 'exploration', 'understand']):
+            skill_type = 'analysis'
+        elif any(kw in title.lower() for kw in ['fix', 'implement', 'edit', 'modify']):
+            skill_type = 'implementation'
+        elif any(kw in title.lower() for kw in ['review', 'validate', 'check']):
+            skill_type = 'validation'
+        
+        skills.append({
+            'phase_title': title,
+            'suggested_skill_name': title.lower().replace(' ', '-'),
+            'skill_type': skill_type,
+            'reusability': reusability,
+            'phase_content': content[:200] + '...' if len(content) > 200 else content
+        })
+    
+    return skills
+
+
+def analyze_prompt(prompt_path: str) -> Dict:
+    """
+    Main analysis function that processes a prompt file.
+    """
+    prompt_text = Path(prompt_path).read_text()
+    
+    # Step 1: Identify phases/sections
+    phases = identify_phases(prompt_text)
+    
+    # Step 2: Identify workflows
+    workflows = identify_workflows(phases)
+    
+    # Step 3: Suggest skills
+    suggested_skills = suggest_skills(phases)
+    
+    return {
+        'phases': phases,
+        'workflows': workflows,
+        'suggested_skills': suggested_skills,
+        'original_length': len(prompt_text),
+        'num_phases': len(phases)
+    }
+
+
+def print_analysis(analysis: Dict) -> None:
+    """
+    Pretty print the analysis results.
+    """
+    print("=" * 80)
+    print("PROMPT ANALYSIS RESULTS")
+    print("=" * 80)
+    print(f"\nOriginal prompt length: {analysis['original_length']} characters")
+    print(f"Number of phases identified: {analysis['num_phases']}")
+    
+    print("\n" + "-" * 80)
+    print("IDENTIFIED PHASES:")
+    print("-" * 80)
+    for i, phase in enumerate(analysis['phases'], 1):
+        print(f"\n{i}. {phase['title']}")
+        print(f"   Type: {phase['type']}")
+        if 'number' in phase:
+            print(f"   Phase number: {phase['number']}")
+    
+    print("\n" + "-" * 80)
+    print("SUGGESTED SKILLS:")
+    print("-" * 80)
+    for i, skill in enumerate(analysis['suggested_skills'], 1):
+        print(f"\n{i}. Skill: {skill['suggested_skill_name']}")
+        print(f"   Original phase: {skill['phase_title']}")
+        print(f"   Type: {skill['skill_type']}")
+        print(f"   Reusability: {skill['reusability']}")
+    
+    print("\n" + "=" * 80)
+
+
+if __name__ == '__main__':
+    import sys
+    
+    if len(sys.argv) < 2:
+        print("Usage: python analyze_prompt.py <path_to_prompt_file>")
+        sys.exit(1)
+    
+    prompt_path = sys.argv[1]
+    
+    if not Path(prompt_path).exists():
+        print(f"Error: File not found: {prompt_path}")
+        sys.exit(1)
+    
+    analysis = analyze_prompt(prompt_path)
+    print_analysis(analysis)
diff --git a/skills/test-reproduction/SKILL.md b/skills/test-reproduction/SKILL.md
new file mode 100644
index 0000000..d5b4041
--- /dev/null
+++ b/skills/test-reproduction/SKILL.md
@@ -0,0 +1,78 @@
+---
+name: test-reproduction
+description: Create minimal reproduction scripts to verify bugs before implementing fixes. Use when you need to confirm a bug exists, create a test case, or validate that a problem can be reproduced. Essential for test-driven bug fixing.
+---
+
+# Test Reproduction
+
+Create focused reproduction scripts that demonstrate the issue before implementing any fix.
+
+## Why Create Reproduction Scripts First
+
+- Confirms you understand the issue correctly
+- Provides immediate feedback when testing fixes
+- Serves as a regression test
+- Documents the expected vs actual behavior
+
+## Creating a Reproduction Script
+
+### 1. Study Existing Tests
+
+Before creating your script:
+- Look at test files in the repository
+- Understand the test framework being used (pytest, unittest, etc.)
+- Note patterns for setup, execution, and assertions
+- Identify how to import and use the affected components
+
+### 2. Create a Minimal Script
+
+Build the smallest possible script that reproduces the issue:
+
+```python
+# reproduce_issue.py
+# Minimal script to reproduce bug #1234
+
+from module import affected_function
+
+# Setup
+test_data = ...
+
+# Execute
+result = affected_function(test_data)
+
+# Verify (this should fail with the bug)
+expected = ...
+assert result == expected, f"Expected {expected}, got {result}"
+```
+
+**Keep it minimal:**
+- Only import what's needed
+- Minimal test data
+- Clear assertion or output that shows the bug
+- Comments explaining what should happen
+
+### 3. Run and Verify
+
+Execute the reproduction script:
+```bash
+python reproduce_issue.py
+```
+
+**Expected outcome**: The script should fail or show incorrect behavior, confirming the bug.
+
+### 4. Adjust as Needed
+
+If the script doesn't reproduce the issue:
+- Re-read the bug report
+- Check your understanding of the issue
+- Verify you're using the right inputs
+- Add debugging output to understand what's happening
+- Try different scenarios from the bug report
+
+## Best Practices
+
+- Create the script **before** implementing any fix
+- Make it runnable with a single command
+- Include clear output showing what's wrong
+- Document expected vs actual behavior in comments
+- Keep the script in the workspace for validation later