6.5 KiB
🛠️ Repository Maintenance Guide (V3)
"If it's not documented, it's broken."
This guide details the exact procedures for maintaining antigravity-awesome-skills.
It covers the Quality Bar, Documentation Consistency, and Release Workflows.
0. 🤖 Agent Protocol (THE BIBLE)
AGENTS MUST READ AND FOLLOW THIS SECTION BEFORE MARKING ANY TASK AS COMPLETE.
There are 3 things that usually fail/get forgotten. DO NOT FORGET THEM:
1. 📤 ALWAYS PUSH (Non-Negotiable)
Committing is NOT enough. You must PUSH to the remote.
- BAD:
git commit -m "feat: new skill"(User sees nothing) - GOOD:
git commit -m "..." && git push origin main
2. 🔄 SYNC GENERATED FILES (Avoid CI Drift)
If you touch any of these:
skills/(aggiungi/rimuovi/modifichi skill)- la sezione Full Skill Registry di
README.md - i conteggi/claim sul numero di skill (
256+ Agentic Skills...,(256/256), ecc.)
…allora DEVI eseguire la Validation Chain PRIMA di committare.
- Eseguire
validate_skills.pyNON è opzionale. - Eseguire
generate_index.pyNON è opzionale. - Eseguire
update_readme.pyNON è opzionale.
Se la CI fallisce con:
❌ Detected uncommitted changes in README.md or skills_index.json
significa che non hai eseguito o committato correttamente la Validation Chain.
3. 📝 EVIDENCE OF WORK
- You must create/update
walkthrough.mdorRELEASE_NOTES.mdto document what changed. - If you made something new, link it in the artifacts.
4. 🚫 NO BRANCHES
- ALWAYS use the
mainbranch. - NEVER create feature branches (e.g.,
feat/new-skill). - We commit directly to
mainto keep history linear and simple.
1. 🚦 Daily Maintenance Routine
A. Validation Chain
Before ANY commit that adds/modifies skills, run the chain:
-
Validate Metadata & Quality:
python3 scripts/validate_skills.pyMust return 0 errors for new skills.
-
Regenerate Index:
python3 scripts/generate_index.py -
Update Readme:
python3 scripts/update_readme.py -
COMMIT GENERATED FILES:
git add skills_index.json README.md git commit -m "chore: sync generated files"🔴 CRITICAL: If you skip this, CI will fail with "Detected uncommitted changes". See docs/CI_DRIFT_FIX.md for details.
B. Post-Merge Routine (Must Do)
After multiple PR merges or significant changes:
-
Sync Contributors List:
- Run:
git shortlog -sn --all - Update
## Repo Contributorsin README.md.
- Run:
-
Verify Table of Contents:
- Ensure all new headers have clean anchors.
- NO EMOJIS in H2 headers.
-
Draft a Release:
- Go to Releases Page.
- Draft a new release for the merged changes.
- Tag version (e.g.,
v3.1.0).
2. 📝 Documentation "Pixel Perfect" Rules
We discovered several consistency issues during V3 development. Follow these rules STRICTLY.
A. Table of Contents (TOC) Anchors
GitHub's anchor generation breaks if headers have emojis.
- BAD:
## 🚀 New Here?-> Anchor:#--new-here(Broken) - GOOD:
## New Here?-> Anchor:#new-here(Clean)
Rule: NEVER put emojis in H2 (##) headers. Put them in the text below if needed.
B. The "Trinity" of Docs
If you update installation instructions or tool compatibility, you MUST update all 3 files:
README.md(Source of Truth)docs/GETTING_STARTED.md(Beginner Guide)docs/FAQ.md(Troubleshooting)
Common pitfall: Updating the clone URL in README but leaving an old one in FAQ.
C. Statistics Consistency (CRITICAL)
If you add/remove skills, you MUST ensure the total count is identical in ALL locations. Do not allow drift (e.g., 356 in title, 354 in header).
Locations to check:
- Title of
README.md: "356+ Agentic Skills..." ## Full Skill Registry (356/356)header.docs/GETTING_STARTED.mdintro.
D. Credits Policy (Who goes where?)
- Credits & Sources: Use this for External Repos.
- Rule: "I extracted skills from this link you sent me." -> Add to
## Credits & Sources.
- Rule: "I extracted skills from this link you sent me." -> Add to
- Repo Contributors: Use this for Pull Requests.
- Rule: "This user sent a PR." -> Add to
## Repo Contributors.
- Rule: "This user sent a PR." -> Add to
E. Badges & Links
- Antigravity Badge: Must point to
https://github.com/sickn33/antigravity-awesome-skills, NOTanthropics/antigravity. - License: Ensure the link points to
LICENSEfile.
3. 🛡️ Governance & Quality Bar
A. The 5-Point Quality Check
Reject any PR that fails this:
- Metadata: Has
name,description? - Safety:
risk: offensiveused for red-team tools? - Clarity: Does it say when to use it?
- Examples: Copy-pasteable code blocks?
- Actions: "Run this command" vs "Think about this".
B. Risk Labels (V3)
- ⚪ Safe: Default.
- 🔴 Risk: Destructive/Security tools. MUST have
[Authorized Use Only]warning. - 🟣 Official: Vendor mirrors only.
4. 🚀 Release Workflow
When cutting a new version (e.g., V4):
- Run Full Validation:
python3 scripts/validate_skills.py --strict - Update Changelog: Create
RELEASE_NOTES.md. - Bump Version: Update header in
README.md. - Tag Release:
git tag -a v3.0.0 -m "V3 Enterprise Edition" git push origin v3.0.0
📋 Release Note Template
All changeslogs/release notes MUST follow this structure to ensure professionalism and quality:
# Release vX.Y.Z: [Theme Name]
> **[One-line catchy summary of the release]**
[Brief 2-3 sentence intro about the release's impact]
## 🚀 New Skills
### [Emoji] [Skill Name](skills/skill-name/)
**[Bold high-level benefit]**
[Description of what it does]
- **Key Feature 1**: [Detail]
- **Key Feature 2**: [Detail]
> **Try it:** `(User Prompt) ...`
---
## 📦 Improvements
- **Registry Update**: Now tracking [N] skills.
- **[Component]**: [Change detail]
## 👥 Credits
A huge shoutout to our community contributors:
- **@username** for `skill-name`
- **@username** for `fix-name`
---
_Upgrade now: `git pull origin main` to fetch the latest skills._
5. 🚨 Emergency Fixes
If a skill is found to be harmful or broken:
- Move to broken folder (don't detect):
mv skills/bad-skill skills/.broken/ - Or Add Warning: Add
> [!WARNING]to the top ofSKILL.md. - Push Immediately.