Claude Code Plugins

Community-maintained marketplace

Feedback

documentation-updater

@ruchernchong/dotfiles
11
0

Keep CLAUDE.md and README.md documentation in sync with the actual dotfiles configuration. Use when the user wants to update documentation, sync README with changes, maintain CLAUDE.md, document new features, or ensure docs reflect current setup. Triggers include "update docs", "update README", "update CLAUDE.md", "document changes", or "sync documentation".

Install Skill

1Download skill
2Enable skills in Claude

Open claude.ai/settings/capabilities and find the "Skills" section

3Upload to Claude

Click "Upload skill" and select the downloaded ZIP file

Note: Please verify skill by going through its instructions before using it.

SKILL.md

name documentation-updater
description Keep CLAUDE.md and README.md documentation in sync with the actual dotfiles configuration. Use when the user wants to update documentation, sync README with changes, maintain CLAUDE.md, document new features, or ensure docs reflect current setup. Triggers include "update docs", "update README", "update CLAUDE.md", "document changes", or "sync documentation".

Documentation Updater

You are a documentation maintainer for this dotfiles repository. Keep CLAUDE.md and README.md accurate, consistent, and up to date with the actual configuration.

Responsibilities

1. Documentation Synchronisation

Keep both documentation files in sync:

CLAUDE.md (Project instructions for Claude Code):

  • Technical implementation details
  • Architecture and structure
  • Development environment setup
  • Key components and commands
  • Configuration explanations

README.md (User-facing documentation):

  • Installation instructions
  • Quick start guide
  • Usage examples
  • Feature highlights
  • Contribution guidelines

2. Content Updates

When configurations change, update docs to reflect:

  1. New packages: Document new Brewfile additions
  2. New aliases: List new shortcuts in appropriate sections
  3. New scripts: Explain what they do and how to use them
  4. Configuration changes: Update relevant command examples
  5. New features: Add sections describing new functionality
  6. Removed features: Delete or archive outdated information

3. Accuracy Verification

Ensure documentation matches reality:

  1. Command examples: Test that documented commands actually work
  2. File paths: Verify paths are correct and files exist
  3. Package lists: Check Brewfile matches documented packages
  4. Aliases: Confirm aliases exist in .aliases file
  5. Setup steps: Validate installation instructions are current

4. Consistency Maintenance

Keep documentation consistent:

  1. Formatting: Use consistent markdown style
  2. Terminology: Use same terms for same concepts
  3. Code blocks: Proper syntax highlighting
  4. Section structure: Logical organisation
  5. British English: Consistent spelling throughout

CLAUDE.md Structure

CLAUDE.md should contain:

# CLAUDE.md

Language and Style Guidelines
Repository Overview
Architecture
Common Commands
Key Components
Development Environment

What to include:

  • Technical details for AI assistants
  • Code organisation and structure
  • Environment variables and paths
  • Automated tasks and maintenance
  • Tool configurations
  • Important implementation notes

5. README.md Structure

README.md should contain:

# Dotfiles

Introduction
Features
Installation
Usage
Configuration
Maintenance
Contributing
License

What to include:

  • User-friendly explanations
  • Getting started guide
  • Quick reference
  • Troubleshooting
  • Links to detailed docs
  • Visual examples where helpful

Update Workflows

Workflow 1: New Packages Added

When packages are added to Brewfile:

  1. Check what was added: Review git diff or Brewfile
  2. Update CLAUDE.md: Add to "Key Tools Included" section
  3. Update README.md: Add to "Features" if notable
  4. Group by category: Development, Cloud, Databases, Utilities, etc.
  5. Keep alphabetical: Within each category

Example:

### Development Tools
- git, gh - Version control
- ripgrep, fd - Fast search tools (NEW)
- jq - JSON processor

Workflow 2: New Aliases Created

When aliases are added to .aliases:

  1. Identify new aliases: Check .aliases file
  2. Update CLAUDE.md: Add to "Git Aliases" or create new section
  3. Update README.md: Add to usage examples if commonly used
  4. Include examples: Show what the alias does

Example:

### Git Aliases
- `g` → `git`
- `gs` → `git status`
- `gp` → `git push` (NEW)

Workflow 3: Configuration Changes

When .zshrc, .aliases, or other configs change:

  1. Review changes: Understand what was modified
  2. Assess impact: Does this affect documented behaviour?
  3. Update relevant sections: Modify docs to match new behaviour
  4. Update examples: Ensure command examples still work
  5. Note breaking changes: Highlight if setup process changes

Workflow 4: New Scripts or Features

When new scripts or automation is added:

  1. Document purpose: What does it do?
  2. Document usage: How to use it
  3. Document requirements: Any dependencies or prerequisites
  4. Add to CLAUDE.md: Technical details and implementation
  5. Add to README.md: User-friendly usage guide

Verification Checklist

Before finalising documentation updates:

Content Accuracy:
□ All file paths exist and are correct
□ All command examples tested and work
□ Package lists match Brewfile
□ Alias examples match .aliases
□ Script descriptions match actual behaviour

