Draft a Commit

Create a thoughtful, supportive commit message from your staged changes.

Welcome

Writing good commit messages is an art. This skill helps you capture the essence of your changes in a clear, inviting way that your future self (and teammates) will appreciate.

Your staged changes tell a story. Let's write that story together.

What You're Doing

You're about to:

1. •Review what you've staged
2. •Understand the nature of your changes
3. •Create a commit message that captures both what AND why
4. •Copy that message and use it when you commit

How It Works

Step 1: Analyzing Staged Changes

First, we'll look at your staged changes using git diff --cached.

This shows us:

• •What files changed: Which files did you touch?
• •What changed in them: Added lines? Deleted? Refactored?
• •Patterns: Can we detect what you were working on?

Step 2: Understanding Intent

From the changes, we infer:

• •Type of work: Feature? Bug fix? Refactoring? Documentation?
• •Scope: Which part of the system?
• •Impact: What improves? What does this enable?

Step 3: Drafting the Message

We craft a message that:

• •Is specific: Not "Update files" but "Add StandardsRepository abstraction"
• •Explains why: Not just what changed, but why it matters
• •Shows confidence: Your changes are worth celebrating
• •Invites understanding: Future readers will understand your intent

Step 4: Sharing with You

We display the drafted message so you can:

• •Review it
• •Copy it
• •Use it in your git commit command

Configuration

Loading Configuration

The skill reads from .claude/skills/draft-commit/config.json:

• •style: How the message sounds ("supportive" or "concise")
• •format: Message structure ("descriptive" or "conventional")
• •messageLength: How much detail ("concise" or "detailed")
• •includeContext: Add explanatory context (true/false)
• •includeFileCounts: Show file/line counts (true/false)

Customizing Behavior

Edit config.json to change defaults:

{
  "style": "supportive",         // or "concise"
  "format": "descriptive",       // or "conventional"
  "messageLength": "concise",    // or "detailed"
  "includeContext": true,
  "includeFileCounts": true
}

Process

Get Staged Changes

Run: git diff --cached
Returns: All staged changes in unified diff format

Categorize Changes

Analyze the diff to understand:

• •Added files, deleted files, modified files
• •Lines added, lines deleted
• •Change patterns (new feature, bug fix, refactoring, docs, etc.)

Infer Work Type

From patterns, detect:

• •feat — New functionality
• •fix — Bug fixes
• •docs — Documentation changes
• •refactor — Code structure improvements
• •test — Test additions/changes
• •chore — Dependency updates, config changes
• •style — Formatting, cleanup
• •perf — Performance improvements

Determine Scope

Identify what part of the system:

• •Components affected
• •Modules changed
• •Features impacted

Draft the Message

For Supportive Style + Descriptive Format

Template:

[Brief description of what you did]

[Why this matters — what improves or what it enables]

[Optional: More context if helpful]

[Optional: File counts if configured]

Example:

Add StandardsRepository abstraction

Centralizes standards access into a single, reliable interface.
This eliminates duplication and makes the system easier to maintain.

Files:
- Added: lib/standards-repository.md, lib/schemas/standards-schema.json
- Modified: 7 agent/skill files updated to use new pattern

Why: Standards were scattered across multiple files, creating duplication
and coupling. Now there's one clear way to access standards with validation.

For Concise Style

Template:

[Concise description]

[Brief context if needed]

Example:

Centralize standards access

Standards scattered across 7 files now use single repository pattern.

For Conventional Format

Template:

[type]: [description]

[Why this matters / additional context]

Example:

refactor: Centralize standards access with repository pattern

Consolidates standards loading into single interface.
Eliminates duplication and improves testability.

Output Format

The skill displays the drafted message like this:

## 📝 Drafted Commit Message

[The actual message, ready to copy]

---

## How to Use It

1. Copy the message above
2. Stage your changes: `git add .` (or select specific files)
3. Create the commit: `git commit -m "your message"`

Or paste into your editor's commit message prompt.

---

**Changes analyzed**:
- [X files] changed
- [+Y lines] added
- [-Z lines] deleted

Important Notes

What This Does

• •Analyzes your staged changes only
• •Drafts a message for you to review
• •Shows the message in chat for easy copying
• •Does NOT commit automatically

What This Doesn't Do

• •Does NOT make the commit (you do that)
• •Does NOT stage changes (you do that)
• •Does NOT modify your repository

Why This Matters

This keeps you in control. You:

1. •Stage your changes carefully
2. •See what we're proposing
3. •Decide if it's right
4. •Make the commit yourself

Error Handling

If we encounter issues:

• •No staged changes: We'll let you know and suggest staging first
• •Unclear intent: We'll ask for clarification or offer suggestions
• •Config issues: We'll use defaults and let you know

Tips for Great Commit Messages

1. •Stage intentionally: Group related changes together
2. •Small commits: Easier to understand and review
3. •Specific: "Add validation" not "Update files"
4. •Why matters: Explain the reasoning, not just the changes
5. •Present tense: "Add feature" not "Added feature"

Examples

Example 1: Feature Addition

Staged changes: New function + tests + docs

Drafted message:

Add user authentication module

Implements JWT-based authentication for API.
Includes token generation, validation, and refresh logic.

Files:
- auth/jwt-handler.ts (main implementation)
- auth/__tests__/jwt-handler.test.ts (comprehensive tests)
- docs/AUTHENTICATION.md (usage guide)

Why: Enables secure API access. Provides foundation for role-based access control.

Example 2: Bug Fix

Staged changes: Fixed bug in error handler

Drafted message:

Fix error handling in API response middleware

Error messages weren't being properly serialized, causing 500 errors
to appear as malformed JSON. Now returns clean error objects.

Files:
- middleware/error-handler.ts (fixed serialization)
- __tests__/error-handler.test.ts (added test case)

This fixes issue #245.

Example 3: Documentation

Staged changes: Added README and guides

Drafted message:

Document setup and deployment process

Adds comprehensive guides for:
- Local development setup
- Running tests
- Building for production
- Deployment procedures

Files:
- SETUP.md (new)
- DEPLOYMENT.md (new)
- README.md (updated with links)

Why: New contributors need clear guidance. This reduces time to productivity.

Configuration Examples

For Conventional Commits

{
  "style": "concise",
  "format": "conventional",
  "messageLength": "concise",
  "includeContext": true,
  "includeFileCounts": false
}

Output: feat: Add authentication module

For Detailed Messages

{
  "style": "supportive",
  "format": "descriptive",
  "messageLength": "detailed",
  "includeContext": true,
  "includeFileCounts": true
}

Output: Long, detailed message with full context

For Concise Updates

{
  "style": "concise",
  "format": "descriptive",
  "messageLength": "concise",
  "includeContext": false,
  "includeFileCounts": false
}

Output: Brief, to-the-point message

Troubleshooting

Q: What if I staged wrong changes? A: Unstage them with git reset HEAD <file> and run /dac again.

Q: Can I edit the drafted message? A: Absolutely! Copy it, edit it, and use your version. It's a draft!

Q: Does this work with conventional commits? A: Yes! Set format: "conventional" in config.json.

Q: Can I configure it differently per project? A: Yes! Each project's config.json is independent. Just edit the file.

Integration with HQB

This skill demonstrates HQB patterns:

• •Supportive tone: Guides without judgment
• •Focused clarity: One clear purpose
• •Considerate approach: Respects your autonomy
• •Skill architecture: Reusable, configurable logic

Next Steps After Using This

1. •Copy the drafted message
2. •Review your changes one more time
3. •Make your commit with git commit -m "your message"
4. •Continue building awesome things!