versioning-skills
Scannednpx machina-cli add skill oaustegard/claude-skills/versioning-skills --openclawVersioning Skills
Use git to track changes during skill development. Initialize repos after creating skills, commit after each logical change, and use git commands to compare versions or revert mistakes.
When Creating a New Skill
After running init_skill.sh, immediately initialize git:
cd /home/claude/skill-name
git init
git add .
git commit -m "Initial commit: skill structure"
When Editing Skills
After each logical change (adding a section, fixing an example, refactoring), commit:
cd /home/claude/skill-name
git add .
git commit -m "Add: validation workflow pattern"
Commit message patterns:
"Add [feature]: description"- New functionality"Fix [issue]: description"- Bug fixes"Update [section]: description"- Content changes"Refactor [component]: description"- Structural changes"Remove [feature]: description"- Deletions
When User Asks "What Changed?"
CRITICAL: Never display diffs inline - redirect to files and provide links.
ALSO CRITICAL: Only create diffs/changelogs when user explicitly asks "what changed?" or "show differences"
Don't preemptively create:
- CHANGELOG.md files
- Change documentation
- "Here's what I modified" summaries
Why: The updated code/docs ARE the documentation. Creating separate changelogs wastes tokens and duplicates information.
When user asks, show commit history:
cd /home/claude/skill-name
git log --oneline
Save diff to file (prevents token waste):
cd /home/claude/skill-name
git diff <commit-hash-1> <commit-hash-2> > /mnt/user-data/outputs/changes.diff
Then provide: [View changes](computer:///mnt/user-data/outputs/changes.diff)
For multiple diffs:
# Changed files list
git diff --name-only <commit-1> <commit-2> > /mnt/user-data/outputs/changed-files.txt
# Full diff
git diff <commit-1> <commit-2> > /mnt/user-data/outputs/full-diff.diff
# Summary stats
git diff --stat <commit-1> <commit-2> > /mnt/user-data/outputs/diff-stats.txt
Wrong: git diff <commit-1> <commit-2> (displays in stdout, wastes tokens)
Right: git diff <commit-1> <commit-2> > /mnt/user-data/outputs/diff.txt (file + link)
Reverting Commits or Discarding Work
Undo last commit (keep uncommitted changes):
cd /home/claude/skill-name
git reset --soft HEAD~1
Undo last commit (discard all changes):
git reset --hard HEAD~1
Revert specific commit (creates new commit, preserves history):
git revert <commit-hash>
Discard uncommitted edits (restore to last commit):
git restore .
Prefer git revert over git reset --hard to preserve history.
When Testing Experimental Changes
Create a branch before risky modifications:
cd /home/claude/skill-name
# Create and switch to experiment branch
git checkout -b experiment-new-approach
# Make changes, test
# ... edit files ...
git add .
git commit -m "Experiment: alternative validation"
# If successful, merge back
git checkout main
git merge experiment-new-approach
git branch -d experiment-new-approach
# If failed, abandon and return to main
git checkout main
git branch -D experiment-new-approach
When Comparing Two Skill Versions
If user uploads or provides two versions:
cd /home/claude
mkdir -p compare
# Extract both versions
unzip /mnt/user-data/uploads/skill-v1.zip -d compare/v1
unzip /mnt/user-data/uploads/skill-v2.zip -d compare/v2
# Initialize git in each
cd compare/v1 && git init && git add . && git commit -m "Version 1"
cd ../v2 && git init && git add . && git commit -m "Version 2"
# Compare
cd ../v1
git diff --no-index . ../v2
Or use diff directly without git:
diff -ur compare/v1 compare/v2
When Packaging Skills
Before zipping, verify clean state:
cd /home/claude/skill-name
git status # Should show no uncommitted changes
git log --oneline # Review history
# Package (excludes .git automatically with -x)
cd /home/claude
zip -r /mnt/user-data/outputs/skill-name.zip skill-name/ -x "*.git*"
Workflow Integration
During skill creation:
- Run init_skill.sh
- Immediately:
git init && git add . && git commit -m "Initial structure" - Edit SKILL.md
- Commit:
git add . && git commit -m "Add: core documentation" - Continue editing → commit after each major change
During skill editing:
- Make change with str_replace or bash
- Test if needed
- Commit:
git add <file> && git commit -m "Fix: corrected example" - Repeat
Before delivery:
- Review history:
git log --oneline - Verify clean:
git status - Package with -x to exclude .git
Configuration
Set git identity once per session to avoid prompts:
git config --global user.name "Claude"
git config --global user.email "skill-dev@claude.ai"
Common Issues
"not a git repository"
→ Run git init first
"nothing to commit"
→ No changes made, or forgot git add
Commit message editor opens
→ Always use -m "message" with commit
Best Practices
Commit after each logical change, not every keystroke. Use descriptive commit messages in present tense. Create branches for experimental changes. Use git log --oneline frequently to track progress.
Limitations
Git repos in /home/claude reset between sessions. Version control only persists within a single development session. Network restrictions prevent push/pull to remote repos.
Source
git clone https://github.com/oaustegard/claude-skills/blob/main/versioning-skills/SKILL.mdView on GitHub Overview
Versioning-skills enforces git tracking during skill development. It recommends initializing a repo after creating skills, committing after each logical change, and using git diff or git log to compare versions or revert mistakes.
How This Skill Works
Technically, you initialize a git repository in the skill folder, add all files, and create commits after each meaningful change. You follow a consistent commit message pattern such as Add, Fix, Update, Refactor, or Remove. Use git log and git diff to review changes and compare versions, and redirect diffs to files when sharing to save tokens.
When to Use It
- After creating a new skill with init_skill.sh
- After editing and refining a skill
- When someone asks What Changed or show differences
- When testing experimental changes in a dedicated branch
- When comparing two skill versions uploaded or provided
Quick Start
- Step 1: After creating a skill, cd into the skill folder and run git init, then git add . and git commit -m Initial commit: skill structure
- Step 2: After each logical change, git add . and git commit -m Describe the change
- Step 3: When asked what changed, use git log and git diff and save diffs to a file if sharing
Best Practices
- Initialize a repo immediately after creating a new skill
- Commit after every logical change such as adding a section or fixing an example
- Use standardized commit messages like Add, Fix, Update, Refactor, Remove
- Use separate branches for experimental changes and merges
- Share diffs by saving to files and providing links instead of inline diffs
Example Use Cases
- New skill created: cd into skill-name, git init, git add ., git commit -m Initial commit: skill structure
- Editing: after adding validation workflow pattern, git add ., git commit -m Add validation workflow pattern
- Testing experimental changes: create branch experiment-new-approach, commit, merge back or discard
- Reverting a faulty commit: use git revert <commit-hash> to preserve history
- Comparing two versions: unzip skill-v1 and skill-v2, git diff --no-index . ../v2