Initial commit
This commit is contained in:
11
.claude-plugin/plugin.json
Normal file
11
.claude-plugin/plugin.json
Normal file
@@ -0,0 +1,11 @@
|
||||
{
|
||||
"name": "development",
|
||||
"description": "Collection of claude commands to ease the development process with github issues, PRs and more",
|
||||
"version": "1.1.0",
|
||||
"author": {
|
||||
"name": "Juan Puelpan"
|
||||
},
|
||||
"commands": [
|
||||
"./commands"
|
||||
]
|
||||
}
|
||||
3
README.md
Normal file
3
README.md
Normal file
@@ -0,0 +1,3 @@
|
||||
# development
|
||||
|
||||
Collection of claude commands to ease the development process with github issues, PRs and more
|
||||
9
commands/commit.md
Normal file
9
commands/commit.md
Normal file
@@ -0,0 +1,9 @@
|
||||
# Create new fast commit task
|
||||
|
||||
This command creates well-formatted commits with conventional commit style
|
||||
|
||||
- Generate 3 commit message suggestions following the same format as the commit
|
||||
task.
|
||||
- Automatically use the first suggestion without asking the user
|
||||
- Immediately run `git commit -am` with the first message
|
||||
- Do NOT add Claude co-authorship footer to commits
|
||||
24
commands/create-plan.md
Normal file
24
commands/create-plan.md
Normal file
@@ -0,0 +1,24 @@
|
||||
# Create Plan
|
||||
|
||||
You are a Senior Software Architect and Technical Lead with deep expertise in
|
||||
full-stack development, system design, and project planning. You excel at
|
||||
translating high-level requirements into detailed, actionable development plans
|
||||
that consider technical dependencies, risk factors, and implementation
|
||||
complexity.
|
||||
|
||||
## Instructions
|
||||
|
||||
- Understand the requirements based on $ARGUMENTS. If the argument is a github
|
||||
issue, use Github CLI to fetch the details.
|
||||
- ASK for more information about the requirements. Iterate for at least 5
|
||||
questions to make sure you understand the requirement. Use the Questions tool
|
||||
to gather this information.
|
||||
- Analyze the code and build an implementation plan.
|
||||
- Divide the work in up to 5 tasks.
|
||||
- Prepare a well-structured description with markdown formatting
|
||||
|
||||
## On Completion:
|
||||
|
||||
- GITHUB: If the argument is a Github Issue, post your plan as an issue comment.
|
||||
Otherwise create a new issue descriptive title and message only if the issue
|
||||
doesn't exist.
|
||||
26
commands/create-pr.md
Normal file
26
commands/create-pr.md
Normal file
@@ -0,0 +1,26 @@
|
||||
# Create Pull Request
|
||||
|
||||
Create a new branch, commit changes, and submit a pull request.
|
||||
|
||||
## Behavior
|
||||
|
||||
- Creates a new branch based on current changes
|
||||
- Analyzes changes and automatically splits into logical commits when
|
||||
appropriate
|
||||
- Each commit focuses on a single logical change or feature
|
||||
- Creates descriptive commit messages for each logical unit
|
||||
- Pushes branch to remote
|
||||
- Creates pull request with proper summary and test plan
|
||||
- Do NOT add Claude co-authorship to PR description or commit messages
|
||||
- Use Github CLI if necessary
|
||||
|
||||
## Guidelines for Automatic Commit Splitting
|
||||
|
||||
- Run the linter, formatting and type checks tool for this project before
|
||||
commiting your changes.
|
||||
- Split commits by feature, component, or concern
|
||||
- Keep related file changes together in the same commit
|
||||
- Separate refactoring from feature additions
|
||||
- Ensure each commit can be understood independently
|
||||
- Multiple unrelated changes should be split into separate commits
|
||||
- Do NOT add Claude co-authorship to PR description or commit messages
|
||||
31
commands/execute-plan.md
Normal file
31
commands/execute-plan.md
Normal file
@@ -0,0 +1,31 @@
|
||||
# Execute plan
|
||||
|
||||
Execute a plan from GitHub issue or comment: $ARGUMENTS
|
||||
|
||||
## Instructions
|
||||
|
||||
You are a senior software engineer tasked with implementing a plan based on a
|
||||
GitHub issue. Please:
|
||||
|
||||
- Fetch the GitHub issue using the issue number or URL provided in the arguments
|
||||
- Parse the plan from the issue description or comment.
|
||||
- Create an execution strategy with concrete implementation steps
|
||||
- Generate concrete code and implementation steps
|
||||
- Create a new branch with a brief name using the conventional commit style as
|
||||
prefix (`feat/<branch-name>`, `fix/<branch-name>`, `docs/<branch-name>`, etc)
|
||||
|
||||
## On Completion
|
||||
|
||||
- Analyze changes and split them into logical commits when appropriate
|
||||
- Commit and push your changes in a logical order when appropriate
|
||||
- Each commit focuses on a single logical change or feature
|
||||
- Creates descriptive commit messages for each logical unit
|
||||
- Ensure each commit can be understood independently following the rules at
|
||||
@./commit.md
|
||||
- Multiple unrelated changes should be split into separate commits
|
||||
- Creates pull request in Github with proper summary following the instructions
|
||||
at @./create-pr.md
|
||||
- Do NOT add Claude co-authorship to PR description or commit messages
|
||||
- Use Github CLI if necessary
|
||||
- Link the issue and the PR
|
||||
- Update the issue tasks
|
||||
74
commands/five-whys.md
Normal file
74
commands/five-whys.md
Normal file
@@ -0,0 +1,74 @@
|
||||
# Five Whys Root Cause Analysis
|
||||
|
||||
You are an expert problem solver and root cause analyst with extensive experience in
|
||||
applying the Five Whys technique to uncover the underlying causes of issues in software
|
||||
development, system failures, and process problems.
|
||||
|
||||
## The Five Whys Method
|
||||
|
||||
The Five Whys is a problem-solving technique that involves asking "Why?" repeatedly
|
||||
(typically five times, but can be more or fewer) to peel away the layers of symptoms
|
||||
and discover the root cause of a problem.
|
||||
|
||||
## Instructions
|
||||
|
||||
1. **Understand the Problem**: Based on $ARGUMENTS, identify and clearly state the
|
||||
problem or issue being analyzed. If the argument is a GitHub issue, use the GitHub
|
||||
CLI to fetch the details.
|
||||
|
||||
2. **Ask Why Iteratively**:
|
||||
- Start with the problem statement
|
||||
- Ask "Why did this happen?" and provide a reasoned answer based on available
|
||||
information
|
||||
- For each answer, ask "Why?" again
|
||||
- Continue for at least 5 iterations (more if needed to reach a root cause)
|
||||
- If information is missing, make reasonable assumptions and note them
|
||||
|
||||
3. **Analyze the Codebase**: If relevant, search and analyze the codebase to:
|
||||
- Understand the context of the issue
|
||||
- Find evidence supporting your analysis
|
||||
- Identify code patterns or architectural decisions that may contribute to the issue
|
||||
|
||||
4. **Document the Analysis**:
|
||||
```markdown
|
||||
## Five Whys Analysis
|
||||
|
||||
**Problem Statement**: [Clear description of the issue]
|
||||
|
||||
**Why 1**: Why did [problem] occur?
|
||||
**Answer**: [First-level cause]
|
||||
|
||||
**Why 2**: Why did [first-level cause] happen?
|
||||
**Answer**: [Second-level cause]
|
||||
|
||||
**Why 3**: Why did [second-level cause] happen?
|
||||
**Answer**: [Third-level cause]
|
||||
|
||||
**Why 4**: Why did [third-level cause] happen?
|
||||
**Answer**: [Fourth-level cause]
|
||||
|
||||
**Why 5**: Why did [fourth-level cause] happen?
|
||||
**Answer**: [Root cause]
|
||||
|
||||
## Root Cause Summary
|
||||
|
||||
[Concise summary of the root cause identified]
|
||||
|
||||
## Recommended Actions
|
||||
|
||||
- [Action 1 to address the root cause]
|
||||
- [Action 2 to prevent recurrence]
|
||||
- [Action 3 for immediate mitigation]
|
||||
```
|
||||
|
||||
5. **Provide Recommendations**: Based on the root cause identified, suggest:
|
||||
- Immediate fixes or workarounds
|
||||
- Long-term solutions to address the root cause
|
||||
- Process improvements to prevent similar issues
|
||||
- Code changes or architectural improvements if applicable
|
||||
|
||||
## On Completion
|
||||
|
||||
- If the argument is a GitHub issue, post your Five Whys analysis as an issue comment
|
||||
- Otherwise, present the analysis to the user and offer to create documentation or
|
||||
action items based on the findings
|
||||
10
commands/linter.md
Normal file
10
commands/linter.md
Normal file
@@ -0,0 +1,10 @@
|
||||
# Linter
|
||||
|
||||
Run the linter tool bash command for this project and fix all the issues found
|
||||
|
||||
## Instructions
|
||||
|
||||
- Find out what the linter tool is for this project. Check in these files:
|
||||
Makefile, pyproject.toml, package.json
|
||||
- Run the linter tool command
|
||||
- Fix the reported linter or type errors
|
||||
112
commands/pr-review.md
Normal file
112
commands/pr-review.md
Normal file
@@ -0,0 +1,112 @@
|
||||
# PR Review
|
||||
|
||||
**PR Link/Number**: $ARGUMENTS
|
||||
|
||||
> **Instructions**: Execute each task in the order given to conduct a thorough
|
||||
> code review. Update GitHub with this review. **Important**: The future is
|
||||
> now—any improvements or “future” recommendations must be addressed
|
||||
> **immediately**. If you implemented changes, commit and push them to the PR
|
||||
> branch. Do NOT add Claude co-authorship footer to commits.
|
||||
|
||||
---
|
||||
|
||||
## Task 1: Product Manager Review
|
||||
|
||||
**Objective**: Assess from a product management perspective, focusing on:
|
||||
|
||||
- **Business Value**: Does this PR clearly advance our core product goals and
|
||||
deliver immediate ROI?
|
||||
- **User Experience**: Is the change intuitive and delightful for users right
|
||||
now? If not, make fixes immediately.
|
||||
- **Strategic Alignment**: Does the PR align with current (and long-term, i.e.,
|
||||
now) strategic objectives?
|
||||
|
||||
**Action**: Provide clear directives on how to ensure maximum user and business
|
||||
impact. All “future” suggestions must be implemented now.
|
||||
|
||||
---
|
||||
|
||||
## Task 2: Developer Review
|
||||
|
||||
**Objective**: Evaluate the code thoroughly from a senior lead engineer
|
||||
perspective:
|
||||
|
||||
1. **Code Quality & Maintainability**: Is the code structured for readability
|
||||
and easy maintenance? If not, refactor now.
|
||||
2. **Performance & Scalability**: Will these changes operate efficiently at
|
||||
scale? If not, optimize immediately.
|
||||
3. **Best Practices & Standards**: Note any deviation from coding standards and
|
||||
correct it now.
|
||||
|
||||
**Action**: Leave a concise yet complete review comment, ensuring all
|
||||
improvements happen immediately—no deferrals.
|
||||
|
||||
---
|
||||
|
||||
## Task 3: Quality Engineer Review
|
||||
|
||||
**Objective**: Verify the overall quality, testing strategy, and reliability of
|
||||
the solution:
|
||||
|
||||
1. **Test Coverage**: Are there sufficient tests (unit, integration, E2E)? If
|
||||
not, add them now.
|
||||
2. **Potential Bugs & Edge Cases**: Have all edge cases been considered? If not,
|
||||
address them immediately.
|
||||
3. **Regression Risk**: Confirm changes don’t undermine existing functionality.
|
||||
If risk is identified, mitigate now with additional checks or tests.
|
||||
|
||||
**Action**: Provide a detailed QA assessment, insisting any “future”
|
||||
improvements be completed right away.
|
||||
|
||||
---
|
||||
|
||||
## Task 4: Security Engineer Review
|
||||
|
||||
**Objective**: Ensure robust security practices and compliance:
|
||||
|
||||
1. **Vulnerabilities**: Could these changes introduce security vulnerabilities?
|
||||
If so, fix them right away.
|
||||
2. **Data Handling**: Are we properly protecting sensitive data (e.g.,
|
||||
encryption, sanitization)? Address all gaps now.
|
||||
3. **Compliance**: Confirm alignment with any relevant security or privacy
|
||||
standards (e.g., OWASP, GDPR, HIPAA). Implement missing requirements
|
||||
immediately.
|
||||
|
||||
**Action**: Provide a security assessment. Any recommended fixes typically
|
||||
scheduled for “later” must be addressed now.
|
||||
|
||||
---
|
||||
|
||||
## Task 5: DevOps Review
|
||||
|
||||
**Objective**: Evaluate build, deployment, and monitoring considerations:
|
||||
|
||||
1. **CI/CD Pipeline**: Validate that the PR integrates smoothly with existing
|
||||
build/test/deploy processes. If not, fix it now.
|
||||
2. **Infrastructure & Configuration**: Check whether the code changes require
|
||||
immediate updates to infrastructure or configs.
|
||||
3. **Monitoring & Alerts**: Identify new monitoring needs or potential
|
||||
improvements and implement them immediately.
|
||||
|
||||
**Action**: Provide a DevOps-centric review, insisting that any improvements or
|
||||
tweaks be executed now.
|
||||
|
||||
---
|
||||
|
||||
## Task 6: UI/UX Designer Review
|
||||
|
||||
**Objective**: Ensure optimal user-centric design:
|
||||
|
||||
1. **Visual Consistency**: Confirm adherence to brand/design guidelines. If not,
|
||||
adjust now.
|
||||
2. **Usability & Accessibility**: Validate that the UI is intuitive and
|
||||
compliant with accessibility standards. Make any corrections immediately.
|
||||
3. **Interaction Flow**: Assess whether the user flow is seamless. If friction
|
||||
exists, refine now.
|
||||
|
||||
**Action**: Provide a detailed UI/UX evaluation. Any enhancements typically set
|
||||
for “later” must be done immediately.
|
||||
|
||||
---
|
||||
|
||||
**End of PR Review**
|
||||
69
plugin.lock.json
Normal file
69
plugin.lock.json
Normal file
@@ -0,0 +1,69 @@
|
||||
{
|
||||
"$schema": "internal://schemas/plugin.lock.v1.json",
|
||||
"pluginId": "gh:puelpan/claude-plugins:development",
|
||||
"normalized": {
|
||||
"repo": null,
|
||||
"ref": "refs/tags/v20251128.0",
|
||||
"commit": "32ae31941763f0106c1207a893dd52709bf67188",
|
||||
"treeHash": "a47494bb23f9221b73c914313c1a84d00e064c026b274403d017b59600f97972",
|
||||
"generatedAt": "2025-11-28T10:27:42.029786Z",
|
||||
"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": "development",
|
||||
"description": "Collection of claude commands to ease the development process with github issues, PRs and more",
|
||||
"version": "1.1.0"
|
||||
},
|
||||
"content": {
|
||||
"files": [
|
||||
{
|
||||
"path": "README.md",
|
||||
"sha256": "c979d0a843f731b1bf399194183c6606c02e824581a74ccb5b386c149ffe18bf"
|
||||
},
|
||||
{
|
||||
"path": ".claude-plugin/plugin.json",
|
||||
"sha256": "a6c6de243a5f4d9af70d3367933c8506ade1a634802e039173aa333a945705c6"
|
||||
},
|
||||
{
|
||||
"path": "commands/five-whys.md",
|
||||
"sha256": "e6c83c3ceb61fb041a532af575da6dbb795b4e2015f59ae0fdf48ea64933ff6f"
|
||||
},
|
||||
{
|
||||
"path": "commands/execute-plan.md",
|
||||
"sha256": "0f5d20cae2b9acae0c88b07dc0b86c89612dc28f3e5668e224720b4a0e61fa2e"
|
||||
},
|
||||
{
|
||||
"path": "commands/linter.md",
|
||||
"sha256": "c05eb79559aa066fcc2d726d1b9d516cec0180d94f2fdd5fedf8a641b4ff27ac"
|
||||
},
|
||||
{
|
||||
"path": "commands/create-pr.md",
|
||||
"sha256": "1292a3697f9b7fe6ae4988fa947880931fe1bc119bc012143a1ba23ccd2217b8"
|
||||
},
|
||||
{
|
||||
"path": "commands/create-plan.md",
|
||||
"sha256": "c783f9740ce6f2319b5e04af714cd6db090a92e9578a1a139cc0eceef4c5f618"
|
||||
},
|
||||
{
|
||||
"path": "commands/commit.md",
|
||||
"sha256": "378057d82645dd1beb7bed8aad825f5cf79d81ff461b5b842efd1f0ebb31bef1"
|
||||
},
|
||||
{
|
||||
"path": "commands/pr-review.md",
|
||||
"sha256": "48b9e9ee6f84e0b2915ab77a022e786870252fa3c5d212926c08caf6079bcc9f"
|
||||
}
|
||||
],
|
||||
"dirSha256": "a47494bb23f9221b73c914313c1a84d00e064c026b274403d017b59600f97972"
|
||||
},
|
||||
"security": {
|
||||
"scannedAt": null,
|
||||
"scannerVersion": null,
|
||||
"flags": []
|
||||
}
|
||||
}
|
||||
Reference in New Issue
Block a user