Initial commit
This commit is contained in:
13
.claude-plugin/plugin.json
Normal file
13
.claude-plugin/plugin.json
Normal file
@@ -0,0 +1,13 @@
|
||||
{
|
||||
"name": "dev-utils",
|
||||
"description": "Utility commands and skill for general development",
|
||||
"version": "1.0.0",
|
||||
"author": {
|
||||
"name": "Simon Kelly",
|
||||
"email": "skelly@dimagi.com",
|
||||
"url": "https://github.com/dimagi"
|
||||
},
|
||||
"commands": [
|
||||
"./commands"
|
||||
]
|
||||
}
|
||||
3
README.md
Normal file
3
README.md
Normal file
@@ -0,0 +1,3 @@
|
||||
# dev-utils
|
||||
|
||||
Utility commands and skill for general development
|
||||
44
commands/commit.md
Normal file
44
commands/commit.md
Normal file
@@ -0,0 +1,44 @@
|
||||
---
|
||||
description: Create git commits with user approval and no Claude attribution
|
||||
---
|
||||
|
||||
# Commit Changes
|
||||
|
||||
You are tasked with creating git commits.
|
||||
|
||||
## Process:
|
||||
|
||||
1. **Think about what changed:**
|
||||
- Review the conversation history and understand what was accomplished
|
||||
- Run `git status` to see current changes
|
||||
- Run `git diff` to understand the modifications
|
||||
- Consider whether changes should be one commit or multiple logical commits
|
||||
|
||||
2. **Plan your commit(s):**
|
||||
- Identify which files belong together
|
||||
- Draft clear, descriptive commit messages
|
||||
- Use imperative mood in commit messages
|
||||
- Focus on why the changes were made, not just what
|
||||
|
||||
3. **Present your plan to the user:**
|
||||
- List the files you plan to add for each commit
|
||||
- Show the commit message(s) you'll use
|
||||
- Ask: "I plan to create [N] commit(s) with these changes. Shall I proceed?"
|
||||
|
||||
4. **Execute upon confirmation:**
|
||||
- Use `git add` with specific files (never use `-A` or `.`)
|
||||
- Create commits with your planned messages
|
||||
- Show the result with `git log --oneline -n [number]`
|
||||
|
||||
## Important:
|
||||
- **NEVER add co-author information or Claude attribution**
|
||||
- Commits should be authored solely by the user
|
||||
- Do not include any "Generated with Claude" messages
|
||||
- Do not add "Co-Authored-By" lines
|
||||
- Write commit messages as if the user wrote them
|
||||
|
||||
## Remember:
|
||||
- You have the full context of what was done in this session
|
||||
- Group related changes together
|
||||
- Keep commits focused and atomic when possible
|
||||
- The user trusts your judgment - they asked you to commit
|
||||
60
commands/describe_pr.md
Normal file
60
commands/describe_pr.md
Normal file
@@ -0,0 +1,60 @@
|
||||
---
|
||||
description: Generate comprehensive PR descriptions following repository templates
|
||||
allowed-tools: Bash(gh pr view:*), Bash(gh pr diff:*), Bash(gh pr list:*), Bash(gh pr checks:*)
|
||||
argument-hint: [PR number]
|
||||
---
|
||||
|
||||
# Generate PR Description
|
||||
|
||||
You are tasked with generating a comprehensive pull request description following the repository's standard template.
|
||||
|
||||
**Usage**: /describe_pr $1
|
||||
|
||||
## If no PR number is provided, identify the PR to describe
|
||||
- Check if the current branch has an associated PR: `gh pr view --json url,number,title,state 2>/dev/null`
|
||||
- If no PR exists for the current branch, or if on main/master, list open PRs: `gh pr list --limit 10 --json number,title,headRefName,author`
|
||||
- Ask the user which PR they want to describe
|
||||
|
||||
## Steps to follow:
|
||||
|
||||
1. **Read the PR description template:**
|
||||
- Read the template at `.github/pull_request_template.md` carefully to understand all sections and requirements
|
||||
|
||||
2. **Gather comprehensive PR information:**
|
||||
- Get the full PR diff: `gh pr diff {number}`
|
||||
- If you get an error about no default remote repository, instruct the user to run `gh repo set-default` and select the appropriate repository
|
||||
- Get commit history: `gh pr view {number} --json commits`
|
||||
- Review the base branch: `gh pr view {number} --json baseRefName`
|
||||
- Get PR metadata: `gh pr view {number} --json url,title,number,state`
|
||||
|
||||
3. **Analyze the changes thoroughly:** (ultrathink about the code changes, their architectural implications, and potential impacts)
|
||||
- Read through the entire diff carefully
|
||||
- For context, read any files that are referenced but not shown in the diff
|
||||
- Understand the purpose and impact of each change
|
||||
- Identify user-facing changes vs internal implementation details
|
||||
- Look for breaking changes or migration requirements
|
||||
|
||||
4. **Generate the description:**
|
||||
- Fill out each section from the template thoroughly:
|
||||
- Answer each question/section based on your analysis
|
||||
- Be specific about problems solved and changes made
|
||||
- Focus on user impact where relevant
|
||||
- Include technical details in appropriate sections
|
||||
- Write a concise changelog entry
|
||||
- Ensure all checklist items are addressed (checked or explained)
|
||||
|
||||
5. **Save the description:**
|
||||
- Write the completed description to `{number}_description.md` (DO NOT COMMIT THIS FILE)
|
||||
- Show the user the generated description
|
||||
|
||||
6. **Update the PR:**
|
||||
- Update the PR description directly: `gh pr edit {number} --body-file {number}_description.md`
|
||||
- This requires the 'project' GitHub scope. If the command fails you can check the scope with `gh auth status`.
|
||||
|
||||
## Important notes:
|
||||
- Be thorough but concise - descriptions should be scannable
|
||||
- Focus on the "why" as much as the "what"
|
||||
- Include any breaking changes or migration notes prominently
|
||||
- If the PR touches multiple components, organize the description accordingly
|
||||
- Always attempt to run verification commands when possible
|
||||
- Clearly communicate which verification steps need manual testing
|
||||
49
plugin.lock.json
Normal file
49
plugin.lock.json
Normal file
@@ -0,0 +1,49 @@
|
||||
{
|
||||
"$schema": "internal://schemas/plugin.lock.v1.json",
|
||||
"pluginId": "gh:dimagi/claude-plugins:plugins/dev_utils",
|
||||
"normalized": {
|
||||
"repo": null,
|
||||
"ref": "refs/tags/v20251128.0",
|
||||
"commit": "e193b24b717e99edc3b60bc6002013c038d5cb78",
|
||||
"treeHash": "092b9f0f35c5ecb08fcc47d1a039c6edf7cc3a78267b6ddc3cb4ea16b821ec79",
|
||||
"generatedAt": "2025-11-28T10:16:27.271060Z",
|
||||
"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": "dev-utils",
|
||||
"description": "Utility commands and skill for general development",
|
||||
"version": "1.0.0"
|
||||
},
|
||||
"content": {
|
||||
"files": [
|
||||
{
|
||||
"path": "README.md",
|
||||
"sha256": "023fda4868343a9089bdd932750566da38ae59b7f1c19825ad917028c586f607"
|
||||
},
|
||||
{
|
||||
"path": ".claude-plugin/plugin.json",
|
||||
"sha256": "35d265bd9c0850c558d41a4ad8f66ea96406eed58029fddbd1d7b019d6b4e07e"
|
||||
},
|
||||
{
|
||||
"path": "commands/describe_pr.md",
|
||||
"sha256": "d2d8e96fdaea92c6fa6a3ac2f1ce33afd8388a3f2acc97edcd1f09eeafc2099f"
|
||||
},
|
||||
{
|
||||
"path": "commands/commit.md",
|
||||
"sha256": "3a6af64fae0fe0aa14cc3fcd664d3e00496c896d93e6b147ed3bd621d1f9f7a3"
|
||||
}
|
||||
],
|
||||
"dirSha256": "092b9f0f35c5ecb08fcc47d1a039c6edf7cc3a78267b6ddc3cb4ea16b821ec79"
|
||||
},
|
||||
"security": {
|
||||
"scannedAt": null,
|
||||
"scannerVersion": null,
|
||||
"flags": []
|
||||
}
|
||||
}
|
||||
Reference in New Issue
Block a user