Sharing Skills
Core Principles
-
Test before share - Only share skills validated via creating-skills TDD process
-
One skill per PR - Each skill independently reviewable
-
Broadly useful - Not project-specific or experimental
Quick Reference
1. Sync
git checkout main && git pull upstream main
2. Branch
git checkout -b "add-${skill_name}-skill"
3. Work
Edit skills/your-skill-name/SKILL.md
4. Commit
git add skills/your-skill-name/ git commit -m "Add ${skill_name} skill"
5. Push + PR
git push -u origin "add-${skill_name}-skill"
gh pr create --repo <UPSTREAM_ORG>/<UPSTREAM_REPO>
--title "Add ${skill_name} skill"
--body "## Summary\n...\n## Testing\n..."
When to Share vs Keep Personal
Share Keep Personal
Applies broadly Project-specific
Well-tested Experimental/unstable
Others benefit Contains sensitive info
Documented Too narrow/niche
Prerequisites
-
gh CLI installed and authenticated
-
Working directory is your local skills clone
-
Skill tested using creating-skills TDD process
Anti-Patterns
-
❌ Batching - Multiple skills in one PR
-
❌ Untested - Sharing without baseline testing
-
❌ Project-specific - Personal conventions as universal skills
-
❌ Incomplete docs - Missing Overview, Quick Reference, Common Mistakes
References
- Workflow Example - Complete async-patterns example
Related
-
creating-skills - REQUIRED: Create well-tested skills before sharing
-
maestro-core - Workflow routing and skill hierarchy