Files
claude-plugins/TESTING.md

447 lines
10 KiB
Markdown
Raw Normal View History

# Testing and Validating Skills
This guide helps you validate skills before adding them to the repository or using them in production.
## Quick Validation Checklist
Run through this checklist before submitting a skill:
```
Metadata
[ ] SKILL.md exists
[ ] YAML frontmatter is valid
[ ] Name ≤ 64 characters
[ ] Description ≤ 1024 characters
[ ] Description includes trigger scenarios
Content Quality
[ ] "When to Use This Skill" section present
[ ] At least one concrete example
[ ] Examples are runnable/testable
[ ] File references are accurate
[ ] No sensitive data hardcoded
Triggering Tests
[ ] Triggers on target scenarios
[ ] Doesn't trigger on unrelated scenarios
[ ] No conflicts with similar skills
Security
[ ] No credentials or API keys
[ ] No personal information
[ ] Safe file system access only
[ ] External dependencies verified
```
## Detailed Testing Process
### 1. Metadata Validation
#### Test YAML Parsing
Try parsing the frontmatter:
```bash
# Extract and validate YAML
head -n 10 SKILL.md | grep -A 3 "^---$"
```
Verify:
- YAML is valid (no syntax errors)
- Both `name` and `description` are present
- Values are within character limits
#### Character Limits
```bash
# Count characters in name (must be ≤ 64)
grep "^name:" SKILL.md | sed 's/name: //' | wc -c
# Count characters in description (must be ≤ 1024)
grep "^description:" SKILL.md | sed 's/description: //' | wc -c
```
### 2. Content Quality Testing
#### Check Required Sections
```bash
# Verify "When to Use This Skill" section exists
grep -i "when to use" SKILL.md
# Verify examples exist
grep -i "example" SKILL.md
```
#### Test File References
If skill references other files, verify they exist:
```bash
# Find markdown links
grep -o '\[.*\]([^)]*\.md)' SKILL.md
# Check if referenced files exist
# (manually verify each one)
```
#### Validate Examples
For each example in the skill:
1. Try running the code/commands
2. Verify output matches expectations
3. Check for edge cases
4. Ensure examples are complete (no placeholders)
### 3. Trigger Testing
This is the most important validation step.
#### Create Test Scenarios
**Positive Tests (SHOULD trigger)**
Create a list of scenarios where the skill should activate:
```markdown
Test Scenario 1: [Describe task that should trigger]
Expected: Skill activates
Actual: [Test result]
Test Scenario 2: [Another trigger case]
Expected: Skill activates
Actual: [Test result]
```
**Negative Tests (SHOULD NOT trigger)**
Create scenarios where the skill should NOT activate:
```markdown
Test Scenario 3: [Similar but different task]
Expected: Skill does NOT activate
Actual: [Test result]
Test Scenario 4: [Unrelated task]
Expected: Skill does NOT activate
Actual: [Test result]
```
#### Example Testing Session
For a "Python Testing with pytest" skill:
**Should Trigger:**
- "Help me write tests for my Python function"
- "How do I use pytest fixtures?"
- "Create unit tests for this class"
**Should NOT Trigger:**
- "Help me test my JavaScript code" (different language)
- "Debug my pytest installation" (installation, not testing)
- "Explain what unit testing is" (concept, not implementation)
#### Run Tests with Claude
1. Load the skill
2. Ask Claude each test question
3. Observe if skill triggers (check response for skill context)
4. Document results
### 4. Token Efficiency Testing
#### Measure Content Size
```bash
# Count tokens (approximate: words × 1.3)
wc -w SKILL.md
# Or use a proper token counter
# (tokens ≈ characters ÷ 4 for rough estimate)
wc -c SKILL.md
```
#### Evaluate Split Points
Ask yourself:
- Is content loaded only when needed?
- Could mutually exclusive sections be split?
- Are examples concise but complete?
- Is reference material in separate files?
Target sizes:
- **SKILL.md**: Under 3000 tokens (core workflows)
- **Additional files**: Load only when referenced
- **Total metadata**: ~100 tokens
### 5. Security Validation
#### Automated Checks
```bash
# Check for potential secrets
grep -iE "(password|api[_-]?key|secret|token|credential)" SKILL.md
# Check for hardcoded paths
grep -E "(/Users/|/home/|C:\\\\)" SKILL.md
# Check for sensitive file extensions
grep -E "\.(key|pem|cert|p12|pfx)( |$)" SKILL.md
```
#### Manual Review
Review each file for:
- [ ] No credentials in examples
- [ ] No personal information
- [ ] File paths are generic/relative
- [ ] Network access is documented
- [ ] External dependencies are from trusted sources
- [ ] Scripts don't make unsafe system changes
### 6. Cross-Skill Conflict Testing
If you have multiple skills installed:
1. **Similar domain overlap**: Test that specific skills trigger (not generic ones)
2. **Keyword conflicts**: Check if multiple skills trigger on same query
3. **Description clarity**: Ensure each skill's domain is distinct
Example conflicts to avoid:
- "Python Helper" (too generic) vs "Python Testing with pytest" (specific)
- Both trigger on "Help with Python" → Fix by making descriptions more specific
## Testing Workflows
### Quick Test (5 minutes)
For minor updates or simple skills:
1. ✓ Validate metadata (YAML, character limits)
2. ✓ Check one example works
3. ✓ Test one positive trigger
4. ✓ Test one negative trigger
5. ✓ Scan for secrets
### Standard Test (15 minutes)
For new skills or significant changes:
1. ✓ Complete metadata validation
2. ✓ Test all examples
3. ✓ Run 3-5 trigger tests (positive + negative)
4. ✓ Check token efficiency
5. ✓ Full security review
6. ✓ Verify file references
### Comprehensive Test (30+ minutes)
For complex skills or pre-release:
1. ✓ All standard tests
2. ✓ Test with different Claude models
3. ✓ Test conflict scenarios with other skills
4. ✓ Have someone else try the skill
5. ✓ Test edge cases in examples
6. ✓ Review progressive disclosure strategy
7. ✓ Load test (simulate typical usage)
## Common Issues and Fixes
### Skill Doesn't Trigger
**Symptoms**: Claude doesn't load skill context when expected
**Diagnose**:
1. Description too vague?
2. Description missing trigger keywords?
3. Name too generic?
**Fix**:
```yaml
# Before
description: Python development helpers
# After
description: Create Python projects using Hatch and Hatchling for dependency management. Use when initializing new Python packages or configuring build systems.
```
### Skill Triggers Too Often
**Symptoms**: Skill loads for unrelated queries
**Diagnose**:
1. Description too broad?
2. Keywords too common?
**Fix**:
```yaml
# Add specificity and exclusions
description: Debug Swift applications using LLDB for crashes, memory issues, and runtime errors. Use when investigating Swift bugs or analyzing app behavior. NOT for general Swift coding or learning.
```
### Examples Don't Work
**Symptoms**: Users can't reproduce examples
**Diagnose**:
1. Missing prerequisites?
2. Placeholders not explained?
3. Environment-specific code?
**Fix**:
- Add prerequisites section
- Make examples self-contained
- Use generic paths and values
### High Token Usage
**Symptoms**: Skill loads too much content
**Diagnose**:
1. Too much in SKILL.md?
2. No progressive disclosure?
3. Verbose examples?
**Fix**:
- Split reference material to separate files
- Link to external resources
- Condense examples
- Move advanced content to on-demand files
## Automated Testing (Advanced)
For repositories with many skills, consider automation:
### Validate All Skills
```bash
#!/bin/bash
# validate-skills.sh
for skill_dir in */; do
if [ -f "$skill_dir/SKILL.md" ]; then
echo "Validating $skill_dir..."
# Check frontmatter exists
if ! grep -q "^---$" "$skill_dir/SKILL.md"; then
echo "❌ Missing YAML frontmatter"
fi
# Check name length
name=$(grep "^name:" "$skill_dir/SKILL.md" | sed 's/name: //')
if [ ${#name} -gt 64 ]; then
echo "❌ Name too long: ${#name} chars"
fi
# Check for secrets
if grep -qiE "(password|api[_-]?key|secret)" "$skill_dir/SKILL.md"; then
echo "⚠️ Potential secrets found"
fi
echo "✓ $skill_dir validated"
fi
done
```
### CI/CD Integration
Add to GitHub Actions or similar:
```yaml
name: Validate Skills
on: [push, pull_request]
jobs:
validate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Run validation
run: |
chmod +x validate-skills.sh
./validate-skills.sh
```
## Documentation Testing
Ensure documentation is accurate:
1. **Links work**: All markdown links resolve
2. **Paths are correct**: File references are accurate
3. **Examples are current**: Code samples match latest versions
4. **Formatting is consistent**: Markdown renders correctly
```bash
# Check for broken internal links
grep -r '\[.*\](.*\.md)' . | while read line; do
# Extract and verify file exists
# (implementation left as exercise)
done
```
## User Acceptance Testing
The ultimate test is real usage:
1. **Give skill to others**: Have colleagues test it
2. **Monitor usage**: See when it triggers in practice
3. **Gather feedback**: Ask users about clarity and usefulness
4. **Iterate**: Refine based on real-world usage
## Testing Checklist Template
Copy this for each skill you test:
```markdown
# Testing Report: [Skill Name]
Date: [YYYY-MM-DD]
Tester: [Name]
## Metadata
- [ ] YAML valid
- [ ] Name ≤ 64 chars
- [ ] Description ≤ 1024 chars
- [ ] Trigger scenarios in description
## Content
- [ ] "When to Use" section present
- [ ] Examples runnable
- [ ] File references accurate
- [ ] No secrets
## Triggering
Positive tests:
1. [Scenario] - Result: [ ] Pass [ ] Fail
2. [Scenario] - Result: [ ] Pass [ ] Fail
Negative tests:
1. [Scenario] - Result: [ ] Pass [ ] Fail
2. [Scenario] - Result: [ ] Pass [ ] Fail
## Security
- [ ] No credentials
- [ ] No personal data
- [ ] Safe file access
- [ ] Dependencies verified
## Overall
- [ ] Ready for production
- [ ] Needs revision
- [ ] Rejected
Notes:
[Any additional observations]
```
## Resources
- [claude-skills/SKILL.md](./claude-skills/SKILL.md) - Best practices guide
- [claude-skills/checklist.md](./claude-skills/checklist.md) - Quality checklist
- [CONTRIBUTING.md](./CONTRIBUTING.md) - Contribution guidelines
---
**Remember**: Testing isn't just about finding bugs—it's about ensuring your skill provides real value and triggers at the right time.