Initial commit

This commit is contained in:
Zhongwei Li
2025-11-29 18:18:08 +08:00
commit 8be7da7e40
4 changed files with 354 additions and 0 deletions

View File

@@ -0,0 +1,12 @@
{
"name": "dt-git",
"description": "Tools for interacting with git and github.",
"version": "0.1.0",
"author": {
"name": "Dan Turkel",
"email": "daturkel@gmail.com"
},
"skills": [
"./skills"
]
}

3
README.md Normal file
View File

@@ -0,0 +1,3 @@
# dt-git
Tools for interacting with git and github.

45
plugin.lock.json Normal file
View File

@@ -0,0 +1,45 @@
{
"$schema": "internal://schemas/plugin.lock.v1.json",
"pluginId": "gh:daturkel/dt-cc:plugins/dt-git",
"normalized": {
"repo": null,
"ref": "refs/tags/v20251128.0",
"commit": "2978bfdf0ffcd360abb928bde611a8eeea86bdfa",
"treeHash": "e02c0fb45f9c9af0352a34210d92836bf4d5209e3e610b15c1975d8915f39042",
"generatedAt": "2025-11-28T10:16:07.428212Z",
"toolVersion": "publish_plugins.py@0.2.0"
},
"origin": {
"remote": "git@github.com:zhongweili/42plugin-data.git",
"branch": "master",
"commit": "aa1497ed0949fd50e99e70d6324a29c5b34f9390",
"repoRoot": "/Users/zhongweili/projects/openmind/42plugin-data"
},
"manifest": {
"name": "dt-git",
"description": "Tools for interacting with git and github.",
"version": "0.1.0"
},
"content": {
"files": [
{
"path": "README.md",
"sha256": "0a0e325507dd25fc2a487569d044e4905dd761688af2a4b6b801ab863c8e643f"
},
{
"path": ".claude-plugin/plugin.json",
"sha256": "403ef2c2041cc5c35ff23e4e48acad45d9c1e88f55e785b50412584b0c7cfd8a"
},
{
"path": "skills/git-ops/SKILL.md",
"sha256": "12101ef5f59eb297b495dd2bce7cadf0d1dea410f27b0ca7ff7029888d92b808"
}
],
"dirSha256": "e02c0fb45f9c9af0352a34210d92836bf4d5209e3e610b15c1975d8915f39042"
},
"security": {
"scannedAt": null,
"scannerVersion": null,
"flags": []
}
}

294
skills/git-ops/SKILL.md Normal file
View File

