Mike Swanson
0e119ce30d
Removed deprecated database context save functionality from /checkpoint: - Deleted Part 2: Database Context Save section - Removed API endpoint, JWT auth, and payload examples - Updated description to focus on git operations only - Simplified verification to git commit only - Kept directives refresh requirement Checkpoint command now handles git commits exclusively. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
67 lines
2.5 KiB
Markdown
67 lines
2.5 KiB
Markdown
---
|
|
description: Create detailed git commit with comprehensive commit message
|
|
---
|
|
|
|
Please create a comprehensive git checkpoint with the following steps:
|
|
|
|
## Part 1: Git Checkpoint
|
|
|
|
1. **Initialize Git if needed**: Run `git init` if git has not been instantiated for the project yet.
|
|
|
|
2. **Analyze all changes**:
|
|
|
|
- Run `git status` to see all tracked and untracked files
|
|
- Run `git diff` to see detailed changes in tracked files
|
|
- Run `git log -5 --oneline` to understand the commit message style of this repository
|
|
|
|
3. **Stage everything**:
|
|
|
|
- Add ALL tracked changes (modified and deleted files)
|
|
- Add ALL untracked files (new files)
|
|
- Use `git add -A` or `git add .` to stage everything
|
|
|
|
4. **Create a detailed commit message**:
|
|
|
|
- **First line**: Write a clear, concise summary (50-72 chars) describing the primary change
|
|
- Use imperative mood (e.g., "Add feature" not "Added feature")
|
|
- Examples: "feat: add user authentication", "fix: resolve database connection issue", "refactor: improve API route structure"
|
|
- **Body**: Provide a detailed description including:
|
|
- What changes were made (list of key modifications)
|
|
- Why these changes were made (purpose/motivation)
|
|
- Any important technical details or decisions
|
|
- Breaking changes or migration notes if applicable
|
|
- **Footer**: Include co-author attribution as shown in the Git Safety Protocol
|
|
|
|
5. **Execute the commit**: Create the commit with the properly formatted message following this repository's conventions.
|
|
|
|
## Part 2: Verify Git Checkpoint
|
|
|
|
6. **Verify commit**:
|
|
- Confirm git commit succeeded by running `git log -1`
|
|
- Report commit status to user
|
|
|
|
## Part 3: Refresh Directives (MANDATORY)
|
|
|
|
7. **Refresh directives** (MANDATORY):
|
|
- After checkpoint completion, auto-invoke `/refresh-directives`
|
|
- Re-read `directives.md` to prevent shortcut-taking
|
|
- Perform self-assessment for any violations
|
|
- Confirm commitment to agent coordination rules
|
|
- Report directives refreshed to user
|
|
|
|
## Benefits of Git Checkpoint
|
|
|
|
**Git Checkpoint provides:**
|
|
- Code versioning
|
|
- Change history
|
|
- Rollback capability
|
|
- Complete project memory over time
|
|
- Collaboration support through detailed commit messages
|
|
|
|
## IMPORTANT
|
|
|
|
- Do NOT skip any files - include everything
|
|
- Make the commit message descriptive enough that someone reviewing the git log can understand what was accomplished
|
|
- Follow the project's existing commit message conventions (check git log first)
|
|
- Include the Claude Code co-author attribution in the commit message
|