Clawdie AI
301aa0b7b1
Establish workflow for keeping docs current: - When you update software/architecture, update the 'Tested With' section in README - When you create a new skill/guide, add metadata with version and date - Docs updates go in the same commit as code changes This prevents docs drift and ensures users always have accurate, trustworthy information. Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com> --- Build: pass | Tests: pass — Tests 489 passed | 10 skipped (499)
3.2 KiB
Contributing
Source Code Changes
Accepted: Bug fixes, security fixes, simplifications, reducing code.
Not accepted: Features, capabilities, compatibility, enhancements. These should be skills.
Skills
A skill is a markdown file in .agent/skills/ that teaches the Coding Agent how to transform a Clawdie installation.
A PR that contributes a skill should not modify any source files.
Your skill should contain the instructions Claude follows to add the feature—not pre-built code. See /add-telegram for a good example.
Why?
Every user should have clean and minimal code that does exactly what they need. Skills let users selectively add features to their fork without inheriting code for features they don't want.
Testing
Test your skill by running it on a fresh clone before submitting.
Pre-Commit Security Check
Before every commit, a security hook automatically scans staged files for sensitive data (credentials, private IPs, project-specific usernames/domains).
Setup
The hook is stored in scripts/hooks/pre-commit. To install it:
cp scripts/hooks/pre-commit .git/hooks/pre-commit
chmod +x .git/hooks/pre-commit
The hook will auto-generate config files on first run:
.git/hooks/sensitive-patterns.txt— blocked patterns.git/hooks/sensitive-allowlist.txt— false positive exceptions
If Your Commit Is Blocked
Option 1: Remove the sensitive data and re-commit
git add your-file.md
git commit -m "your message"
Option 2: Add to allowlist (for false positives)
# Example: legitimate "192.168.0.1" in a router tutorial
echo "docs/router-setup.md:192\.168\." >> .git/hooks/sensitive-allowlist.txt
git commit -m "your message"
Option 3: Skip check (not recommended)
SKIP_SECURITY_CHECK=1 git commit -m "your message"
See scripts/hooks/SECURITY.md for full details on patterns, customization, and audits.
Documentation Update Protocol
Docs stay accurate by updating them at the same time you update code.
When to Update Docs
| Trigger | Action |
|---|---|
| Update software version (FreeBSD, Node, PostgreSQL, etc.) | Update "Tested With" section + date in README |
| Architecture or system change | Update relevant setup guide |
| New skill or guide created | Add "Tested With" + date to the new doc |
| Bug fix affecting user workflow | Update affected guide/tutorial |
Example: Updating FreeBSD
You update from FreeBSD 14.1 to 15.0:
- Update code/infrastructure
- Test it works
- Update README:
## Tested With - FreeBSD 15.0-RELEASE - Node.js 20.11.0 - Last verified: 23.mar.2026 - Commit both the code change and the README update together
Example: New Skill
You add a skill add-monitoring.md:
- Write the skill instructions
- Add a "Tested With" section:
## Tested With - Clawdie v0.8.2+ - FreeBSD 15.0 - Verified: 23.mar.2026 - Commit the skill with the metadata
No Special Tooling
This is not automated. Just: When you update code, also update the relevant doc. Include both changes in the same commit.
Long-term benefit: Users trust the docs because they're kept current with the code.