@@ -0,0 +1,294 @@
---
name: git-ops
description: Get information about the state of a git repo, get diffs, make commits, make PRs, etc.. Use this skill when the user needs to accomplish git tasks.
allowed-tools:
- Bash(git:*)
- Bash(ls:*)
- Bash(pwd)
- Bash(gh:*)
---
# Git Operations Skill
This skill provides comprehensive git repository information for commits, PRs, and general repository status.
## Important: User Confirmation Required
**ALWAYS ask for user confirmation before**:
- Creating commits (`git commit`)
- Pushing to remote (`git push`)
- Creating pull requests (which includes pushing)
Use the `AskUserQuestion` tool to present the proposed action and get explicit approval before executing.
**These operations can be performed without confirmation**:
- Reading repository status (`git status`, `git diff`, `git log`, etc.)
- Staging files (`git add`)
- Creating/switching branches (`git branch`, `git checkout`)
- Fetching from remote (`git fetch`)
- All other read-only or local-only git operations
## Instructions
Follow these steps to gather and present git information:
### 1. Basic Repository Status
```bash
git status
```
This shows:
- Current branch name
- Tracking status (ahead/behind remote)
- Staged files (green)
- Unstaged files (red)
- Untracked files
### 2. Staged Changes (Ready for Commit)
```bash
git diff --cached --stat
```
Shows statistics of staged files.
```bash
git diff --cached
```
Shows full diff of what would be committed.
**Present**: Summarize the number of staged files and the nature of changes.
### 3. Unstaged Changes (Modified but Not Staged)
```bash
git diff --stat
```
Shows statistics of modified but unstaged files.
```bash
git diff
```
Shows full diff of unstaged changes.
**Present**: List files with unstaged modifications.
### 4. Creating Commits
When the user asks to create a commit:
1. **Gather information about changes**:
- Check what files would be committed
- Review the diffs to understand the changes
- Check recent commit history for message style: `git log --oneline -10`
2. **Draft commit message** based on recent history style:
- Keep it 1-2 sentences maximum
- Focus on "why" not "what"
- Follow the repository's commit message style
3. **Ask for confirmation using AskUserQuestion tool**:
- Present the proposed commit message
- Show what files will be committed
- Warn about sensitive files (.env, credentials.json, etc.) if present
- Ask user to approve, modify, or cancel
4. **If approved, create the commit**:
- If user said "commit all" or similar: stage everything with `git add .` first
- Otherwise only commit staged changes
- Create the commit: `git commit -m "Your concise commit message"`
**Important rules**:
- ALWAYS ask for confirmation before committing using the AskUserQuestion tool
- ALWAYS create NEW commits, NEVER use `--amend`
- If nothing staged and not staging all, inform user (don't create empty commit)
- User must explicitly approve the commit before executing it
### 5. Recent Commit History
```bash
git log --oneline -10
```
Shows last 10 commits for context on commit message style.
### 6. Branch Comparison (For PR Context)
Show changes since branching:
```bash
git diff main...HEAD --stat
```
Statistics of all changes from base branch.
```bash
git log main..HEAD --oneline
```
All commits that would be in a PR.
```bash
git diff main...HEAD
```
Full diff for PR review (use sparingly, can be large).
### 7. Remote Status
```bash
git rev-list --left-right --count HEAD...@{upstream} 2>/dev/null || echo "No upstream configured"
```
Shows how many commits ahead/behind the remote.
### 8. Creating Pull Requests with `gh` CLI
When the user asks to create a PR, follow these steps:
1. **Verify branch status**:
```bash
git branch --show-current
git status
```
- If on main/master, warn user and don't create PR
- Check if branch needs to be pushed
2. **Understand the full scope of changes** from when the branch diverged:
```bash
git log origin/main...HEAD --oneline
git diff origin/main...HEAD --stat
git diff origin/main
```
- If no commits ahead of default branch, inform user
3. **Draft PR title and description** based on all changes:
- Analyze ALL commits and the full diff, not just the latest commit
- Draft a concise title (50 chars or less)
- Create a detailed summary with:
- What was changed and why
- Major changes as bullet points
- Focus on "why" and user impact
4. **Ask for confirmation using AskUserQuestion tool**:
- Present the proposed PR title and description
- Show summary of files changed and commits included
- Confirm that user wants to push (if needed) and create PR
- Allow user to approve, modify, or cancel
5. **If approved, push to remote if needed**:
```bash
git push -u origin $(git branch --show-current)
```
6. **Create PR with `gh` CLI**:
```bash
gh pr create --title "Concise title (50 chars or less)" --body "$(cat <<'EOF'
## Summary
Detailed explanation of the major changes, what was modified, and why.
Analyze ALL commits and the full diff, not just the latest commit.
- Major change 1
- Major change 2
- etc.
Focus on the "why" and user impact, not just the "what".
EOF
)"
```
7. **Return the PR URL** when done
**Important notes**:
- ALWAYS ask for confirmation before pushing and creating PR using the AskUserQuestion tool
- Analyze ALL commits that will be included, not just the latest one
- Use HEREDOC format for the body to ensure proper formatting
- Do NOT use the Task or TodoWrite tools when creating PRs
- Adapt base branch name (try `main`, `master`, `origin/main`, etc.)
- User must explicitly approve before pushing to remote
## Presenting Information
Organize your response based on what the user needs:
### For Commit Questions
- **Staged files**: List files ready to commit with brief summary
- **Commit message suggestion**: Based on changes and recent history
- **Warnings**: Flag any concerns (large files, potential secrets)
### For PR Questions
- **Branch comparison**: Summarize all changes since base branch
- **Commit list**: Show commits that would be included
- **Files changed**: List all modified files with stats
- **Create PR**: Use `gh pr create` to create the PR with appropriate title and description
- **PR description template**: If only describing, suggest title and description
### For General Status
- **Current state**: Branch name, tracking status
- **Staged vs unstaged**: Clear breakdown of what's where
- **Next steps**: Actionable suggestions
## Best Practices
1. **Be concise**: The user is experienced, provide summaries not explanations
2. **Adapt base branch**: Try `main`, `master`, `develop` as needed
3. **Handle errors gracefully**: Not all repos have remotes or follow conventions
4. **Skip noise**: Ignore lock files, build artifacts in summaries
5. **Security awareness**: Flag potential secrets or sensitive files
## Examples
### Example 1: Commit message for staged changes
**User**: "Write a commit message"
```bash
git diff --cached --stat
git diff --cached
git log --oneline -10
```
**Response**:
```
Staged: 3 files (parser.py, test_parser.py, README.md)
Suggested commit message:
"Add config parser with tests and documentation"
```
### Example 2: Commit message for unstaged changes
**User**: "Commit my changes"
```bash
git status
git diff --stat
git diff
git log --oneline -10
```
Draft commit message based on changes, then ask for confirmation:
- Use AskUserQuestion to present: "Add config parser with tests"
- Show files that will be committed
- After approval, stage and commit:
```bash
git add -u
git commit -m "Add config parser with tests"
```
### Example 3: PR description for branch
**User**: "Write a PR description"
```bash
git log main..HEAD --oneline
git diff main...HEAD --stat
git diff main...HEAD
```
**Response**:
```
**Add configuration parser with validation**
Implements config parsing and validation system.
- Added parse_config() for YAML/JSON parsing
- Added validate_config() with schema validation
- Full test coverage for both modules
- Updated docs with examples
6 files changed: +365 -8
```