Initial commit
This commit is contained in:
Zhongwei Li
104
commands/commit.md
Normal file
104
commands/commit.md
Normal file
@@ -0,0 +1,104 @@
|
||||
---
|
||||
description: Create git commits for changes made during the current session
|
||||
allowed-tools: Bash(git status:*), Bash(git diff:*), Bash(git add:*), Bash(git commit:*), Task, AskUserQuestion
|
||||
model: claude-haiku-4-5
|
||||
---
|
||||
|
||||
# Commit Changes
|
||||
|
||||
You are executing the `/commit` command. Follow these steps precisely:
|
||||
|
||||
## Overview
|
||||
|
||||
This command creates git commits for changes made during the current session. It delegates the analysis and commit creation to a general-purpose agent to avoid polluting the main conversation context.
|
||||
|
||||
## Step 1: Extract Conversation Context
|
||||
|
||||
Before delegating to the agent, analyze the conversation history to extract:
|
||||
- What tasks/features were discussed and implemented
|
||||
- Which files were mentioned or modified during implementation
|
||||
- Any specific intents or goals stated by the user
|
||||
- Whether multiple distinct tasks were worked on
|
||||
|
||||
Create a concise summary (2-4 sentences) of the session's work.
|
||||
|
||||
## Step 2: Delegate to Agent
|
||||
|
||||
Launch a general-purpose agent with the Task tool using the claude-haiku-4-5 model for efficiency, providing:
|
||||
|
||||
**Prompt structure:**
|
||||
```
|
||||
You are helping create git commits for a coding session.
|
||||
|
||||
Session context:
|
||||
[Include the summary from Step 1]
|
||||
|
||||
Your tasks:
|
||||
1. Analyze changes: Run git status and git diff to see all changes. Based on the session context above, identify which changes are relevant to commit.
|
||||
|
||||
2. Commit strategy: If multiple distinct tasks were detected from the session context, ask the user using AskUserQuestion tool:
|
||||
- Question 1: "How should I commit these changes?"
|
||||
- "Single commit" - Commit all changes together
|
||||
- "Multiple logical commits" - Create separate commits for each distinct task/feature
|
||||
|
||||
- Question 2 (only if unstaged/untracked files exist that weren't part of the session work):
|
||||
"There are uncommitted changes not made in this session. Include them?"
|
||||
- "Yes, include all changes" - Stage and commit everything
|
||||
- "No, only session changes" - Commit only files from this session
|
||||
- "Let me review first" - Show list of files and stop
|
||||
|
||||
3. Create commits following these rules:
|
||||
- Style: Concise, factual, savant-like. State what was done, not why (unless discussed during implementation)
|
||||
- Simple changes: Title only (no description)
|
||||
- Complex changes: Title + description with context about what was changed
|
||||
- Use facts, avoid self-praise adjectives ("improved", "optimized", "enhanced")
|
||||
- Hard limit: 80 words total
|
||||
- Format: Always use heredoc for commit message
|
||||
|
||||
Examples:
|
||||
```bash
|
||||
# Simple change
|
||||
git commit -m "$(cat <<'EOF'
|
||||
Add user authentication middleware
|
||||
EOF
|
||||
)"
|
||||
|
||||
# Complex change
|
||||
git commit -m "$(cat <<'EOF'
|
||||
Refactor database connection pooling
|
||||
|
||||
Extracted connection logic into separate module. Added retry mechanism
|
||||
for failed connections. Configured pool size based on environment variables.
|
||||
EOF
|
||||
)"
|
||||
```
|
||||
|
||||
If creating multiple logical commits:
|
||||
- Create commits in chronological order of implementation
|
||||
- Each commit should be self-contained and logical
|
||||
- Follow same message rules for each commit
|
||||
|
||||
4. Return the following information:
|
||||
- Commit SHA(s)
|
||||
- Full commit message(s) for each commit created
|
||||
```
|
||||
|
||||
## Step 3: Display Results
|
||||
|
||||
After the agent completes, display the output:
|
||||
- List each commit SHA with its full commit message
|
||||
- Confirm total number of commits created
|
||||
|
||||
Example output format:
|
||||
```
|
||||
Created 1 commit:
|
||||
|
||||
abc123d - Add user authentication middleware
|
||||
```
|
||||
|
||||
## Error Handling
|
||||
|
||||
If the agent reports any failures:
|
||||
1. Display the error message clearly
|
||||
2. Ask user if they want to retry or need assistance
|
||||
3. Do not attempt automatic fixes in the main conversation
|
||||
150
commands/open-pr.md
Normal file
150
commands/open-pr.md
Normal file
@@ -0,0 +1,150 @@
|
||||
---
|
||||
description: Create commits, push branch, and open a pull request on GitHub
|
||||
argument-hint: [draft]
|
||||
allowed-tools: Bash(git status:*), Bash(git diff:*), Bash(git add:*), Bash(git commit:*), Bash(git push:*), Bash(git branch:*), Bash(git checkout:*), Bash(gh pr create:*), Bash(xdg-open:*), AskUserQuestion
|
||||
model: claude-haiku-4-5
|
||||
---
|
||||
|
||||
# Open Pull Request
|
||||
|
||||
You are executing the `/open-pr` command. Follow these steps precisely:
|
||||
|
||||
## Parameters
|
||||
- `draft` (optional): Create PR as draft if specified (e.g., `/open-pr draft`)
|
||||
|
||||
## Step 0: Branch Check
|
||||
|
||||
**CRITICAL: Run this check FIRST before any other steps.**
|
||||
|
||||
Check current branch with `git branch --show-current`.
|
||||
|
||||
**If on main or master branch:**
|
||||
1. Analyze changes briefly to understand what was modified/added
|
||||
2. Generate 4 best-effort branch name suggestions based on changes:
|
||||
- Use format: `feature/descriptive-name`, `fix/descriptive-name`, or `refactor/descriptive-name`
|
||||
- Make names concise but descriptive (2-4 words max)
|
||||
- Vary the suggestions to give different perspectives on the changes
|
||||
3. Ask user to choose branch name using AskUserQuestion:
|
||||
- Question: "You're on the main/master branch. Choose a branch name:"
|
||||
- Options: Present the 4 generated branch names as options
|
||||
- Note: User can always select "Other" to provide custom branch name
|
||||
4. Create and checkout new branch: `git checkout -b <chosen-branch-name>`
|
||||
|
||||
**If on any other branch:** Proceed to Step 1.
|
||||
|
||||
## Step 1: Analyze Changes
|
||||
|
||||
Run `git status` and `git diff` to analyze all changes:
|
||||
- Identify files modified/created by Claude in current session
|
||||
- Identify unstaged/untracked files NOT modified by Claude
|
||||
- Review conversation context to detect if session involved multiple distinct tasks (separate features, fixes, or refactorings discussed/implemented)
|
||||
|
||||
## Step 2: Commit Strategy Questions
|
||||
|
||||
If you detect multiple distinct tasks from conversation context, ask user using AskUserQuestion tool (both questions in same group):
|
||||
|
||||
**Question 1** (always ask if multiple tasks detected):
|
||||
- "How should I commit these changes?"
|
||||
- "Single commit" - Commit all changes together
|
||||
- "Multiple logical commits" - Create separate commits for each distinct task/feature
|
||||
|
||||
**Question 2** (ask ONLY if unstaged/untracked files exist that Claude didn't modify):
|
||||
- "There are uncommitted changes not made in this session. Include them?"
|
||||
- "Yes, include all changes" - Stage and commit everything
|
||||
- "No, only Claude's changes" - Commit only files Claude modified
|
||||
- "Let me review first" - Show list of files and stop
|
||||
|
||||
## Step 3: Create Commits
|
||||
|
||||
**Commit Message Rules:**
|
||||
- **Style**: Concise, factual, savant-like. State what was done, not why (unless discussed during implementation)
|
||||
- **Simple changes**: Title only (no description)
|
||||
- **Complex changes**: Title + description
|
||||
- Description adds context about what was changed
|
||||
- Use facts, avoid self-praise adjectives ("improved", "optimized", "enhanced")
|
||||
- Only state intents if explicitly discussed during implementation
|
||||
- **Hard limit**: 80 words total
|
||||
- **Format**: Always use heredoc for commit message
|
||||
|
||||
**Examples:**
|
||||
```bash
|
||||
# Simple change
|
||||
git commit -m "$(cat <<'EOF'
|
||||
Add user authentication middleware
|
||||
EOF
|
||||
)"
|
||||
|
||||
# Complex change
|
||||
git commit -m "$(cat <<'EOF'
|
||||
Refactor database connection pooling
|
||||
|
||||
Extracted connection logic into separate module. Added retry mechanism
|
||||
for failed connections. Configured pool size based on environment variables.
|
||||
EOF
|
||||
)"
|
||||
```
|
||||
|
||||
If creating multiple logical commits:
|
||||
- Create commits in chronological order of implementation
|
||||
- Each commit should be self-contained and logical
|
||||
- Follow same message rules for each commit
|
||||
|
||||
## Step 4: Push Branch
|
||||
|
||||
Check if force-push is needed (`git status` shows diverged branch).
|
||||
|
||||
**If force-push required**: Ask user for confirmation before proceeding.
|
||||
|
||||
**Otherwise**: Auto-push with `git push -u origin <branch-name>`
|
||||
|
||||
**On push failure**: Explain error and ask if you should retry with alternative approach.
|
||||
|
||||
## Step 5: Create Pull Request
|
||||
|
||||
**PR Title**: Use title from commit message (if single commit) or summarize all commits (if multiple)
|
||||
|
||||
**PR Description Rules:**
|
||||
- **Always include description** (even for simple changes)
|
||||
- Same style as commit messages: factual, concise, savant-like
|
||||
- For single commit: Expand on commit message with more context
|
||||
- For multiple commits: List key changes made across commits
|
||||
- Avoid self-praise language, state facts only
|
||||
- **Hard limit**: 150 words
|
||||
|
||||
**PR Metadata:**
|
||||
- Auto-detect default branch (main/master) as base
|
||||
- If `draft` parameter passed: add `--draft` flag
|
||||
- No labels/reviewers unless user specifies
|
||||
|
||||
**Create PR:**
|
||||
```bash
|
||||
gh pr create --title "PR title" --body "$(cat <<'EOF'
|
||||
PR description content here.
|
||||
EOF
|
||||
)" [--draft]
|
||||
```
|
||||
|
||||
**On PR creation failure**: Explain error and ask if you should retry with alternative approach.
|
||||
|
||||
## Step 6: Open PR Page
|
||||
|
||||
After successful PR creation, extract PR URL from `gh` output and open it:
|
||||
```bash
|
||||
xdg-open <PR_URL>
|
||||
```
|
||||
|
||||
## Error Handling
|
||||
|
||||
If any step fails:
|
||||
1. Explain what went wrong clearly
|
||||
2. Provide the specific error message
|
||||
3. Ask user if you should retry with an alternative approach
|
||||
4. If user confirms, attempt automatic fix or provide manual commands
|
||||
|
||||
## Final Output
|
||||
|
||||
After successful completion, output:
|
||||
- Commit SHA(s)
|
||||
- Branch name
|
||||
- PR URL
|
||||
- Confirmation that PR page was opened
|
||||
Reference in New Issue
Block a user