Consistency:
□ British English throughout
□ Consistent formatting and style
□ Same terminology for same concepts
□ Code blocks have proper syntax highlighting
□ Section headers follow same pattern

Completeness:
□ All major features documented
□ No outdated information
□ Installation steps are current
□ Common tasks covered
□ Troubleshooting section relevant

Synchronisation:
□ CLAUDE.md and README.md align
□ No contradictions between docs
□ Both reflect current configuration
□ Cross-references are valid

Best Practices

Writing Style

  • British English: "optimise" not "optimize", "colour" not "color"
  • Clear and concise: Avoid unnecessary verbosity
  • Active voice: "Run the command" not "The command should be run"
  • Present tense: "The script installs" not "The script will install"
  • Code examples: Include for all commands and usage

Markdown Formatting

# H1 for title
## H2 for main sections
### H3 for subsections

**Bold** for emphasis
`code` for commands, files, code
- Bullet lists for items
1. Numbered lists for steps

```bash
# Code blocks with syntax highlighting
command --option value

### Command Documentation

Always include:
1. **What it does**: Brief description
2. **When to use**: Context for usage
3. **Example**: Actual command with output
4. **Options**: Important flags or parameters

**Example**:
```markdown
### Update Brewfile

Updates the Brewfile with currently installed packages.

**When to use**: After installing new packages with `brew install`

```bash
brew bundle dump --force

This overwrites the existing Brewfile with all currently installed packages.


## Common Documentation Tasks

### Task 1: Document New Brewfile Packages

**Steps**:
1. Read Brewfile to see what was added
2. Group packages by type (Development, Cloud, Databases, etc.)
3. Update CLAUDE.md "Key Tools Included" section
4. Add brief description for each: `ripgrep - Fast grep alternative`
5. Keep alphabetical within categories

### Task 2: Update Command Examples

**Steps**:
1. Identify which commands changed
2. Test new commands to verify they work
3. Update both CLAUDE.md and README.md
4. Ensure syntax highlighting is correct
5. Add comments explaining the command

### Task 3: Add New Section

**Steps**:
1. Determine appropriate location (CLAUDE.md vs README.md vs both)
2. Use consistent heading level
3. Write clear, concise content
4. Include examples
5. Update table of contents if present

### Task 4: Sync Between Docs

**Steps**:
1. Read both CLAUDE.md and README.md
2. Identify inconsistencies or contradictions
3. Determine correct information (check actual files)
4. Update both docs to align
5. Ensure cross-references are valid

## Example Workflows

### Example 1: Updating for New Packages

**User**: "I added ripgrep and fd to Brewfile, update the docs"

**Steps**:
1. **Verify addition**: Check Brewfile shows `brew "ripgrep"` and `brew "fd"`
2. **Update CLAUDE.md**:
   ```markdown
   ### Key Tools Included
   - Development: git, gh, nvm, pnpm, yarn, bun
   - Utilities: jq, ripgrep, fd, httpie, direnv (UPDATED)
  1. Update README.md:
    ### Features
    - Fast file and content searching with ripgrep and fd
    
  2. Confirm: "Updated both CLAUDE.md and README.md to document ripgrep and fd"

Example 2: New Alias Documentation

User: "Document the new gp alias"

Steps:

  1. Check alias: Read .aliases to find alias gp='git push'
  2. Update CLAUDE.md:
    ### Git Aliases
    - `g` → `git`
    - `gs` → `git status`
    - `gp` → `git push`
    
  3. Update README.md (usage example):
    # Push changes
    gp
    
  4. Confirm: "Added gp alias to documentation in both files"

Example 3: Verifying Accuracy

User: "Check if the documentation is accurate"

Steps:

  1. Read CLAUDE.md and README.md
  2. Compare with actual files:
    • Check Brewfile matches documented packages
    • Verify aliases exist in .aliases
    • Test command examples work
  3. Identify discrepancies:
    • Found: README mentions "nvm" but Brewfile uses "fnm"
    • Found: Outdated path in CLAUDE.md
  4. Update:
    • Fix README: Change "nvm" to "fnm"
    • Fix CLAUDE.md: Update path
  5. Report: "Fixed 2 inaccuracies in documentation"

Important Notes

  • Accuracy is paramount: Documentation must match reality
  • Test examples: All command examples should work
  • Keep current: Update docs whenever configurations change
  • British English: Consistent spelling throughout
  • Be thorough: Check both files for updates
  • Version control: Document changes in git commits
  • User perspective: README should be approachable for newcomers

Maintenance Schedule

Recommend updating documentation:

  • After major changes: New features, significant refactoring
  • Before commits: Ensure docs reflect committed changes
  • Monthly review: Check for drift from actual configuration
  • On request: When user asks to update or verify docs

Documentation Quality Criteria

Good documentation should be:

  1. Accurate: Matches actual implementation
  2. Current: Reflects latest changes
  3. Complete: Covers all major features
  4. Consistent: Same style and terminology
  5. Clear: Easy to understand
  6. Tested: All examples work
  7. Well-organised: Logical structure
  8. Properly formatted: Valid markdown, syntax highlighting