Repository Documentation Updates
This skill helps update core repository documentation files before committing changes or creating releases.
When to Use This Skill
Use this skill when:
- Preparing to commit changes and need to update documentation
- Creating a release and need to update CHANGELOG
- Documentation is out of sync with code changes
- Need to add or update core repository files (README, CHANGELOG, LICENSE, CONTRIBUTING)
Core Documentation Files
README.md
Primary documentation file covering:
- Project overview and purpose
- Setup and installation instructions
- Basic usage examples
- Development guidelines
- Links to additional documentation
Common updates:
- Add new features or capabilities
- Update installation steps
- Revise configuration instructions
- Add or update examples
CHANGELOG.md
Chronological record of changes following Keep a Changelog format.
Structure:
# Changelog
## [Unreleased]
### Added
- New features not yet released
### Changed
- Changes to existing functionality
### Fixed
- Bug fixes
## [X.Y.Z] - YYYY-MM-DD
### Added
- Feature descriptions
### Changed
- Modification descriptions
### Fixed
- Bug fix descriptions
Common updates:
- Move items from Unreleased to new version section
- Add new version entry with date
- Document new features, changes, and fixes
- Add version comparison links at bottom
LICENSE
Legal terms for code usage and distribution.
Common updates:
- Update copyright year
- Change license type (requires project decision)
- Update copyright holder
CONTRIBUTING.md
Guidelines for contributors.
Typical sections:
- How to report issues
- Development workflow
- Code submission process
- Testing requirements
- Communication channels
Common updates:
- Update workflow steps
- Revise standards or requirements
- Update contact information
- Add new guidelines
Workflow for Release Preparation
When preparing a release:
-
Review changes since last release
- Check git log or PR history
- Identify user-facing changes
- Note breaking changes or deprecations
-
Update CHANGELOG.md
- Create new version section:
[X.Y.Z] - YYYY-MM-DD - Move items from Unreleased to new version
- Categorize: Added, Changed, Deprecated, Removed, Fixed, Security
- Add version comparison link
- Create new version section:
-
Update README.md if needed
- Add new features to overview
- Update version numbers
- Revise examples if API changed
- Update dependencies list
-
Update LICENSE if needed
- Update copyright year
- Verify copyright holder
-
Review CONTRIBUTING.md
- Ensure workflow is current
- Update any changed processes
Workflow for Regular Commits
Before committing changes:
-
Identify documentation impact
- Does change affect usage?
- Are there new features?
- Did configuration change?
- Are there breaking changes?
-
Update CHANGELOG.md Unreleased section
- Add to appropriate category (Added/Changed/Fixed)
- Be specific and user-focused
- Note if breaking change
-
Update README.md if needed
- Add new features
- Update examples
- Revise configuration steps
Best Practices
- Keep CHANGELOG current - Update with each change, not at release time
- Be specific - "Added user authentication" not "Made improvements"
- User perspective - Document what users see, not internal refactoring
- Version format - Follow Semantic Versioning (MAJOR.MINOR.PATCH)
- Date format - Use ISO 8601 (YYYY-MM-DD)
- Categorize correctly - Use standard categories (Added, Changed, Fixed, etc.)
- Link commits - Reference commit SHAs or PR numbers when helpful
Output Format
Generate updated documentation files directly in /mnt/user-data/outputs/ with:
- Proper markdown formatting
- Consistent structure
- Current information
- Clear, concise descriptions